If you been installing an SAP CE 7.2 system on an 32-Bit Windows Server on a Amazon Web Service cloud system but failed upgrading it to SP03 then this blog is for you. The reason the upgrade initially fails is, because the kernel upgrade fails upgrading certain dlls and you will se the following error message:

However, if you were able to solve this, you would run into another problem that is caused by insufficient Java heap memory due to a formula to calculate this type of memroy that is unsuited for a 32-Bit Windows Server Amazon Web Service cloud installation and you will see the following error message:

Having a look into the developer trace of the J2EE server process would reveal that in fact it ran out of memory:

So lets change this and two other parameters that could prevent the upgrade from beeing successfull and start the installation all over again. Start the Config Tool:

In the Config Tool navigate to cluster-data -> template -> instance and chose the tab for the VM Parameters. There you see the unsuited calculation. To change this enter 1024 as the Custom Value for the maxHeapSize parameter:

Then navigate to cluster-data -> template -> services -> classpath_resolver and set 256 as the value for javac.Xmx, which is the heap size for the Java compiler:

Save your change and restart the cluster as the Config Tool tells us to do.

Next we have to adjust the cache size of the MaxDB database. For this launch the Database Manager, navigate to Configuration -> Parameters and change the CacheMemorySize parameter to 8192:

Now we can (re-) start the upgrade. To do so start the SAP Java Support Package Manager (JSPM):

Login as administrator or user <SID>adm. (Your SAP CE 7.2 J2EE server has to be up and running for this.) If you loged in as administrator JSPM would complain that you should login as user <SID>adm but in fact it makes no difference for the upgrade:

Select "Support and Enhancement Package Stack" as the package type you want to apply:

Slect "Service market place" as the source for the archives to apply. That way JSPM will download the required support package stack automatically:

To enable JSPM to download the support package stack you have to provide your SAP service market place user and password and if required your proxy information:

Next you tell JSPM to search for the latest patches:

First thing JSPM checks whether it is up-to-date and if not upates itself:

For this JSPM generates an import queue as usual, which you have to confirm:

It won't be long until JSPM deployed the new version of itself and required to be restarted:

You wouldn't have to restart it manually but it restarts automatically. This takes a minute, so just be patient. Finally you will have to login as before, select the same package type and specify the SAP service market place as the source for the support package stack again. JSPM remembered your SAP service market place user, but you have to enter your password again. Also you have to tell JSPM again to search for the latest patches. After a while JSPM comes up with a huge list of upates, including kernel updates:

Next JSPM downloads all the software archives which can be a while:

However, eventually JSPM comes up with the queue for deploying the full support package stack which you need to confirm again:

Next JSPM shuts down the J2EE engine to upgrade the SAP kernel. Unfortunately, as mentioned earlier, this will not succeed but result in an error:

Fortunately we are talking SAP software so we just follow the link to the Log Analyzer. That tell us to look into a log at Logfile location: \jspmlogs\JSPM_MAIN_1_01.LOG. There we find the following:

That means copying some files from a shadow kernel directory (D:\usr\sap\<SID>\J00\j2ee\JSPM\tmp\newKernel_01\kernel) to the actual kernel directory (D:\usr\sap\CE1\<SID>\exe\uc\NTI386) did not work. While not knowing the reason for this problem, we don't bother but just copy the new kernel manually. When being asked whether to replace an existing file we do so and also for all other occasions:

During the copying we run into the same problems as JSPM:

We cancel the copying, rename the original file, in this case icudt34.dll to icudt34.dll.del:

and start the copying again. We repeat this until the kernel is fully upgraded. We then proceed with JSPM and after a couple of hours and some automatic restarts of the SAP J2EE server the upgrade fineshed successfully:

With this we got an mostly up-to-date SAP CE 7.2 system in the cloud. However be aware that there are already quite a few patches available for CE 7.2 SP03. Therefore, if you run into a strange problem with CE 7.2 SP03, check for those patches.