well I hit a big one today in trying to assist my client to set up a virtual network for testing our software application.
In order to work with (and test the software myself) I had bought and installed VMWare workstation ver 6.5 on my dev machines. Since I had already gone to the trouble of setting up a virtual network that I had deployed on my machines, I thought we would just ship the images off to the client and they could install them… And thus the problems began.
First up, the client didn’t have VMWare 6.5, but instead 5.5.5, so after I had discovered that I had to export the images as downgraded images. No problem there, and indeed we got them up and running on the client’s machine. The first problem cropped up, once we got everything running. The Virtual Domain was happy… but the mouse was choppy and just plain weird when ever it was over the vmware image. A little digging around revealed that the mouse behavior was overseen on the image by the VMTools, and that’s where I started to go down the rabbit hole!
As you can see, I had put the VMware tools on the domain controller when it was created on my machines in VMware 6.5 (giving me tools of 6.5) but the client’s workstation was 5.5.5, so VMware tools were not “playing” nice with their containing VMware workstation.
OK easy peasy, right… not so fast. I’ll skip some of the drama I went thru but basically the problem turned out to be this… When the VMware tools were ver 6.5, or when they were removed from the image all together the GroupPolicy system (and the RSOP snap-in) operated the way it was supposed to.
But just uninstall the 6.5 tools, then reinstall the 5.5 tools (that go with the workstation) and Viola, you have a broken domain controller.
I’ve spent the last day and a half trying all the “fixes” I can find for a sysvol permissions issue (which this clearly is) and in the end, I’ve decided to tell my client, either rebuild the network from scratch, or spend the $400 dollars and upgrade to 6.5 VMware workstation…
I think the smart thing will be to upgrade…
Well I thought about it a bit and it cogitating on what I had read when I was trying to fix it using technotes, it occurred to me that quite a few of the notes talked peripherally about “… process not able to contact domain controller…” so I decide to look at what options are installed on the client when the VMware tools are pushed in (I used the Custom Install), and first up, I don’t have scsi so no need to install that, and then I saw that they had an option to “improve” the network card.
Network, communication, failure… so playing a hunch that modifying the network process was a bad idea on the domain controller, I decide to skip that part of the VMware tools.
Unfortunately, that had no effect. upon completion of the VMware tool installation here is what I get when I try to look at the group policies for the domain
Click ok here gives
And finally the final SNAFU:
If I can come up with a work around, I’ll amend this entry to let you know what I found.
If you look at the first image in this blog you will notice that the client is using Ver 5.5.1 of VMware workstation. After I was done posting this entry, I basically threw up my hands and said, “never going to happen”. But then while trolling thru the VMware website, I saw that there was an upgrade to the version of 5.x ver of workstation basically 5.5.9 and the update was free for my client’s license. So figuring if I was going to ask the client to upgrade to 6.x which would cost money, let’s try the 5.5.9 free upgrade (that I was sure wouldn’t work).
And what do you know? It Worked.
After installing the 5.5.9 upgrade I started up the domain server, installed VMware tools, and whoo hoo, it was a happy camper. So now I can get back to my REAL work.
Moral of the story. Upgrade as far as you can for free before paying for a more advanced upgrade.