Scripts updated in MDT 2008 Update 1

A few people have asked about the script updates that were made in MDT 2008 Update 1.  Here's the quick summary listing all the scripts that were modified in MDT 2008 Update 1 and a very brief description of the changes made to each:

  • DeployWiz_Definition_ENU.xml.  If the deployment type is blank, show the deployment type wizard pane even if directed to skip it.
  • DeployWiz_Initialization.vbs.  Better handle task sequences that reference OSes that no longer exist.  For new computers, filter out task sequences that aren't for the current architecture of Windows PE.  Don't display the application selection pane if there are no "Install Application" steps in the task sequence.
  • DeployWiz_Validation.vbs.  Preserve the preconfigured DeploymentType value while clicking through task sequences.
  • LiteTouch.wsf.  Add hooks for the LTI OEM preloading process.  Send proper "beginning" events to the management pack.
  • LTIApply.wsf.  Set the right image path, pointing to the locally-cached image, when performing multicast Windows Vista or Server 2008 deployments.
  • LTICleanup.wsf.  Changes to support the LTI OEM preloading process.
  • LTISysprep.wsf.  For Windows XP and Server 2003, set the local Administrator password to blank before running sysprep.
  • ZTIBackup.wsf.  When capturing a Windows XP or Server 2003 image, remove the boot folder and bootmgr file so that they don't confuse ConfigMgr 2007 if the image is later used with ConfigMgr.
  • ZTIBcdUtility.vbs.  Fixed a problem when running BCDEDIT on a non-English OS.  (See
  • ZTIDiskpart.wsf.  Changes to support the LTI OEM preloading process (don't repartition and reformat the disk if the deployment point is on it).
  • ZTIDiskUtility.vbs.  Use DiskIndex instead of Index when querying WMI for disk information.
  • ZTIGather.wsf.  Fixed logic for setting SMSDP variable.  Modified computer name assignment logic so that logging and management pack behaviors are more consistent.
  • ZTIGather.xml.  Added OSDComputerName property.  Fixed ADDSUserPassword to be ADDSPassword.
  • ZTIMediaHook.wsf.  Added logic to wait for an advertisement after adding a new unknown computer.
  • ZTIMoveStateStore.wsf.  If the "move" process fails, try to copy the state store directory.
  • ZTISCCM.wsf.  Cache the MDT files package content even in Windows PE, as long as there is a place to put it, to avoid later network access issues.
  • ZTIStorageDrivers.wsf.  Don't do anything when installing an image (only for unattended installs of Windows XP and Server 2003).  Use XCOPY to copy mass storage drivers, removing read-only attributes.  Remove "IDE CD-ROM" entry from unattend.txt that caused problems on non-English OSes.
  • ZTIStorageDriversSysprep.wsf.  Fixed a variety of errors related to the processing of TXTSETUP.OEM files.  Added "hdc"-class drivers to the selection criteria.
  • ZTIUtility.vbs.  Modified the management pack event file creation logic.  Changed the computer name assignment logic to be more consistent, especially during ConfigMgr deployments.  Properly build SQL connection strings when specifying named pipes and a port.
  • ZTIWindowsUpdate.wsf. Add logic to opt in to Microsoft Update.  Restore the original state of the Window Update Agent when done performing updates.

There are also two new scripts:

  • LTIOEM.wsf.  Load a Lite Touch media deployment point onto the hard disk.
  • ZTIOEM.wsf.  Save and restore needed task sequence variables to support the split two-part OEM task sequence templates.

Comments (12)
  1. Anonymous says:

    Thanks again Mike for your reply. That helped tremendously. After playing with it for a while (after my last post, obviously), RSAT is being injected and installed (though not configured).

    I have discovered that through modifying the ZTIOSRoles.wsf script, I can "add support" for Windows Vista and run OCSetup to enable the various roles/features within RSAT. I’ll post my changes to the code back when I have successfully configured RSAT using LTI deployment with MDT.

  2. Anonymous says:

    This is great info Michael, thanks for spending the time to blog the changes. This will come in handy in things to expect after the update is applied.

  3. Anonymous says:

    I see that the Remote server Administration Tools are available for installation under the task Install Roles and Features. However, the script ZTIOSRoles.wsf has some code that says that Windows Vista is unsupported. Now I know this is because Update 1 came out before (or slightly after) the RTW release of RSAT. Now I’ve been poking around at the scripts trying to determine how best to "add support" for Vista. First, RSAT needs to be installed in at least the STATERESTORE phase. I see in ZTIGather.xml that there are properties–namely the Role list property as well as all the properties associated with the various RSAT Features/Roles that would be available from Program and Features in Vista, as well as the OSRoles and OSFeatures comma delimited lists–that look like they can be set in CustomSettings.ini. If that’s the case, then ZTIGather.wsf would collect all these settings from CustomSettings.ini. So now, where would be the appropriate place to get these features installed? Would it be Install Packages (since when you import the RSAT MSU into MDT it gets placed into the OS Packages folder and that task occurs in the STATERESTORE phase)? The only other fly in the ointment, is not actually configure these features to be enabled is by using OCSetup, which ZTIOSRoles.wsf calls for Windows 2008. I know that RSAT can be installed for Vista via MDT, but what is the best way to go about it? I am not afraid of scripting (and yes, I have made sure I have copies of the original scripts in case I really screw something up 😉 ).

  4. There are no scripts involved with Workbench – it’s all compiled code.  It is possible to do this via PowerShell, calling the Microsoft.BDD.ConfigManager methods that perform this task, but this is likely to change in the next version of MDT which would break the PowerShell script.


  5. mantolama says:

    Thank you for a nice study I would like to make my few shares

  6. Anonymous says:

    The only question that would greatly aid in what I’m trying to accomplish (I can’t wait until MDT 2010 is released 😉 ) is at what point during the installation is the <servicing /> section processed?

    Some packages that appear under this section, such as drivers and language packs can be installed during the offlineServicing pass. However, SP1, for example–and in my case, RSAT–can only be installed while "online" (the installation of Windows that will receive the component is running). Does the particular package tell Setup when it should be processed (in which pass)?

    For instance, the ApplyPatches task is by default in both the PreInstall and PostInstall phases of setup, hence my confusion.

    In addition, there is the Packages task that uses the same Packages.xml file that the ApplyPatches task uses (which begs the question what really is the difference between a package and a patch?).

    So in my case, where is it best to include the installation (not configuration) of RSAT? In ApplyPatches, or InstallPackages? I would think ApplyPatches because that is where the Packages.xml file is processed and added to Unattend.xml. I don’t see anything in InstallPackages that’s adds items to the <servicing /> section in unattend.xml (which is where RSAT gets dumped when you use WSIM to add the package to the unattend.xml file manually).

    BTW, I have been able to successfully get Vista Setup to install RSAT by modifying the Unattend.xml file manually via WSIM. However, I would like to have this functionality all self-contained in MDT. My point is, I know it can be done, so I’m trying to do it; but I need a little help. 🙂

    TIA! MDT is a great tool.

    — P.S. one more thing…

    SUGGESTION: Make different (additional?) default task sequences depending on whether an OSD, SCCM, or UNC DeploymentMethod is being done. It’s very confusing to have all these different tasks in the Task Sequence that aren’t related to the installation method I’m using.

  7. Anonymous says:

    Thanks for the info Michael.

    I would like to create a distribution share automatically. Which script is called when clicking on "Create distribution share directory".

    Thanks in advance.

  8. We will try to add more documentation around the scripts in the next version, but there are no guarantees.  (We have provided this type of information at TechEd and MMS sessions in the past, it just hasn’t made it into documentation.)

    One correction too:  While there is a Microsoft.BDD.Utility.dll COM component, most of the oUtility implementation is indeed in the ZTIUtility.vbs script (Class Utility).  It’s not a binary DLL.

    As for RSAT, if you import the MSU into Workbench, MDT will make sure the package gets injected, but the role won’t be installed, so some script changes would be required.  We’ll see what we can do about that in MDT 2010 too.

  9. Anonymous says:

    P.S. To my post above:

    I guess what I’m really asking is, architecturally speaking, where should certain things be done?

    I can write a custom section in the ZTIPackages.wsf script to detect whether Roles and Features were requested to be installed and on what OS and install RSAT for Vista if I need to. If I can place these settings in CustomSettings.ini, then ZTIGather.wsf will do a lot of work for me. Then, modifying ZTIOSRoles.wsf can enable me to enable the specific features/roles requested.

    What we really need for the MDT is good documentation regarding the scripts. What are the methods on oUtility, oEnvironment, oLogging, etc. Yes, you can glean a lot from the scripts, but nothing is as good as documentation. Especially since oUtility is an object that is implemented in a binary Dll (Microsoft.BDD.Utility.dll) for which there is no documentation at all. I hope that this kind of documentation will be added in MDT 2010.

  10. Anonymous says:

    Thank you for the reply. I will hope for and look forward to those changes in MDT 2010.

  11. Jay P (PLA) says:

    On a refresh with ConfigMgr R2, MDT2010 U1, the ztigather is unabe to determine DP.  What can be the cause of this?  The reason I need this is for the USMT capture.. the /config:config.xml by itself doesn't work (can't find file) so need to add a absoulte path to the local DP and package source.

Comments are closed.

Skip to main content