SSO database import - Bug

[TheoSmit]

Hi - I hope there are some wizards around that can help me.

I am installing two vCenter sites (5.1U1b) set up in linked mode and a multi site SSO deployment (SQL2012 db). As suggested I have installed my Site01 vCenter with all the requirements and exported the SSO database. Then installed the second site's SSO and imported that database into Site02. Then carried on with the installation of vCenter at Site02. Once both sites had vCenter I exported Site02 SSO database and imported it at Site01 so that all sites are on the same page.

I then wanted to create a checkpoint hence I shut both servers down and took snapshots in their current states.

Once back online I installed SRM at Site01, but before installing at Site02 I want to distribute Site01 changes to Site02. The export works, but when I import at Site02 I get the following response after ten minutes.

Start executing full data import

Bug

Some notes:

I noticed the command is case sensitive to the path and gives the same Bug response (albeit immediately instead of minutes later) if sso is used instead of SSO for db directory location...This is not currently the case.

My installation directories are not default. (C:\Program Files => E:\Services)

Domain accounts were used as follows - SQL installation - Domain\SQLaccount, SSO/IS/VC installation - Domain\VCaccount, SRM installation - Domain\SRMaccount.

I am not able to see cause in the repl_tool.log file (attached).

Has anybody seen this or know what could be wrong? Suggestions?

Thanks in advance

Theo

[raog]

This is a known issue.. you will need to contact VMware support to get the jar file with the workaround/fix for this.

Regards

Girish

[TheoSmit]

Thanks Girish

I will log the support call.

[EXPRESS]

TheoSmit, can you tell us the outcome of this, I am finding myself in a similar situation but not with SRM, SSO. I have seen those errors in the log files as well.

Thanks

[TheoSmit · Accepted solution]

I have finally been able to get this working last night!

In response to Girish I have logged the call. They have sent me a java file that I had to replace as Girish suggested needs to happen. This however did not solve the problem. The new file did not work at all. I reverted back to the old and the support engineers then went ahead with troubleshooting. (My installation paths are not default or the versions are incorrect - we did not troubleshoot the reason for this, but I have found in other scripts that the different installation path wasn't working and have fixed the path in all scripts required.)

The actual solution:

SRM does not require the SSO database to be distributed according to the engineer.

Furthermore it seems as if v1 of SSO does not like it when the database is distributed when there are no changes. That was the reason it broke.

I therefore proceeded with the second SRM installation straight after the first. The last time I synced the SSO databases was after the VC installations.

I have my reservations with this solution, but have confirmed with the engineer that it is correct. I still need to test the system extensively.

The next version of SSO (v2) shipped with vSphere 5.5 apparently does not require manual database synchronization. It was also completely rebuilt and might be more stable than the current. I will wait for that version when I have the choice. The other option would be to not use linked mode and run two completely seperate SSO servers. It would still be v1 though unless you wait for VC 5.5.

[TheoSmit]

I thought I'd come back and give the latest update on my SSO saga.

Since vSphere 5.5 was released I have installed v5.1 with the new SSO v2. This seems to be working and I have not experienced problems yet. Systems are still not in full production, but no problems thus far.

I had to install SSO2 and Web Client 5.5 from the new release and could then carry on with the Inventory Service, Virtual Center, VC Client and SRM of the 5.1 release.

Once the dust has settled around the v5.5 release and all is proven to be stable it would probably make sense to upgrade all components, but for now I'd rather be cautious and still stick with v5.1 where possible.

Hope this can help someone else in a similar situation...