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.

Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *