The x86 based Microsoft Virtual Server 2005 R2s took the Service Pack 1 with no issues. Both machines were happy with the update.
The x64 based system with a host OS of Windows Server 2003 R2 Standard x64 SP2, which is also hosts the Admin Site via HTTPS/Host Header, choked:
Security Alert - Driver InstallationThis is where it gets really fun.
The driver software you are installing for:
Microsoft Virtual Server Storage Bus
has not been properly signed with Authenticode(TM) technology.
Therefore, Windows cannot tell if the software has been modified since it was published. The publisher's identity cannot be verified because of a problem:
The parameter is incorrect.
Do you still want to install this software?
No matter which option, Yes or No, we choose we get:
We tried everything we could come up with to get the Service Pack to take. Nothing worked.Rolling back action
Now, since we did the admin system last, we were stuck as none of the production VMs were online as a result of those systems receiving the Virtual Server SP1 too. Not even the Virtual Machine Remote Control Client Plus could connect to any of the virtual servers to get those machines started. We were completely stuck.
Things would not be so bad if we could find anything relevant on the Internet in relation to this error. But, we hit the brick wall ... and hard. There is seemingly nothing out there about this specific problem applying Virtual Server 2005 R2 Service Pack 1 to an x64 Enterprise based Virtual Server install ... nothing!
Since this was a business critical situation, there were production machines down, we needed to call the Partner Support Hotline to take advantage of our Partner Perk of free business critical support.
After obtaining our SRX0711... number, we were put on with Vaseem A. who listened intently to the situation. We had to connect to an MS support site to allow him access to the server desktop. Once connected, and he had control, we got to sit back and watch. ;)
It is not too difficult to get first impressions by the initial steps a remotely connected person goes through. Especially for those of us who have a good chunk of server management under our belts. Vaseem demonstrated an excellent level of knowledge and understanding of the products he was working with: Windows Server 2003 R2 Standard SP2 as the host and Virtual Server 2005 R2 as the virtual server.
Even then, it took some time to figure out what the source of the problem was.
A big clue as to what was causing the problem was found in C:\Windows\SetupAPI.log:
#W366 ... The parameter is incorrect.Vaseem ended up uninstalling Virtual Server 2005 R2 Enterprise x64 off of the machine, cleaning out the Program Files directory, he exported the MSVS registry settings then renamed them "settingkeyold". The server was then rebooted. Vaseem then ran the VS 2K5 R2 SP1 install routine again. The error did not return!
...
#W360 ... The certificate is not valid for the requested usage
...
#E122, E157 ... Driver is not intended for this platform
When the server was rebooted, the host header and ports for the management site were properly set and the SSL certificate was set to the site, we had the Admin site came up. It took some time to get to this point, so before we allowed Vaseem to continue, we fired up the VMs on the other two servers so at least the critical production systems were back online. Since this is a Constrained Delegation setup, we were able to confirm that the setup was still functional when we were able to connect to the other x86 based Virtual Servers.
After all of this, the Virtual Server service refused to start on the server we were working on! :(
An examination of the directory that Virtual Server installs to showed that the files were all correct, we checked the permissions on the VM folders (in a non-standard location) and they looked correct, and verified the service settings in services.msc. All looked 100%.
What ended up being the cause of the VS service falling flat on its face was the registry settings. The Virtual Serverold key was still there as Vareem had left it ... but the Virtual Server SP1 install routine failed to create a new Virtual Server key.
So, uninstall VS 2K5 R2 SP1, clean out the directories, export the registry keys and this time delete all of them, reboot and reinstall.
After the server had rebooted, we made the necessary site port, SSL, host header, and IP settings changes to the VS site in IIS Admin, and we verified connectivity to the site. It worked, and showed all three servers available!
Wow! What a lot of work to get things up and running.
We fired up the final 4 VMs on the x64 box and said, "Whoo hoo!" :D
There are times where we have heard negative things about the over seas crew that Microsoft utilizes for some of their support duties. To date, we have been very fortunate that every time we have had the need to utilize the business critical support, they have come through in Spades.
Thank you Vaseem for helping us out of a bind! :D
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.
Hello Mr. I didn´t understand how you solve this problem, could you be more explicit, specialy when you mentioned registry.
ReplyDeleteThank you