Configuring Microsoft Deployment Toolkit can range from the simple, default configuration to a heavily customized, post-installation process that supports all your devices and meets your organization's needs.
That's no easy feat, but with proper planning it can be achieved in an organized, efficient manner. Even so, once all the pieces are in place, you've got to test it, right? Many variables can be involved—the make/model of computers, various OSes, software versions, and device drivers are chief among them—so the process to test each possible combination can be daunting.
To refocus your efforts on correcting the errors and not on the items that aren't working properly, you can leverage MDT's own scripts, combined with our carefully written settings files, to execute an offline test of the entire process that will bring to light any errors. That way, IT can fix configuration problems before rolling out physical deployments.
This method will also save IT untold amounts of time, since a typical deployment scenario may run from 20 minutes to several hours, depending on the load placed on the servers. Deploying 300 computers simultaneously for a one-hour deployment period only to discover that the configuration did not name computers according to site standards, then joining them to the domain, will equal several hours of work to clean up the mess created during deployment—only to have to redeploy all the stations once again after the configuration error has been fixed.
Below are the requirements necessary for testing a deployment's configuration:
- Server running Windows Server 2008 (or later)
- Windows Deployment Services (configured with boot images and multicast, if needed)
- MDT (finalized deployment configured and populated with OS/drivers/software)
With the requirements out of the way, let's look at two methods for testing your MDT deployment without wasting valuable time and resources.
This method is one the quickest in my opinion and the simplest once all the necessary information is available. It is used to test the configuration of the CustomSettings.ini (CS) file on deployment. However, the test is based on the type of client being used to execute the script. In other words, if your CS file has logic to discern by ClientType to push one configuration for servers and a different configuration for laptops, you'll need to test this script from a server to yield the "server configuration log" and again from the laptop to yield the "laptop configuration log."
Start by creating a batch file and editing the contents to include the snippet of code below and then save it accordingly:
del C:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT /q cscript C:\DeploymentShare\Scripts\ZTIGather.wsf /Debug:True /inifile:..\Control\CustomSettings.ini notepad.exe c:\minint\smsosd\osdlogs\bdd.log
Note that the path after "cscript" is that UNC path or file path to your deployment share's Scripts folder and more accurately, the ZTIGather.wsf script file.
Next, execute the batch file and watch as the script scans each line of code in your CS file and processes it, without ever executing the actual processes to invoke the deployment process (Figure A).
Once completed, the full log will be output to Notepad, where it may be saved for further analysis to detect errors in the settings and configuration, respectively.
Note: This test may also be run on the Bootstrap.ini file to verify that those settings are indeed configured properly as well (Figure B).
Unlike the full test method above, this one requires an SCCM license to make use of the Configuration Manager Trace Log Viewer (CMTrace) tool that comes bundled with SCCM and the SCCM Toolkit to view log files generated by SCCM or its components.
This tests only for a specific TaskSequence (TS) called from the command to be run. It's exceptionally helpful in determining how a TS will function after modifications have been made to it or when you want to test only certain components instead of the entire deployment share.
Begin by launching the command line and executing this command:
cscript C:\DeploymentShare\Scripts\ZTIGather.wsf /inifile:..\Control\CustomSettings.ini" /tasksequenceid:TS001
The command will execute the entirety of the TS without actually invoking the deployment process and will save the log file to the following path where it can be opened by the CMTrace application to view the contents of this particular log file (Figure C)(Figure D).
At its heart, MDT will work differently depending on the needs of each organization, but one thing that is universal across each scenario is to test, retest, and test again your deployments for errors and to ensure the maximum level of compatibility for each supported device.
- MDT: How to automate deployments using CustomSettings.ini (TechRepublic)
- MDT: How to automate deployments using Bootstrap.ini (TechRepublic)
- How to set up Microsoft Deployment Toolkit: Step by step (TechRepublic)
- MDT 2013: Create a simulation environment for your PowerShell Scripts (Operating System Deployment Couture)
Do you have any deployment horror stories to share? How about tips on testing MDT deployments? Please share your thoughts below in the comments section.
Jesus Vigo is a Network Administrator by day and owner of Mac|Jesus, LLC, specializing in Mac and Windows integration and providing solutions to small- and medium-size businesses. He brings 19 years of experience and multiple certifications from several vendors, including Apple and CompTIA.