During the development of a project, you may need at some point to automate the testing of your whole application. Virtual Machines make that very easy, especially with Visual Studio Lab Management in the loop.
You can have a step in your nightly build to have your application installed silently, and then have some acceptance tests running on it.
To make all this repeatable and mostly predictable, you can use snapshots of a clean environment and restore that environment before starting your test scenarios. That way, any previous test run does not affect the new run, as long as the tests can run confined in a single machine. For multiple machines tests, like a web front end and DB backend, you may need to synchronize all of the snapshots, but this is definitely doeable.
The case of the VM part of a Domain
Your tests may also need to have a domain account to run. To do this, you join your VM to the domain, then make a snapshot.
Your automated tests run fine for about a month, then start to fail for reasons like :
The trust relationship between this workstation and the primary domain failed.
Or something a bit different like :
This computer could not authenticate with \\MYDC, a Windows domain controller for domain MYDOMAIN, and therefore this computer might deny logon requests.
Which means that the machine account registered with the domain is out of sync.
For a bit of background, the machine account is used by windows subsystem, but also the "NT AUTHORITY\System" account to communicate with the domain to apply
GPOs, for instance. This account is also used for many other things, like in
SCVMM, to ensure that the server has access to a host without requiring a "real" account that has administrative access to that host.
Password Renewal
That machine trust account has a password like a normal user account, even though it is not accessible to the users. That password is changed periodically, every 30 days or so, and that change is initiated by a request of the machine tied to this account. It is designed in such a way that it allows machines to be offline for long periods and not get out of sync because the DC would have changed the password unilaterally.
At this point, you're probably seeing why that account information can be out of sync when using VMs and reverting to snapshots.
When joining the domain, the account is in sync, and it is possible to revert to that snapshot until that 30 days window is reached. Then, the live snapshot of the machine asks for password renewal of the trust account, and then you revert to your original snapshot. This is where the problem occurs, the machine cannot authenticate on the domain anymore because it is using the previous password.
Keeping the password in sync
There are a few techniques to keep that password in sync, the first being a leave and join domain sequence. This is fairly easy to do, but there are some caveats.
When you leave and re-join, you get a new SID for that machine, which means that if you gave access rights to the previous machine account on an other machine, you're forced to update your ACLs on that other machine.
But there is a lesser known technique based on the
netdom command, to reset that trust account password :
netdom resetpwd /server:MYDC /userd:MYDOMAIN\myuser /passwordD:* /securepasswordprompt
This needs to be run on the target machine, using an account that has the rights to update machine accounts, which is most probably the same account you used to add your machine to the domain.
Making it permanent
You still don't want to have to reset that password every two weeks, so you can use the
DisablePasswordChange registry setting for that, which will disable the update of the machine account password.
This will make your VM a bit more vulnerable to password based attacks to hijack your machine account, just so you know.