jump to navigation

New Tool: Advanced Format Drives April 29, 2011

Posted by keithga in Troubleshooting, Uncategorized, Windows 7.

Been slacking lately (Working on MDT 2012).

Advanced format drives are coming!


This hasn’t been much of a problem until recently, now that most of the major hard drive manufacturers have started to switch over to full Advanced Format.

When you have an Advanced format drive, you should format with an operating system that can format the drive aligned on the advanced 4k sectors rather than the 512 byte sectors found on older drives.

If  you do not format an “Advanced Format” disk aligned on the 4k sectors, then you may experience performance degradation. Windows 7 SP1 has been updated to address Advanced Format Drives, and WinPE 3.1, contained in WAIK 3.1 has been updated as well.

But how do you know if you need WinPE 3.1?

I have just written a new tool: IsAdvancedFormat.exe, that can detect if there are *any* advanced format drives present on the local machine. It will return errorlevel 0 if there are no advanced format drives, and errorlevel 42 if there *are* advanced format drives.

Source code is included.

Sample Output!

C:\> IsAdvancedFormat.exe
Enumerate all detect all Advanced Format Drives.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: WDC WD10EADS-11M2B2
  Emulated sector size is 512 bytes.
  Physical sector size is 4096 bytes.
C:\> @echo %ErrorLevel%



Update! (7/24/2011)

It appears that Dell has taken this tool and enhanced it! Their new tool can detect if an Advanced Format drive was partitioned/formatted incorrectly.  Cool Stuff.

Since Dell’s tool is now a superset of my tool, I would recomend theirs first:  http://del.ly/afhdd 

I will continue to provide my tool here as a reference.

Thanks Dell! (and thanks Warren Byle)


Duplicate Driver Tool. January 10, 2011

Posted by keithga in MDT 2010, PowerShell, Troubleshooting.
comments closed


I just created a PowerShell script that can automatically detect duplicate drivers within a MDT Deployment share. For those of you who are not manually associating each driver to a specific Make and Model, this can help in trying to find drivers that are duplicates, or drivers that have been replaced by newer versions.

Typically having more than one driver in your MDT database won’t cause any errors during OS Installation, Windows will automatically determine the best driver out of all possible matches, and install only that one. However, as a Driver Database gets larger and larger, the MDT console may operate slower, and the installation process will also slow as MDT copies more possible driver matches.

This script is not a fully automated process. The output of the script is in text format, and the administrator must manually remove the drivers marked as duplicate/deprecated.


…\DupeDriverTool.ps1 [[-SelectionProfile] <String>] [[-DPDrive] <String>] [[-DPShare] <String>] [-WhatIf] [-Confirm] [-Verbose]

DPShare – By default, the script will use the First Deployment share found on your local MDT Console. Override using this parameter.

SelectionProfile – By default the script will use the “Everything” Selection Profile Group, override using this parameter.

Verbose – Use Verbose to display more debugging information and to display a list of OK drivers at the end of the report.

Each driver package within the drivers.xml file looks something like:

<driver guid=”{1d30e8a3-f9ca-479f-bc89-9c929c9f647f}” enable=”True”>
   <Name>Intel System dmi_pci.inf</Name>

Process Flow

The driver dupe tool runs as a PowerShell script, and must run on a machine with MDT 2010, or MDT 2010 Update 1 installed, as it uses some of the MDT PowerShell providers to manage the drivers.

The script will go through all driver packages and PnPID’s, looking for instances where two driver packages have matching PnPID’s. If we can do an intelligent job of determining which of the matching drivers contain the best version of the driver, we no longer need to maintain the drivers for the old drivers.

At the end of processing, the script will display a list of driver packages that are “safe” for removal. These are drivers where *all* PnPID’s are superseded by other “better/newer” drivers.

The Rules

  • Signed drivers are always preferred over unsigned drivers.
  • Signed driver dates are used to compare drivers, not driver versions.
  • Never modify any part of a Signed Driver, including the *.inf file. If you do so, the driver will no longer be signed.
  • It is always assumed that newer drivers are better than older drivers. If not, then you will need to manually keep track of which drivers are better.
  • Only driver packages where *all* PnPID’s are superdeded by better drivers are marked for removal.
  • Use the Verbose switch to see more detail while processing.


  • Find Out of Box Drivers that exist within the OS as in-box drivers.
  • Find Out of Box Drivers that exist within WinPE.
  • Automatically delete the drivers on the machine if dupes are found.
  • No SCCM support now, only MDT 2010.




Keith Garner is a Deployment Specialist with Xtreme Consulting Group

MDT Litetouch startup -Super Flow- help; November 11, 2010

Posted by keithga in MDT 2010, Troubleshooting, Windows 7.

Someone posted a question on a MDT forum recently:

I´m courious about what is happening when you boot your client on the WinPE iso image that is generated when you update the deploymentshare in MDT.

So, does a “superflow” or other documentation like that exist ?

Interesting question, thought I’d write down some of the basics (Things that are interesting to people in the deployment field):

  •  The Computer starts up and the BIOS is responsible for selecting which device to boot from. This can be either:
    Network (PXE), Hard Disk, USB Flash Drive, or CD-ROM (El-Torito)
  • When booting off a hard disk or USB Flash Drive, the BIOS will look for an “Active” partition, and run the code in the Master Boot Record.
  • PXE Booting is a different topic…  :^)
  • When booting from the CD-ROM, the BIOS will kick off the EtfsBoot.com program running in El-Torito No-emulation mode. ETFSBoot.com does two things:
    • Runs the BootFix.bin program – This program will test for the existence of any “Active” hard disk partitions on the machine, if found, it will prompt the user to “Press Any Key to boot from CD or DVD.” If no “Active” partition is found, or the user presses a key, then the next “BootMgr” program is run.
    • Bootmgr – ( In windows XP it was ntldr) Is responsible for management of the other Operating Systems, it reads the \boot\bcd file (a registry hive), and displays a menu to the user. It can launch Windows, WinPE, other Real Mode programs, and even boot Windows from VHD files (for premium versions of windows like Windows Ultimate or Enterprise).
  • Once the OS has been selected, BootMgr then starts the process of loading all the OS components into memory, when ready it will pass control from Real Mode into the Windows Kernel. The OS will then take over the boot up process and continue loading the rest of the drivers and components. If at this point it can’t find the hard disk from where it came from, it will Stop BugCheckEx(), with error code 0x0000007B, typically this means the Storage Driver wasn’t loaded.
  • In WinPE the process continues by calling WinPEShl.exe. If WinPEShl.exe finds the file WinPEShl.ini, it will parse it. For MDT 2010, the WinPEShl.ini file looks like:
  • BddRun.exe – Will launch wpeinit.exe. It will also remain in memory and monitor the keyboard for F8 (See: http://deployment.xtremeconsulting.com/2009/10/29/78/ )
  • WpeInit.exe will start up the network, and other services and parse the unattend.xml file for commands to run. For MDT 2010, the Unattend.xml file looks like:
<?xml version="1.0" encoding="utf-8"?>
<Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
  • Litetouch.wsf will then check to see if there are any Task Sequences in progress (is there a c:\minint and/or c:\_SMSTaskSequence\TSEnv.dat file present), and if so execute.
  • If Litetouch can’t find any in-progress Task Sequences (NewComputer), it will:
    • Parse the Bootstrap.ini file
    • Display the Welcome Wizard (unless SkipBDDWelcome is defined)
    • Parse the CustomSettings.ini file (Typically from the DeployRoot found in the Bootstrap.ini file).
    • Display the Deployment Wizard (Unless SkipWIzard is defined)
    • Run the full Task Sequence…


New Tool: ZTIAppVerify.wsf – Logs the status of all installed applications. November 8, 2010

Posted by keithga in MDT 2010, Troubleshooting, VBscript.
comments closed

Someone posted this question on a E-Mail list today:

Subject: Applications log file

Hi all,

I am working on building a LTI solution for Win7. [… is] there […] a simple solution to create a log file at the end of the deployment phase. This log file must contains a list of all applications installed in the task sequence.

It’s possible?

It got me thinking, and I realized that I *had* created a script to perform this exact same problem early this year, yet never posted it here to my blog.

So without further delay:  Introducing new tool ZTIAppVerify.wsf!


This script performs two tasks:

  1. 1. It will enumerate through the Applications specified in the Wizard, the CustomSettings.ini, and/or MDT Database. In other words, it will parse the Applications and the MandatoryApplications list properties and attempt to see if the installation was successful.
    How does it determine if the installation was successful?  If you populated the “UninstallKey” when creating your Application in MDT, that Key must then exist in the uninstall registry. For MSI applications, that UnInstallKey is just the Product Key. An Error is generated if the Key is not found (meaning the install was not successful).
  2. The script will also enumerate through all the Uninstall Registry Keys on the local machine:
    This is the list that is populated when you go to the Control Panel to remove an application (and a lot more). Note that output will contain the “UninstalKey” for use later on.

Just place this script in your MDT 2010 Task Sequence, somewhere *after* the ZTIApplication.wsf script(s) are run.

Sample Output:

For example, in the 2nd case listed above, the script will display a list of installed programs, the “UninstallKey”, and a friendly name for the application:

INSTALLED:   {23170F69-40C1-2702-0465-000001000000} \ 7-Zip 4.65 (x64 edition)
INSTALLED:   {25097770-2B1F-49F6-AB9D-1C708B96262A} \ System Center Operations Manager 2007 R2 Agent
INSTALLED:   {26A24AE4-039D-4CA4-87B4-2F86416017FF} \ Java(TM) 6 Update 17 (64-bit)
INSTALLED:   {29C93182-34F6-3275-A18D-59326851CD57} \ Microsoft Windows SDK for Visual Studio 2008 .NET Framework Tools - enu
INSTALLED:   {2F14965D-567B-4E59-ADEB-0A2CC1E3ADDF} \ Sql Server Customer Experience Improvement Program
INSTALLED:   {31E8F586-4EF7-4500-844D-BA8756474FF1} \ Windows Automated Installation Kit
INSTALLED:   {347F1DAD-AFF5-4F68-84F5-69AEB3EE1D24} \ Microsoft Deployment Toolkit 2010 Update 1 (5.1.1642.01)



P2V Migration for Software Assurance Beta 2 Now Available – with System Center Configuration Manager 2007 integration September 26, 2010

Posted by keithga in Announcements, MDT 2010, System Center Configuration Manager, Troubleshooting, USMT, VBscript, Windows 7.
comments closed


We’ve been busy here at Xtreme Consulting Group, recently Keith worked as a Developer on the P2V Migration project with Microsoft.

For more information on P2V Migration, click here.

P2V Migration adds documentation and support of System Center Configuration Manager 2007 Zero Touch Installation! 

What is better than spending a moment to kick off a completely automated process to redeliver an existing operating system as a virtual machine within a new build of Windows 7?
Answer: Making the entire process “zero touch” without necessitating a visit to the target computer or manually initiating the migration!

P2V Migration for Software Assurance can now be implemented using System Center Configuration Manager 2007 Operating System Deployment as well as native Lite Touch Installation with the Microsoft Deployment Toolkit 2010 U1. Computer refresh, replace and restore task sequence templates for Configuration Manager are included and documented in this Beta release.

clip_image001 P2V Migration templates integrated with Microsoft Deployment Task Sequence options in System Center Configuration Manager. Can be created and advertised as with other task sequence options.

Additional optimizations beyond Configuration Manager functionality included in this release are:

1. Better flexibility for backing-up and restoring VHD files using default file locations

2. Support for PCs using system and boot volumes

3. Globalization of scripts to handle varying regional and locale formats

4. General bug fixes and improved documentation

These fixes reflect the feedback of our Connect community and MVPs – thanks to everyone for submitting feedback!

Download P2V Migration for Software Assurance Beta 2 now:

P2V Migration for Software Assurance

New to P2V Migration for Software Assurance?


This solution was built to help unblock OS deployments by redelivering blocking users’ old Windows environments, applications and browsers seamlessly in Windows 7 using automated physical-to-virtual migration

P2V Migration for Software Assurance uses the Microsoft Deployment Toolkit, Sysinternals Disk2VHD and optionally System Center Configuration Manager 2007 to convert a user’s existing Windows XP or newer client environment to a virtual hard disk then automates the delivery of an updated and personalized Windows 7 operating system containing a virtual machine with the user’s previous Windows environment, applications and Web browser. The user’s previous virtual desktop retains its existing management components, domain membership and policies. The process also publishes applications and the browser for the user to access them seamlessly within Windows 7’s start menu.

How it Works

clip_image002 Completely automated process enables the previous operating system to be a child virtual machine inside the Windows 7 host.
clip_image003 Standalone application and Internet Explorer links published from virtual machine to native Windows 7 start menu. These applications can be launched individually using RemoteApp integration – without showing the entire virtual machine’s desktop.


Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Solving an Intermittent Format Problem November 17, 2009

Posted by tmintner in MDT 2010, Troubleshooting.
Tags: , , ,
1 comment so far

I received and interesting email yesterday from someone who was performing Lite Touch deployments and it seemed that randomly his deployments would fail at the Format and Partition Disk step in the task sequence.  Examining his BDD.LOG showed this error:

FAILURE ( 7705 ): command: FORMAT.COM C: /FS:NTFS /V:OSDisk /Y /Q   FAILED with error = 4

The first step I had him do was reboot the computer and run through the steps that the script ztidiskpart runs manually.  Those steps are:

  1. Boot in Windows PE
  2. Press F8
  3. Run diskpart
  4. select disk 0
  5. clean
  6. create partition primary
  7. assign letter=c:
  8. active
  9. exit
  10. format c: /fs:ntfs /v:OSDisk /Y /Q

Again the format command failed.  He then immediately tried the format again and it worked.  So this was truly an intermittent problem.  My suspicions went up that this was driver related and had him check what kind of storage controller is in the laptop and it was the lovely Intel Matrix Storage Driver.  I checked Intel’s web site and had him download the new driver from here: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17882&lang=eng 

After removing the old Intel Matrix Driver from his Deployment Workbench, adding this one back in, and regenerating his boot images it worked!

It was a great lesson for both of us and now hopefully you won’t have to go through as many steps.  If you ever run into any intermittent format or partitioning problems start investigating the storage driver!

– Tim Mintner

How to delete files that won’t delete November 11, 2009

Posted by keithga in MDT 2010, Troubleshooting, Uncategorized.
add a comment

One of the frustrations when working with beta software is dealing with constant changes and little support for cross-build (not major version) upgrading.

During the development cycle for MDT 2010, one component that had constant change was the Windows Automated Installation Kit. MDT requires several components from the WAIK to perform correctly, so we were constantly upgrading.

One of the components, the WIMGAPI.dll was particularly nasty. The WAIK installer would set the permissions on the file so regular users could not delete it, and the intra-build upgrades didn’t replace the file automatically. Luckily, if you are using the final released (RTM) version of the WAIK, and upgrading from a previously released version, you should be OK.

Why are these files so hard to delete?

Windows protects some installed files by giving only the “Trusted Installer” account access to the file, and explicitly denying everyone else access, including administrators and the SYSTEM account.

Running the icacls.exe command on wimgapi.dll reveals:

NT SERVICE\TrustedInstaller:(F)

The problem is that normal users and administrators don’t have full access to the file and are not allowed to modify the permissions.

How to Modify “Trusted Installer” files

If you ever find yourself in the situation where you need to modify/delete files that are “trusted installer” protected, here is what I do:

  1. Start up an elevated command prompt (with administrator privileges).
  2. Run “icacls.exe <file>” to see the current permissions.
  3. Run “TakeOwn.exe /f <file>” to change ownership.
  4. Run “icacls.exe <file> /reset” to change permissions.
  5. Run “icacls.exe <file>” to display the new permissions.




Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Windows Update in MDT 2010 November 9, 2009

Posted by keithga in MDT 2010, Troubleshooting.

I have a confession to make, ZTIWindowsUpdate.wsf was written by me, it’s my fault. When it works, it’s the biggest time saver for getting my machines up to date, when it’s not working, yes even I get frustrated. It was designed to fill problem of mine and still has some advantages for the right customers.

I wrote it back in 2007 when I was working for Microsoft IT. At the time, Microsoft IT didn’t have a good Update/Patching story, there were some tools that ran occasionally as part of Group Policy, but it was hard to tell if a given machine was up to date, and what the correct manifest of patches for a given machine were. I was setting up a Litetouch deployment server and wanted to ensure that each machine was up to date when litetouch was done.

ZITWindowsUpdate.wsf was designed to fulfill a specific task: Update the local machine to the latest Updates/Patches/Drivers from Windows Update (WU), Microsoft Update (MU), or a WSUS server.

When the script works, its great. Most of my Dell and HP test machines have great Windows Update Driver support, so I have to spend less time updating my MDT 2010 Out-Of-Box driver folder with the latest drivers. I also don’t have to spend too much time staying up to date on the latest patches from Microsoft (hello patch Tuesday). The script does a good job downloading the latest/greatest patches from Microsoft.

However, things are not always perfect, and it does require some work once in a while. This might be due to new packages that don’t install properly, or other problems.

Most of the changes to ZTIWindowsUpdate.wsf between MDT 2008 and MDT 2010 were changes to improve the robustness of the system if the package failed to install.

One example was a specific patch from Windows Update that would try to install, and fail. However it reported back to the system that it passed. The script would keep retrying, and get into an infinite loop. We added some better logic to ensure that ZTIWindowsUpdate would not get into those kinds of infinite loops.

By default, ZTIWindowsUpdate.wsf will install everything from the WU/MU servers. There are some exceptions:

  • If the package says that it “can” request user input, then we skip over the update. ZTIWindowsUpdate.wsf should be fully automated, and User Input could break automation. I added this primarily for IE7 and IE8 updates. So be sure you have IE8 install packages elsewhere if you require IE8.
  • We skip Windows Vista and Windows 7 Ultimate “Language Pack” files. It’s just too much data to download.
  • We can also skip packages for a specific KB article, or by Package ID.

Manually Excluding Updates

Occasionally you may come across cases where you need to exclude specific packages from installing on ZTIWindowsUpdate.wsf.

First step is to find the bdd.log or ZTIWindowsUpdate.log file generated by your test machine. We need the log files to know which Update ID numbers to exclude. While Microsoft Deployment is running, the log will be located at c:\minint\smsosd\osdlogs, however after the installation has finished, the logs could be uploaded to your SLShare Log Share, or to c:\windows\temp\deploymentlogs.

At the start of the log there will be some connection/diagnostic information. ZTIWindowsUpdate.wsf needs to connect to Microsoft Servers to ensure that the runtime binaries are up to date (yes, even Windows Update needs updating). You’ll want to look for the line “Start Search…”, then we see a list of packages:

Start Search...  INSTALL - d49c3450-6646-4fbc-9e67-da7947bf3f13 -
Update for Microsoft Office Outlook 2007 Junk Email Filter (KB974810)   
  SKIP  - 254a9c2e-0431-4a37-b977-f1652d9d4b4d -
Windows Malicious Software Removal Tool x64 - October 2009 (KB890830)   

Here we see a list of all the relevant packages Windows Update has returned for this machine.

  • First column is either “INSTALL” or “SKIP”, all items marked “INSTALL” are to be installed, all items marked “SKIP” are *not* going to be installed.
  • Then we see a 36 character GUID – This is the unique ID For the package. Please note that x86 and x64 packages of the same fix may have different ID’s.
  • A short description of the fix.
  • And sometimes we may have also have the associated Microsoft KB article.

Once you have identified the package you wish to exclude in the future, you can add the ID or the KB article in your customsettings.ini file. Test the install again to ensure that all packages are marked as “SKIP” in the log file, and you are good to go.

Here are some examples of ID’s that I included recently in my customsettings.ini file.

WUMU_ExcludeKB1 = 941160  ; Ultimate Extras WUMU_ExcludeKB2 = 928416  ; .NET Framework 3.0 WUMU_ExcludeKB3 = 955020  ; Add En/De words to dictionary WUMU_ExcludeKB4 = 905474  ; Windows Genuine Advantage ; Bad AuthenTec Driver, blocks installation.
WUMU_ExcludeID001 = 3a130260-44f8-4769-9b9e-57c3bbd4ce45


One trick I use often when testing ZTIWindowsUpdate.wsf directly is to use the /query flag.

net use z: \\server\deploymentshare$
cd /d z:\scripts
cscript \ztiwindowsupdate.wsf /query

When you specify the flag, it will only query windows update, it won’t download or install anything. This is helpful if you need to test your WUMU_ExcludeKB or WUMU_ExcludeID entries to see if they match.


Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Getting Debug information in Client Scripts November 5, 2009

Posted by keithga in MDT 2010, Troubleshooting, VBscript.
1 comment so far

(New for MDT 2010)

Most of the client script in BDD/MDT are written in VBScript. VBScript is a powerful scripting language, and it is avaiable on all versions of windows that MDT supports.

I would have loved to work in a more modern language like Powershell and/or C#, however when deploying an operating system from scratch, there are very few guarantees what kind of run time environments are going to be available. The .NET framework, for example, is not available on Windows XP. So back to VBScript for me.

Error Handling

VBScript has the ability to skip/ignore errors if it comes across them when executing them, using the “On error resume next” command.

This can be helpful if you have a long series of non-interdependent tasks. However if you have a long set of dependent tasks, this can be problematic since the failure of any one step in the task could cause the entire thing to fail.

I would have to agree with Eric Lippert’s comments about error handling in VBScript (He was one of the architects of VBScript):

I think I’m old school in saying that error handling should be very tight. Handle errors where you expect to find them. Everything else is left to fail. I’d rather have a program end in a messy death than to blithely continue on in an unpredictable fashion. Some of my cohorts would rather do broad error handling (whole subroutines or sections of the script). They seem to assume that only the errors they expect will happen. And even if other errors do happen, it’s better to have the script finish as best it can than to do nothing at all.

Most of the code in the MDT client scripts is written with this in mind. If it’s possible for a routine to return an error, the script will handle the error cases. If the results of a routine are unexpected or bad, then we want to halt execution to be notified of the problem, rather than continue in an unexpected state.

MDT Error Handling

BDD/MDT was written with a really cool feature that allows it to pick up run time errors identified by the VBScript host program. These errors are logged to the bdd.log file for review later.

The only problem is that the built in error handling routines made available by the VBScript Host program are not as complete as if we were to run it using cscript.exe with the error written to the console.

For example, here is what an undefined variable error would look like when processed by MDT and it’s built in error handling routines:

c:\>cscript zti_test.wsf
ZTI ERROR - Unhandled error returned by
zti_test: Variable is undefined (500)

New for MDT 2010, is the ability to disable the “on error resume next” main error handler in all MDT client VBScript programs, with the “/DebugCapture” flag. When we run the same script with that flag, we get the following output:

c:\>cscript zti_test.wsf /debugcapture
Property debugcapture is now =
c:\zti_test.wsf(10, 10) Microsoft
VBScript runtime error: Variable
is undefined: 'UndefinedVariableFoo'

Note that when calling the script with the /debugcapture flag, the cscript.exe host program not only found the run time error as in the previous example, but it also displayed the line number where the error occurred and the name of the actual variable!?!?

Really cool stuff, and it has been invaluable for me while debugging scripts in MDT 2010.


Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Troubleshooting Database Issues with MDT 2010 November 4, 2009

Posted by tmintner in MDT 2010, Troubleshooting, Uncategorized, VBscript.
Tags: , , ,
add a comment

There have been a few really great posts on how to troubleshoot database connection issues with BDD and MDT over the past couple of years.  Ben Hunter wrote a great post on this here: http://blogs.technet.com/benhunter/archive/2007/07/10/bdd-2007-troubleshooting-database-issues.aspx.  However, if you try to do this with MDT 2010 you will get a few errors in the output.  In MDT 2010 the structure of the scripts have changed somewhat and the functionality of ztigather has been extended to also gather additional information that now requires some compiled code.  So with MDT 2010, you can perform the same steps with the following modifications:

1. Create a folder on the client device and copy the following files from the deployment point to this folder:

  • ZTIGather.wsf
  • ZTIGather.xml
  • ZTIUtility.vbs
  • CustomSettings.ini
  • ZTIDataAccess.vbs (new script file in MDT 2010 for accessing data sources)
  • Create a Tools folder and create an X86 and X64 folders underneath the Tools folder.  Copy the Microsoft.BDD.Utility.dll file from the Tools\X64 and Tools\X86 folders in your deployment share to your newly created Tools\X86 and Tools\X64 folder

  2. Delete C:\MININT directory if it already exists. This folder can also be located at X:\MININT if the C drive is not available.

NOTE: MDT stores configuration and progress information in the MININT folder, if this folder is not removed between tests then the results will be invalid.

  3. From the command prompt navigate to the newly created folder and execute the rule processing script using the following command:

“cscript.exe ZTIGather.wsf /debug:true”

      The script will then be processed and the results outputted to the command prompt and a log file ( .\MININT\SMSOSD\OSDLOGS\ZTIGather.log)

NOTE: The script can be run within Windows PE or the host operating system.

  4. Review the results of the script.


Tim Mintner is a Principal Consultant with Xtreme Consulting Group