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
1 2 3 4 5 6 7 |
[Settings] Priority=ByLaptop, ByDesktop, Model, Default Properties=MDTStatus [Default] ; Status of the MDT Environment: "Development", "Testing", "Production" MDTStatus=Testing |
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
1 |
cscript E:\DeploymentShare\Scripts\ZTIGather.wsf /inifile:"E:\DeploymentShare\Control\CustomSettings.ini" /tasksequenceid:OSD002 |
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
Pingback: MDT Tutorial Part 11: CustomSettings.ini Validation Testing & Troubleshooting Part 1 | IT in Legal