Attempting to Change VC Service Account failing

[JonT]

I am trying to change my VC (Virtual Center 2.0.2) Service Account from my personal Domain User account to a Domain Account specifically setup for this service. At this time I cannot start the service using this new account on the VC server and need to make this switch. Here is what I have done and checked so far:

1. The new Domain account has "local admin" rights on both the VC server and the standalone DB Server (SQL 2005).

2. The new Domain account has the exact same permissions to the Database as my domain account does.

3. Checked to make sure the SVC account has permissions in the security to "log on locally"

4. Checked using an SQL Trace and it appears that the account is able to connect to the DB. Trace output below.

5. Checked all manner of A.D. properties on the SVC account to make sure it is correct.....

My SQL DBA's sent me this excert from the trace, as well as the entire trace file:

-

---

In the trace, starting at 9:01:45, I see activity for this userid, PRD_SV0_VMW, but it lasts for less than a minute.

It does some setup stuff, then runs this query several times:

select USER_NAME() select usertype,type,name from systypes where usertype>=257

When it finishes that, it runs this query:

declare @p1 int

set @p1=NULL

exec sp_prepexec @p1 output,N'@P1 varchar(14)',N'select id from vpx_sequence where name = @P1','VPX_ENTITY_SEQ'

select @p1

Then it logsout.

-

---

I have attached the SQL trace in case anyone wants to view it.

Does anyone have any ideas? I really need to get Virtual Center to stop using my account because of normal password policy requirements to change the PWD every so often......

[sbeaver]

Did you change your ODBC DSN account to reflect this change? You can try to re-run setup as an upgrade and change the account that way,

Steve Beaver

VMware Communities User Moderator

*Virtualization is a journey, not a project.*

[JonT]

Unfortunately I recreated the ODBC (System) DSN but no change at all.....I am keeping the option of upgrading to 2.5 now open but want to make sure this service account is going to work. I don't want to have to roll-back because of my service account today....

[davesil2]

Did you set the Service account to be able to "log on as a service" in at least the local group policy? this is not a default option that would be enabled by copying administrator or anything like that. You may have to set the "log on as a service" in AD group policy depending on the overrides you have.

[JonT]

Well you are correct in that I don't know what domain GPO overrides are setup, but I did add the account to the "log on as a service" in the local policy and no change. For now I have the service back as my domain user account so that VC will be available, but if anyone else has any ideas I am all ears.....

Thanks

[davesil2]

Is your ODBC connection setup for UserDSN or SystemDSN. If it is set to UserDSN, you either need to login as that domain user and create it for the user or you need to Create the ODBC connection as SystemDSN. System would be available to all users where user is only available to the current user.

-David

[JonT]

David,

Not a bad thing to check for sure. My ODBC connection type is System as it was setup previously. At this point I tested a UserDNS as well just to make sure but am getting ready to setup a VM with Virtual Center on it ( i have a spare license) and test the service account on that new VM. If it works I am just going to blow away the current install and install 2.5 fresh. If anyone has another solution idea while I am testing please let me know.

[JonT]

Ok to add insult to injury with the 2.5 installer I get an error pop-up saying

"The DB user entered does not have the required permissions needed to install and configure VMware VirtualCenter Server with the selected DB. Please see the installation documentation for detailed DB permission requirements."

Does anyone know the specific DB permissions needed or where to find it? The service account I have supposedly has DBO rights to the database and I thought that would be enough. That is what my domain user account has to the same DB.....very odd...

[JonT]

Ok so for anyone who understands SQL permissions better than I (not hard to do), would i need to have a SQL Login created or available for this DSN/user? I checked the SQL server and found that my domain account that does work is a member of a group that is defined in the base server Logins permissions folder but my SVC account is not. Does this even matter? I have asked my SQL DBA's but no answer on it yet.....

[JonT]

Update on this for anyone who cares....after looking at this closer with my DBA, it appears that during my initial install of VC a long time ago the schema assigned to my account is a special one, and not the default dbo schema. The entire VC database right now is permissioned for the schema that was specially created on my user account. My DBA is looking into changing the schema arrangments around and hopefully this will give me the access I need on my service account.

[sbeaver]

The service account needs to be DBO at least for the install

[JonT]

Ok after further digging here is what I have found. The service account is a dbo for the database and has all the rights it should. I checked the "vpxd.log" files and found this recurring error:

Log for VMware VirtualCenter, pid=5024, version=2.0.2, build=build-50618, option=Release, section=2

Current working directory: C:\WINDOWS\system32

Initializing SSL context

Vmacore::InitSSL: doVersionCheck = true, handshakeTimeoutUs = 120000000

NFC connection accept timeout: 180000 milliseconds

NFC request timeout: 180000 milliseconds

NFC read timeout: 60000 milliseconds

NFC write timeout: 600000 milliseconds

Starting VMware VirtualCenter 2.0.2 build-50618

Account name: PRD_SV0_VMW

Enabled low-frag process heap.

Enabled low-frag crt heap.

34 max LROs

6 reserved internal LROs

6 reserved blocker LROs

6 reserved short LROs

4 reserved long LROs

600-second task lifetime

Failed to init tableDef: Column VER_ID does not exist in table VPX_VERSION. Database version may be incompatible.

Failed to intialize VMware VirtualCenter. Shutting down...

[JonT]

To add further insult to injury on this, I manually opened up the DB to view the tables on the remote SQL server and the table and column mentioned are still there named properly. I read in the installation guide that for a remote SQL server the only supported authentication is SQL authentication, but with a local SQL install NT domain authentication is supported. My SQL DBA is digging through a SQL Trace right now but if anyone has any ideas it would really help....

[JonT]

Ok, thanks to everyone who helped out on this. The actual fix was to remove the service account from the database "users" container and have it only defined in the SQL "logins" container. Also we had to set the actual database owner (not db_owner) to the service account. Apparently setting the account with db_owner rights to the database was not enough for the vpxd service.