vCenter SSO update/installation oddities and hints

I have just updated my lab with the recently released vSphere 5.1 Update 1 and want to share some oddities I encountered with the Single Sign On (SSO) component.

1. When I tried to update the Single Sign Component from the Autorun-GUI of the vCenter installation ISO I encountered an error message that I already knew from the original installation of vCenter 5.1 GA:

vCenter SSO installation/upgrade error 2229

Since I already knew this annoying error (<rant>Why has this not been fixed with U1??</rant>) I also knew the related KB article KB2037976: It stated that this issue occurs on non-English versions of Windows.
Now the odd thing is that I was indeed using a US-English version of Windows (I never use localized Windows versions, just to avoid errors like these ...), I even did not install the German language pack - I only had the Administrator's regional settings (keyboard, location and time/date formats) configured to German! Obviously this is enough to let the installer stumble ...

2. The resolution in the KB article is to install SSO via a command line like this:

VMware-SSO-Server.exe /S /v"/L*v \"%temp%\vim-sso-msi.log\" /qn"

So I opened a command prompt, copied and pasted this line into it, completed the path to the exe file and started it - only to find out after a while (by looking at the log file) that the installation failed again, this time with MSI error 1603.
To fix this change to the directory that includes VMware-SSO-Server.exe before you start it. The KB article somewhat explains that: "2. From the command line, navigate to the folder ...", but this can be easily read over.

3. Please note: Upgrading SSO this way will result in a forced and unannounced reboot. This is not really a problem, because you should have planned a downtime of vCenter for updating it anyway. However, the reboot might surprise you if you are in the middle of doing something else on the server while running through the upgrade procedure.
You might be able to suppress the automatic reboot by adding appropriate MSI options to the command line (I haven't further tested that). It is noteworthy that the updates of Auto Deploy and the Dump Collector through the Autorun-GUI will also warn about reboots being necessary, but don't force it. Anyway it is best practice to reboot again at least once after all components have been updated - just to check whether all vCenter components start cleanly after a server crash or reboot.

4. And a last hint: If you run the update/installation of SSO in a Remote Desktop Session then you should modify the path to the installation log file in the command line from the KB article. %temp% points to your personal temporary directory and this will by default be deleted by Windows once you are logged off from the Remote Desktop Session (which will happen inevitably, because the server reboots). This way you would lose the log file.

Apart from these glitches the update of my test lab went pretty smooth, and I have not encountered any issues since then.