Troubleshooting vCenter Service startup issues

There are lots of reasons a vCenter Service would not start up.  The usual suspect is an unavailable SQL database.  ESPECIALLY when the SQL database is LOCAL to the vCenter server.  I know that statement might seem illogical since by having the SQL database on the same server, you are basically eliminating all network related connectivity issues.  The reason it is a common issue for single host solutions though is timing.  Most times during the server boot, the SQL server service is not up and running by the time the Virtual Center service is attempting it’s startup.  This results in a failure due to an inaccessible database.  This can usually be verified if after logging into the console, you can just start up the service without issue.

A good preventive measure for this is to add the SQL server service as a dependency for vCenter.  This will force the service to at least wait until SQL is up before trying to start up vCenter.  VMware has a pretty detailed KB article @ KB Article: 1007669.

So this is USUALLY the case.  Occasionally though, you will come across an ACTUAL SQL ERROR.   Today, I ran into an issue where my vCenter Database was marked as ‘Suspect’.  This prevented any access to the database and of course caused the VC Service to fail on startup.  Inspecting the VC logs (C:\ProgramDATAVMwareVMware VirtualCenterLogs), I noticed an error referring to “[Microsoft][SQL Native Client][SQL Server]Login failed for user ‘NT AUTHORITYSYSTEM’.”

After firing up the SQL Management Studio, I saw the issue.

Some quick Googling around lead me to the following resolution.
Be aware that the commands do include a ‘REPAIR_ALLOW_DATA_LOSS’ statement but in my limited vCenter environment, no data was actually lost.  After running the SQL query, the VirtualCenter Service started right up.  I imagine the SQL Express server must have crashed at some point sending the database into this ‘suspect’ mode.