Hi people,

2015 is almost 2 weeks old, and it already feels like we’re halfway through the year. Just a quick post I wanted to share with you all, about building, developing and testing an MDT environment that is going to be used for production purposes.

I often find myself forgetting to disable certain steps in MDT during testing, that effect’s the turnaround time a certain task sequence is taking. For example, testing an entire roll-out, from OS deployment up to application installation takes quite some time. And if you have forgotten to disable the Windows Updates step, during this test, and new updates are available, you’ll lose valuable time that could have been spent otherwise, whilst Windows Updates is a guaranteed step in your task sequence that works.

Or another example, Windows Activation, against KMS or MAK, should that run when testing?

OK, so we can create development task sequences, copy tasks back and forth. But what about making things less complex and work with something cool as Custom Properties?

So this is how I have setup my customsettings.ini for a project I’ve been working on:

script 1.1: CustomSettings.ini Properties

Using the custom property: “MDTStatus” I can easily use this as a Task Sequence Variable condition on all the steps that I would like to include or exclude during development, testing and production:

figure 1.1: MDT Status on Windows Updates

figure 1.2: MDTStatus on Windows Activation

Now to quickly assess this, there is an easy way of processing these settings in the CustomSettings.ini against the designated TaskSequence:

script 1.2: Executing the ZTIGather.wsf script

Upon execution, you will see that the ZTIGather.wsf script, starts evaluating with the CustomSettings.ini and designated Task Sequence in mind:

figure 1.3: Evaluating CustomSettings.ini and TaskSequence with ZTIGather.wsf

When the ZTIGather script is finished processing, you’ll find the following folder in the root of your C:\ Drive: “C:\MININT\SMSOSD\OSDLOGS” and within that folder you’ll find the BDD.log which is used by MDT to echo all actions of the steps that are executed back to this particular logfile.

In this logfile you will find the following:

figure 1.4: Custom property added

figure 1.5:  Custom property picked up

And there you have it, setting an entire MDT environment in a certain mode enables you to perform testing without being bothered with steps that impact the turnaround time, or make you spill your MAK keys for no other reason then testing.

Cheers! Rens