Ditto it works
I also have no problems with SQL2005 and VC 2 on the same maschine.
Its pretty stupid that officialy according to documentation just the SQL 2000 is suported, for which you can not purchase licenses any more.
What would also interest me if in case you have some major issues you really do not get any support from VMware, something like "You have to use Oracle"...
But from my experiences until now with support the VMware staff is very competent and do their best to help!
I had VC 2.0.0 working just fine on with 2005, but VC 2.0.1 is not. I have assigned the DSN account as dbo in 2005 and no joy. Please confirm that 2.0.1 is working, because I cannot get it to work. I get an error when the installer attempts to create to the tables.
I understand the support/works philosophy. If I cannot get it to work again on 2005, I'll revert to 2000. All of our sql clusters have been updated to 2005, and so I had our VC 2.0.0 db on it, albit unsupported. If I have to revert to MSDE, I will. I just want to throw it out to the community and ask. Has anyone gotten 2.0.1[/b] to work with SQL 2005?
I brought up a temp SQL 2000 server and configured it in the same way; and behold, same problem. After further investigation I found it was not SQL 2005, but the length of my password. I use a 64-char complex password for my service accounts and there is something that the 2.0.1 installer does not like about them. After reducing my password to 32-char, all is well again. This also explains why sa would not work either. Even though it is local, it is also a 64-char password.
I hope this helps someone else that uses long passwords.
This problem was not present in the 2.0.0 release. If you plan to upgrade to 2.0.1, shorten your passwords to 32-char or lower.
It's not like I ever have to actually type them out. This is the first time my insane security policy has bitten me.
The crazy part is it does not matter if it was sql or NT auth. If the password was 64-char, it failed. I think there is something in the VC installer that is broken. During the ODBC configuration, everything passes, but once the installer attempts to use this information when creating the tables, it fails. I think some of the password is getting cut off from the time you configure the ODBC info till the time the installer attempts to create the VC repository.
I had a similiar issue with the vmware VI client. It doesn't support spaces in the password.
What's with the artificial password limitations? Like it's that hard to code for support of characters. In fact, it seems they had to write more code to not allow it, than to allow it.
Make your root password on an esx server one with spaces in it and with a space at the end. Now try to log in from VI remotely.
No worky. Now try making it the same password without spaces. Works.
Message was edited by:
Message was edited by:
email@example.com to shorten the URL
The installation documentation (http://www.vmware.com/pdf/vi3_installation_guide.pdf) still shows SQL2000SP4 as a requirement with no mention of SQL2005 which means it's unsupported. Yet, the VMware KB says SQL2005SP1 is now supported.
VMware, please update the documentation This is an important piece for the infrastructure and can easily be a showstopper planning the environment without the proper back end DB. It was for us. We had SQL2000SP3a but now SQL2000SP4 or SQL2005SP1 which meant we had no supported SQL environment for VC2. Due to this, we had to use Oracle 9iR2 as our back end database which we did have in house already.