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.

SEE: Windows Server 2016: The smart person’s guide


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)
  • DHCP
  • DNS
  • 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.

Testing CustomSettings.ini

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:

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).

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).

Figure B

Test TaskSequenceID

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).

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.

Also see…

Your take

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.