Hi .. i'm a new to VM.. i'm installing vCenter 5.1 on Windows Server 2008 R2 (4 GB RAM and 2 X vCPU) . It errors out starting the service.. full log file below attached ... please anyone help
Moderator note: moved to vCenter Server forum area.
Same problem here, here is my situation:
Hello,
I am running the following in my envrionment:
2 vCenters running 5.1
4 hosts running ESXi 5.1.0, 799733
I am working to P2V all my physical machines in my lab. I had a physical Domain Controller called DC1 and my domain is called DC.local.
I recently performed the following change in my environment:
Created a new VM called DC2.dc.local and promoted it to domain controller and installed the DNS role.
Migrated all FSMO roles over to DC2.dc.local.
Ran dcpromo on DC1.dc.local and demoted it to member server and removed the DNS role.
Powered off DC1 and reimaged DC1.dc.local (it's gone and never coming back).
I have updated the clients to use DC2.dc.local's IP address as the primary DNS. DNS resolution is working from all hosts, I have all hosts can ping one another. I was repeatedly getting and error stating "Authorize Exception" when I attempted to log in to vCenter with "Use Windows session credentials", or I would get a standard error stating that the username or password is incorrect.
I disjoined my vCenter's from the domain and re-added them as it suggests in the following KB:
Once the vCenters were added back into the domain and restarted the VirtualCenter Server service has failed to start. Looking in the logs I can see the following errors which appear to be the cause:
2012-10-29T16:27:05.948-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [InitSsoAdminServices] successful.
2012-10-29T16:27:05.948-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [LoginToAdmin]
2012-10-29T16:27:05.948-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [CheckTokenValidity]
2012-10-29T16:27:05.964-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [CheckTokenValidity] Refreshing SSO token ...
2012-10-29T16:27:05.964-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [RefreshSsoToken]
2012-10-29T16:27:07.376-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [RefreshSsoToken] The VC HOK token has been successfully refreshed.
2012-10-29T16:27:08.851-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [LoginToAdmin] Successfully logged.
2012-10-29T16:27:08.915-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [FindGroup]
2012-10-29T16:27:12.802-04:00 [04688 error '[SSO]'] [UserDirectorySso] NormalizeUserName AuthException: Authorize Exception
2012-10-29T16:27:12.802-04:00 [04688 warning 'Default'] Warning, existence of group "DC\Administrators" unknown, permission may not be effective until it is resolved.
2012-10-29T16:27:12.802-04:00 [04688 error 'Default'] The group account "DC\Administrators" could not be successfully resolved. Check network connectivity to domain controllers and domain membership. Users may not be able to log in until connectivity is restored.
2012-10-29T16:27:12.802-04:00 [04688 info '[SSO]'] [UserDirectorySso] GetUserInfo(DC\Administrators, true)
2012-10-29T16:27:12.802-04:00 [04688 info '[SSO][SsoAdminFacadeImpl]'] [FindGroup]
2012-10-29T16:27:14.055-04:00 [03952 warning 'VpxProfiler' opID=SWI-8b1c03cd] VpxUtil_InvokeWithOpId [TotalTime] took 12184 ms
2012-10-29T16:27:26.318-04:00 [03952 warning 'VpxProfiler' opID=SWI-62904c1e] VpxUtil_InvokeWithOpId [TotalTime] took 12059 ms
2012-10-29T16:27:35.822-04:00 [02688 warning 'VpxProfiler' opID=SWI-67707f6a] VpxUtil_InvokeWithOpId [TotalTime] took 30030 ms
2012-10-29T16:27:38.820-04:00 [03952 warning 'VpxProfiler' opID=SWI-a7d9da71] VpxUtil_InvokeWithOpId [TotalTime] took 12293 ms
Looking into it further I found a KB which I believe is closely related to my issue because it suggests a problem with the Domain:
However, I can't figure out what the problem could be. I only have a single DC so replication issues can't (or shouldn't) be the problem. There were no errors during the DC decomissioning. I am able to add and remove computers to the domain without issue. I cannot find any DNS problems on any of the clients.
Any suggestions?
same problem here, seems to be an SSL problem
still same error with VCENTER 5.1.0a ......
Did you perform an upgrade or clean install? To be honest, installing 5.10A was going to be my next step, sounds like it might be a waste of time.
I'm almost certain I've found the problem. The SSO logs contain an erroneous reference to DC1.DC.local. This is the domain controller which has been decommissioned. Where is SSO pulling this server name from? All DNS records have been removed which referenced it, the correct server should be DC2.dc.local. Hopefully I just need to correct this setting somewhere, but I have no idea where:
C:\Program Files\VMware\Infrastructure\SSOServer\logs\imsTrace.log
2012-10-30 13:34:17,457, [castle-exec-23], (SecurityTokenServiceImpl.java:112), trace.com.rsa.riat.sts.impl.SecurityTokenServiceImpl, ERROR, VC51.DC.local,,,,Error while trying to generate RequestSecurityTokenResponse
com.rsa.common.ConnectionException: Error connecting to the identity source
Caused by: javax.naming.NamingException: getInitialContext failed. javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection 'ldaps://DC1.DC.local:3269' with 'GSSAPI' Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection DC1.DC.local:3269 [Root exception is javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection 'ldaps://DC1.DC.local:3269' with 'GSSAPI' Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection DC1.DC.local:3269]
Caused by: javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection 'ldaps://DC1.DC.local:3269' with 'GSSAPI' Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection DC1.DC.local:3269
Caused by: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection DC1.DC.local:3269
Caused by: javax.naming.CommunicationException: DC1.DC.local:3269 [Root exception is java.net.UnknownHostException: DC1.DC.local]
Caused by: java.net.UnknownHostException: DC1.DC.local
I have fixed this problem in my environment by creating an alias record which redirects SSO to the correct domain controller. I would strongly recommend checking your SSO logs located at:
C:\Program Files\VMware\Infrastructure\SSOServer\logs\imsTrace.log
Search for errors like the ones I found, example:
Unable to create managed connection DC1.DC.local:3269
Create an alias record which redirects SSO to the functioning DC. This is just a workaround, I really don't know the true problem, but it appears that there are some domain controller settings in SSO which are hard coded upon install.
i did a clean install of the vCenter 5.1.0a with SSO and Inventory.
logs show that it fails acquiring the sso ...doesn't get past that
Same problem, had issues with an inplace upgrade so I have just tried an install on a fresh virtual machine.
Lots of people saying this is a SSL siisue, but if its a fresh install and the certs look good untill 2022 then why on earth wont the service start
Looking through our DNS we had a lot of old ojects which were no longer relevant. So I deleted them all and tried again, same problem.
I have just tried installing on a server which isnt a memember of our domain and it worked first time.
So It has to be something to do with our active directory. I have checked name resolution and all appears to be fine. The only thing I can think of now is our domain is domain.co.uk maybe the SSO service doesnt like accepting requests from servers with an extrenal namespace. Although I cant think why, internal DNS is authorative and we dont have any other issues.
The other idea I had was that we created a new doamin admin account and moved the defautl administrator one to just be a domain user. I tried again with this as a Domain admin but no luck. I could see some references to this user in the logs, but im not sure if it was causing any problems.
The install was done with another domain admin account
I recently performed the following change in my environment:
Created a new VM called DC2.dc.local and promoted it to domain controller and installed the DNS role.
Migrated all FSMO roles over to DC2.dc.local.
Ran dcpromo on DC1.dc.local and demoted it to member server and removed the DNS role.
Powered off DC1 and reimaged DC1.dc.local (it's gone and never coming back).
I have updated the clients to use DC2.dc.local's IP address as the primary DNS. DNS resolution is working from all hosts, I have all hosts can ping one another. I was repeatedly getting and error stating "Authorize Exception" when I attempted to log in to vCenter with "Use Windows session credentials", or I would get a standard error stating that the username or password is incorrect.
Did you find a solution?
We have exactly the same prerequisits and exactly the same problem.
After the old DC was removed VCenter no longer works.
Strange enough. AD is healthy and all other services like Exchange, SharePoint, MSSQL work without a problem.
Why is VCenter still referencing the old DC which no longer exists?
Seems that it is hard coded anywhere in VCenter configs during install.
Regards.
Try creating an alias record for the old DC which uses the IP of the new DC. That old name is hard coded somewhere, if you search the logs on you SSO server you'll find references and errors pointing to the old DC.
Let me know how it goes.
Duncan.
Sent from my BlackBerry device on the Rogers Wireless Network
Hi dbutch1976,
creating an alias is not possible for us as the old dc still exists, but is only a member server now after demoting.
But I'm sure it would work around the problem.
The question remains what is the root cause of the problem.
My additional findings you can find here:
http://communities.vmware.com/thread/431783?tstart=0
Thanks for your help.
Problem solved.
You find our solution here http://communities.vmware.com/thread/431783?tstart=0