Setting Up An MDT Test Environment and Workflow

I’m not going to waste time going over how to install the Windows 10 ADK and MDT. There are guides all over that cover that topic well. Instead I’m going to explain my strategy to implementing this setup so that I can affect a crude form of versioning and testing and afford myself some flexibility in the environment.

The goals here are simple:

  • Have the ability to experiment with changes without risking the production environment
  • Being able to hold on to changes that work and still have a space to experiment
  • Be able to easily revert to a working setup when experiments muck things up

So, with that in mind, here’s what my setup looks like. I have 4 deployment shares: two on my admin workstation, and 2 on our MDT server. One of the shares on my workstation is a “build” share that used solely for generating reference images. Booting a VM from the litetouch ISO in this share automatically deploys and configures Windows, installs Office 2016, and installs all updates from our WSUS before sysprepping and recapturing. This is a special purpose share that may or may not have utility in your environment, so lets just ignore it for now.

The other share on my workstation is a “development” share. As I’m working out problems or experimenting with a new OS or whatnot, I do everything in this share. Nobody uses this share but me, so it’s segregated and safe from the production environment. There is, however, a couple of limitations of this share. Once I have something completed in the development share but am not ready to post it to the production share, what do I do with it? Also, if I have a problem mostly worked out but need to continue experimenting, I need somewhere else to save my progress. Enter the “testing” deployment share.

The testing share exists on the MDT server. As I make significant progress on an issue, it can serve as a staging ground to store that progress while I continue experimenting. This way, should I hose things up afterwards, I can just grab another copy of the testing share and try again. It’s also a place where I can push changes to from my development share to ensure it merges correctly with existing files before then moving those changes to the production share.

The last share on the MDT server is, of course, the production share.

The method by which I “push” my changes around are with linked deployment shares. You can easily create linked deployment shares by right clicking the “linked deployment shares” folder under “Advanced Configuration” for a given deployment share. You have 2 different types of replication for these, and they are Merge and Replace. I typically use merge for pushing changes and replace when something goes wrong.

Here’s how I have it set up: Development share (Merge)=> Testing share Testing share (Merge)=> Production share Testing share (Replace)=> Development share Production share (Replace)=> Development share

With a setup like this, I can push changes back and forth between the development and testing shares, I can promote a testing share setup to the production share, and I can recreate the production share in the development share for a clean slate. Notice that there’s no way to sync to the production share directly from the development share. I also migrate to the testing share first and do a test deployment to ensure that the sync didn’t overwrite something it shouldn’t have or cause some other sort of general wierdness.

This setup keeps the production share clean, stable, and ready for use while I continue to tinker and improve things.

A few things to note about using Linked Deployment Shares:

  • You have to configure the properties, CustomSettings.ini, and Bootstrap.ini for each share individually. They do not copy over during a replication.
  • You can copy and paste your CustomSettings.ini between them for the most part, unless you have a path included in it that points to a specific share. Then you’d obviously have to update that part for each one 😛
  • You can copy and paste your Bootstrap.ini between the shares too, but be sure to update the DeployRoot to reflect the UNC path to the specific share.
  • You should to run “Update Deployment Share” for each share to get boot media to use with testing each share.

Hopefully you find this helpful. This setup may not work or may be overkill for your environment, but you can always take the parts you like from this and make your own variation that best suits your needs. At the vary least, hopefully I’ve given you some thoughts to consider when contemplating your own OS deployment setup.


MDT Enables UAC for Built-In Administrator Account

After setting up MDT for our organization, a coworker pointed out some issues with starting a new litetouch deployment from within an existing Windows 10 installation. When I saw it, it was obvious the issues were related to UAC. The problems were:

  • The user was being asked for network credentials immediately at the beginning of the wizard.
  • After answering all of the questions and completing the wizard, the computer would reboot into PE and proceed to start the whole wizard over again, forgetting all of the previously provided answers.

I checked and found, sure enough, the local policy “Enable app approval mode for built-in Administrator account” was set to enabled. I couldn’t figure out where or how this was getting set, so I ran some test deployments and found MDT itself was turning this on at the very end of a litetouch deployment!

Turns out, this is set this way by a few lines near the beginning of the LTICleanup.wsf file. Microsoft did this for versions of Windows 8 and above so that the built-in Administrator account could open Windows modern apps, such as Edge. I’d never encountered this issue before because I’d only ever used MDT with Windows 7 in the past.

I disagree with this decision not only on the grounds of it being mostly useless and worse, encourages people to use the Administrator account for daily use, but also because it causes the before mentioned issues on future MDT deployments.

To fix this issue, simply comment out lines 144-150 in LTICleanup.wsf that reads:

If oEnvironment.Item("OSCurrentVersion") <> "" then
  If ((oUtility.VersionMajor = 6 and oUtility.VersionMinor >= 2) or oUtility.VersionMajor >= 10 ) then
    oLogging.CreateEntry "Re-enabling UAC for built-in Administrator account", LogTypeInfo
    oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken", 1, "REG_DWORD"
  End if
End if 

You can comment each line by simply adding an apostrophe to beginning.

You can find LTICleanup.wsf in the Scripts folder of your deployment share.