Let me start by saying that yes i did search the forum first 
I'm fairly certain there is a bug in the VC 2.5 installer, basically when installing with ADDLOCAL=VPX, the %programfiles%\VMware\Infrastructure\VirtualCenter Server\locale directory does not get created, thus causing the service to fail to start. Running vpxd -s throws the ol'
2008-01-09 18:39:36.178 'Locale' 5088 warning No supported locales in directory 'C:\Program Files\VMware\Infrastructure\VirtualCenter Server\locale/'.
2008-01-09 18:39:36.178 'Locale' 5088 error No locale directories found in 'C:\Program Files\VMware\Infrastructure\VirtualCenter Server\locale/'.
2008-01-09 18:39:36.225 'App' 5088 error Locale Init Failed. Check for outdated or missing locale files in configured locale path or current directory.
2008-01-09 18:39:36.225 'App' 5088 error Failed to initialize: Locale initialization failed.
2008-01-09 18:39:36.225 'App' 5088 error Failed to intialize VMware VirtualCenter. Shutting down...
2008-01-09 18:39:36.225 'App' 5088 info Forcing shutdown of VMware VirtualCenter now
There are several other threads that suggest this is due to some kind of database corruption, but that is not the case - I can reproduce the error with 100% accuracy either by installing VC without the ADDLOCAL argument, or even copying off the %programfiles%\VMware\Infrastructure\VirtualCenter Server\locale directory from a successful install, and simply pasting into a broken one (ie without touching the database at all).
Can anyone else out there reproduce this? I'll log a bug report if someone can confirm.
Thanks Jason - will give you some helpful points for that
Just for the record, this is a totally clean install, both database and VC (and they live on separate hosts). But yeh, there are a few odd things regarding SQL that vpxd does in 2.5... for example, when creating the SQL Agent jobs, the first thing the sql script (job_schedule1_msssql.sql for example, in the same directory as vpxd) does is to chk for the existence of a job with the same name, then delete it if it finds one. However by default there is not a SQL role that I know of other than 'sysadmin' that has the rights to delete SQL Agent jobs (there's a question for you to ask on your course!), and even if there was I don't think any self respecting enterprise DBA would give it to the SQL n00bs like us who run the virtual infrastructure, just as we wouldn't give them datacenter admin rights in VC. So when I ask them to create and permission a database for VC's use, i get db_owner on my database, and some low level rights on the msdb system database, and that's all I need for VC to install and run quite happily. However, AFAIK SQL Agent jobs are configured on a per instance basis (there's another question for you to ask), so say I had a SQL utility that hosted multiple databases under the one instance, then my next VC install will fail because it will try to delete the existing jobs and not have the rights to do so :(. But even if it did have rights to delete the existing jobs, it shouldn't do so because I need them for the original database! So either I have to automate the renaming of the jobs so they are unique, or I have to have multiple instances, one for each database, which is not optimal when all the databases aren't very large or resource intensive as far as enterprise databases go, and there is more SQL overhead associated with multiple instances as opposed to multiple databases in a single instance.
I know it's just a case of the VC devs making setup as automated as possible and assuming the DBA is the VC admin is the Windows admin etc etc, but it would be nice to have some kind of option to turn some of the extraneous stuff off, or at least have it fail and continue with the rest of the database initialisation.