Getting smashed on vCenter 5.1 SSO Install

[TonyNguyen]

VMWare Experts,

Getting smashed on the vCenter 5.1 SSO Install and was wondering if I could get some assistance.

This is what I've done so far:

1.) Execute the "rsaIMSLiteMSSQLSetupTables.sql"

2.) Change only the "C:\Changeme" portion of the script which was "C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2K8R2\MSSQL\DATA

3.) Execute the script which created a database named RSA

I then went to vCenter Simple Install which started out installing the SSO which I got held up on.

Under Database Type: I chose MSSQL:

I am drawing a blank next on the syntax remaining fields.

The relevant server names are:

SQL Servername: TEST-SQL01.test.local

SQL Named Instance: SQL2K8R2

vCenter Server: TEST-VC01.test.local (where I will be installing the SSO, Inventory service, etc)

No idea on what to set for the Database Name, Windows Authentication, JDBC URL, etc.

I tried to follow the install guide and there was no mention of if I needed to set up ODBC connections or anything like that.

Any help would be greatly appreciated.

[bedobash]

I logged in to the vSphere web client using the domain service account that I configured vCenter to run as, and this allowed me to make changes to the permissions of the vCenter server (Home -> vCenter -> Inventory Lists -> vCenter Servers -> (vCenter FQDN). then Manage -> Permissions and you should see Administrators listed here.

Theoretically this will mean that any domain account that has local administrator permissions over the vCenter server host via GPO will have rights to the box.

Add the domain security group used for VMware administrators (test it to make sure it works! or you'll lock yourself out removing administrators), then remove administrators. I added SYSTEM-DOMAIN\admin in here just in case SSO domain authentication screwed up.

Ofcourse, this is all dependent on your SSO install going smoothly, and either it auto-detecting your active directory domain configuration and adding ldaps connections to all necessary domains, or you manually adding these connections. On my very first upgrade attempt, the SSO install would not auto-discover domain configuration (and the entire upgrade blew up), but on the second run through everything worked fine. When I log in to SSO, I see both <root domain> and <child domain> along with 2 ldaps (primary/secondary) per domain. Also, Base DNs for users and groups are auto populated, and authentication type is set to Reuse Session.

LiamSinton let me know if any of this doesn't help your deployment complete successfully.

[Asru]

admin@System-Domain does not have any permissions on any VCenter - by design.

You need to add another user (yours) to _Regular Users_ group or _Administrators_ group; your user needs to have permissions on VCenter too. After that you'll be able to login with your user and you'll see your VCenter instance in the list.

[LiamSinton]

My issues turned out to be that the RSA database was created in SQL 2000 compatibility mode, once I changed to SQL 2005 compatibility mode to match VIM_VCBD and VIM_UMDB (Vmware suggested SQL 2008 mode but I thought best to match), the upgrade all continued through without any issues.

I tell a lie, the simple install option failed on so I had to actually run each part separately (sso, inventory service and vcenter) but apart from that everything went well.

It even upgraded my permissions so all existing permissions were left in place which I wasn't expecting!

[Asru]

My problems with SSO (so far - the night is young) are these:

1. What can I do to delete an AD group from _Administrators_ group.

2. How can I create a new admins group if I delete the default _Administrators_ group.

Any help would be appreciated.

Thanks.

[LiamSinton]

Sorry, wish I could offer some advice but as I didn't have any issues with permissions after SSO installed, I can't help.

Did you log it with Vmware? Can you rollback?

[Asru]

I will log with VMware soon, if I don't find an answer to those questions.

The environment is working, but there's a domain group we added to _Administrators_ and we'd like that removed. So far we could only remove user accounts, not groups.

Second question was related to first one, as if that doesn't work (removing AD groups) maybe we can remove _Administrators_ group and recreate it.

Rolling back is not really an option.

[LiamSinton]

I'm not really sure what you mean to be honest....

Are you talking about permissions and roles at vcenter level?

The Administrators group at vcenter level is locked as far as I am aware so you can't add groups to it but I could well be wrong of course

There is also an Administrator role that you can assign to a group you have added which makes more sense to me, is this what you mean?

[Asru]

Nope.

I'm talking about SSO Users and Groups>Groups.

There you have 4 default groups: LSAAdministrators, _Regular_Users_, VCOAdministrators and _Administrators_

First question: We added a group for Active Directory to _Administrators_ group (bad, I know now). Trying to remove that AD group returns this error:

The "Delete group" operation failed for the entity with the following error message.

The specified principal (VMware_Admins) is invalid.

If you delete an AD user instead of an AD group it works fine.

Second question: How can we create another admin group in SSO? Or is it even possible?

[LiamSinton]

I think we may have different VMware versions as I am Essentials Plus and I am guessing you are probably Enterpise Plus?

That might explain why I didn't have to do anything with SSO Users and Groups and don't even know where you configure them.

I can't see any separate SSO app on my vCenter server or anywhere in vCenter that relates to SSO user and groups....:smileyplain:

[Asru]

It's Ent Plus, yes. Evaluation.

See attached.

[LiamSinton]

Hi, I asked the question to my good man at VMware and this was his reponse ;-0

SSO Bug

At this time there is no workaround for removing a group.

When attempting to remove a user, select the user to be removed then click the Red X button. You will be prompted with a dialog box confirming the removal. Right clicking or selecting Remove Principal from the Actions menu attempts to remove the principal itself, not the assignment to the group.

You should have only one admin group in SSO

If things go far south reinstall SSO and re-regisater inventroy and VC again

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=203362...

[Asru]

Thanks for that, really appreciate it.

I already deleted the admins group on SSO in my lab, so the answer "You should have only one admin group in SSO" doesn't really help. Would be nice to see how to create an admin group.

I guess it's a good time to test that KB

[Asru]

SSO seems so...rushed.

[LiamSinton]

I thought the whole upgrade was a mess compared to previous simple upgrades so I can only imagine it would be much worse for enterprise users who actually need SSO. I just saw it as an inconvenience and would have skipped it if I could but there are only a handful of vCenter users here....

Good luck with it

[Asru]

We were doing just fine before SSO, to be honest.

[LiamSinton]

Haha, so you didn't want it either!

I'm sure someone does....:smileyconfused:

[Asru]

My bet would be vCloud guys...I blame them anyway.

[LiamSinton]

Would've been nice if VMware let us have the choice whether or not we wanted SSO, surely it would have been in their own best interests not to force everyone to upgrade to SSO and end up logging millions of support requests when it doesn't work...

[Asru]

When it doesn't work...I'm sure you meant Because it doesn't work as it should and it's a pain somewhere dark so far.

[drosala]

Has anyone attempting this with an external Oracle 11g database?  I am finding the lack of database guidelines, especially for non MSSQL databases frustrating.