Hello,
Am running VMWARE Workstation 5.5.1 build-19175.
I have a windows xp pro installation that fails to find the domain every time it is started. It has been connected to a domain before and acted as part of the network, but everytime I shut it down it 'forgets' that it was connected to a domain. I get the error message 'Windows cannot connect to the domain, either because the domain controller is down or otherwise unavailable or your computer account was not found'.
I can fix the problem by rejoining the domain, but that is getting very tedious.
Does anyone know why this is happening?
Thanks
bmak
As to why no,
Are you creating a snapshot when you power down the guest ?
The behaviour you describe is very common when you revert to a snapshot, I haven't seen having to unhook and rehook every time you use the guest
The active directory "removes" the VM computer from the domain, so as you say its unhook and rehook ![]()
Hello telfred,
In fact I have tried both. To start with this VM was not making use of snapshots, but in an attempt to stop the repeated domain rejoining I enabled snapshots and took one prior to a shutdown. Still no joy.
It's a pain because I am now finding other ways to get the job done that don't require a VM session.
bmak
Talk to your domain administrators it may be that the active directory group policy settings are what are causing all this fun and games !
You'll know alot more about Active Directory than me then, something we have tried here is related to changing SIDs, I don't know whether that helps explains things.
Hello,
Yes, it could be SID related, but that get's taken care of when you introduce the image to Vmware in the first instance (this was created on the same version of VMware but a system crash resulted in a reinstall - the image was then reattached to the new installation). Once VMware sees that it is an existing image it asks the questions about recreating the ID and gives the warning about Windows XP activation.
I would not expect the SID to change between sessions either. It will see the first time round that things have changed, but nothing changes after that, and the snapshots will back this up I think.
bmak
bmak I also have this problem all the time. If I find something out I will let you know.
check out this post:
http://www.vmware.com/community/thread.jspa?messageID=187305𭮩
And this one:
http://www.vmware.com/community/thread.jspa?messageID=349340񕒜
W2K, NT - workstation loses connection to Domain
After a Revert (and/or Discard) loses those VM the connection to the domain. Why?
To the Authentifizierung between PC and server (domain) so-called machine account password is used. This changes itself for safety reasons cyclically. If VM by means of Revert on one old conditions is put back, is not correct the password PC any longer with that the server.
With the following Registry key one switches that automatic changes of this password off:
HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters DisablePasswordChange REG_DWORD 1
If the password ran off once, helps in short removing of the VM from the domain and after the restart a renewed Take up to the domain! Then equal the above Registry keys change and one new Snapshot make!
The above is a poor translation from German to English but some have said this works. I will be trying this out on my next build attempt.
Hello,
Yes, it could be SID related, but that get's taken
care of when you introduce the image to Vmware in the
first instance (this was created on the same version
of VMware but a system crash resulted in a reinstall
- the image was then reattached to the new
installation). Once VMware sees that it is an
existing image it asks the questions about recreating
the ID and gives the warning about Windows XP
activation.
Actually, No. VMware changes it's own UUID and MAC address of the virtual NIC. It has no knowledge about the Microsoft SID inside the guest. You need to run SysPrep or NewSID or similar application inside the guest to change the guest's SID.
Rob
First this is not a sid issue and yes what I posted earlier for a resolution did work.
Microsoft Article:
http://support.microsoft.com/kb/154501/
Message was edited by:
lawson23
Hi, I have a quite similar problem with WinXP guest logging to the domain. After I revert to the last snapshot I can login just once, but after that if I reboot the guest the next login fails. This happens with two of the clones, others work fine. These two also worked fine for about one month after they were created. I changed the DisablePasswordChange value to 1, but it wasn't any help. Any suggestions?
Btw is there a way to build linked clones so that I don't have to install each and every Windows update to every clone separately?
-Tapio
Besides the previous posts in this thread, I have not had any problems cloning machines (and reverting to previous snapshots, this has been my procedure.
This is because if the image is a Domain Host, whenever I cloned/copyed the machine I would want to disjoin from the Domain, so this saves that step.
Prep the Machine before joining the Domain[/b]
1. Change the Hostname.
2. Verify the chosen Hostname does not already exist in the Domain. If that name is still to be used, .
3. Verify the NIC MAC address has been changed.
Note that this procedure is not different than what should be done when joining new physical machines to an existing AD, this ensures...
1. No previous machine SID should exist in the AD. Notice this is "should" - because you never really know what inconsistencies and orphans might already exist deep in a machine. To be certain, always use a name that is almost certainly never used before.
2. The AD Computername account SID is always re-created when joining a new machine to the Domain. If an account already exists, it's problematic whether a new machine SID may be created. Note that if the AD Computername SID is unique (ie re-created), that is all that is needed to ensure the machine will co-exist properly with other VMs with the same original Machine SID.
Note also that when a VM is cloned or copied, if it is run on the same physical machine, the User is prompted to re-activate Windows. When you clone/copy the VM to another physical machine, Windows re-activation is required. I do not know that re-activation has anything to do with machine SIDs, but am almost absolutely certain there is no relationship because machine SIDs should be generated originally during Windows Setup.
Once you've joined the Domain and has "started its new life" you can create snapshots, but all previous snapshots should be disregarded/deleted.
Another -and possibly more elegant approach- is to create an OU in Active Directory and apply a custom policy that disables Machine Account updates only for the machine accounts in that OU. No registry hacks required! When a new VM is added to AD, just move the machine account into that OU and PRESTO! Snapshot away!
Here's more detail on that Policy setting:
http://technet2.microsoft.com/WindowsServer/en/library/2ee8cf56-7dcc-4c79-af46-737c40abbf8b1033.mspx
Yes, we have that solution implemented (with a separate OU for virtual machines and that policy set) and it has worked fine for a long time. But for some reason it does not work anymore! A resultant set of policy check shows that all is in order, but still as soon as I reverts to a snapshot I need to rejoin our domain!
I dont really know what has changed, nothing in the policys at least, but I'm using a new build of VMware (the latest one).
Anyone else with similar problems?
Yes of course that could happen, but I thought the policy below should prevent that password change thus making reverts ok?
(http://technet2.microsoft.com/WindowsServer/en/library/2ee8cf56-7dcc-4c79-af46-737c40abbf8b1033.mspx?mfr=true)
Domain member: Disable machine account password changes
Description
Determines whether a domain member periodically changes its computer account password. If this setting is enabled, the domain member does not attempt to change its computer account password. If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days.
Default: Disabled.
It would be easy to determine that, based on event logs. Did you check them?
Yes I ofcause have events that indicates problems with the machine account (eventid 3210 among others). I still think that policy should have taken care of this (and it has done so in the past). Also, logging in locally and checking the registry tells me that that option is in effect (DisablePasswordChange=1).
Perhaps the snapshots were taken before that domain policy went into effect (and therefore the machine's passwords in the snapshot are not the same as they are now)?
