Tag Archives: mdt 2012 update 1

MDT 2012 will HideShell=YES and LTISuspend.wsf work together in one task sequence?

Published / by Rens Hollanders / 4 Comments on MDT 2012 will HideShell=YES and LTISuspend.wsf work together in one task sequence?

Short answer: YES 😀

Recently I have created a Build Task Sequence for a customer where it was needed to do some checks upfront, before the operating system, running on a virtual machine would be captured to a WIM file.

As some of you might know, the LTISuspend.wsf script, residing in the SCRIPTROOT of MDT (DeploymentShare\Scripts), can be called after the ‘State Restore’ step in the task sequence.

At any given moment, but preferably under the ‘Custom Action’s’ folder, create a ‘Run Command Line’, with the following commandline: “cscript.exe %SCRIPTROOT%\LTISuspend.wsf”

figure 1.1: Suspend Task Sequence Step


this will postpone the task sequence and create a shortcut on the desktop called ‘Resume Task Sequence’. However when using the following property in your customsettings.ini: “HideShell=YES”, your desktop shell will not be fully loaded, thus it would be possible that no desktop, taskbar and other icons where presented during the LTISuspend.wsf.

figure 1.2: No Explorer Shell

TS Progress

Luckily this isn’t the case. When the machine is suspended and HideShell is set to YES in the customsettings.ini the task sequence will be succesfully postponed, however the Windows theme, will be set to basic, as we can see by the screenshot I took:

figure 1.3: Suspended Task Sequence


So use it with confidence!

Keep on automating my young padawan learners! 😀


MDT 2012 LTI Deployment, Regional and Locale settings based on #chars of Hostname

Published / by Rens Hollanders / 12 Comments on MDT 2012 LTI Deployment, Regional and Locale settings based on #chars of Hostname

Recently I have done an MDT implementation for a customer regarding a deployment which featured an database of approx. 250 clients, each with known mac-addresses and host-names available to make use of.

The customer requested that based on mac-address the host-name would be provided, and based on the host-name, Regional and Locale settings could be set during LTI deployment. After a little bit of consult on technet and talked to deployment artist ‘Johan Arwidmark’, I’ve incorporated a custom ‘user exit’ script that does just the trick!

Basically, the company had 5 different affiliate locations in 5 different countries, with each different Regional and Locale settings

The script created/used was a joint effort between a colleague and me, (thanks Roger the Young aka. Drillsergeant):

Explanation of script:

The first 4 lines is our basic UserExit script function, the second function retrieves the CountryCode, and retrieves this information based on the first two characters of the host-name. Last, if no value is declared, the script will automatically fill-in the desired default country, which in our case is NL – Netherlands

The script then executes, and replaces the following values, with the values that are specified in the customsettings.ini:

Make sure you add the following properties to your customsettings.ini: “ByCountry“, “CountryAbbr” (which stands for Country Abbreviation) and define the custom properties: “CountryAbbr“, “CountryOU” as your custom declared properties. This way the script knows what to process.

The values I then had declared were:

CountryOU: since they had different OU’s for each country
CountryOrRegion: Country#
InputLocale: specifies the input language and keyboard layout for a Windows installation.
KeyboardLocale: specifies the input language and keyboard layout for a Windows installation.
UserLocale: specifies the per-user settings used for formatting dates, times, currency, and numbers in a Windows installation.
TimeZoneName: gets the Notification Services assigned name for the time zone

This way, the default values will be overwritten with the values that matches the hostname’s first two characters and the values will be placed in your unattend.xml, which is located in the “C:\Windows\Panther”, during the inital setup of the operating system, just after the image has been applied.

If all fails, you’ll notice immediately because then you will find an error during the setup phase of your operating system, which will look like this:

figure 1.1: Unattended.xml parsing error


This indicates that an incorrect value has been written into the unattend.xml, likeley in the <specialize> pass, you can look this up by opening the unattend.xml with notepad during your deployment.


You can just use any country abbreviation that is out there, accompanied by the default settings for this country, or off-course your own values, and also, extend the list of values with other country related settings you wish to apply.

Download the script here:



MDT 2012 Settings for fully automated LTI deployment, Part II: Customsettings.ini

Published / by Rens Hollanders / 39 Comments on MDT 2012 Settings for fully automated LTI deployment, Part II: Customsettings.ini

So my second part of how to achieve a fully automated deployment, can be used to create a reference image or to deploy a computer.

Lets start customizing 🙂

First of all we can set our priority and fortunately the ‘deployment bunny’ has written a great blog about the available properties for setting the priority in which order MDT executes which task with which properties:

Priority=MACAddress, Default

In my case I have set the priority on MACAddress first, this means that MDT will look for a machine with the given MACAddress and apply the custom defined properties only for this machine. This is especially handy when we want to use our deploymentshare for more then one purpose alone. In my case the ability to create an automatic reference image but also being able to use other task sequences from that same deploymentshare to other computers.

So if we specify our MACAddress here, we can then apply the settings we want. In my case I start again with configuring the IP address for a virtual machine which occurs in a back-end server environment with no particular DHCP present on the VLAN.


Then I specify that the task sequence wizard needs to be skipped by providing the following option: SkipTaskSequence=YES
And immediately after that I fill-in the desired TaskSequenceID which needs to be executed automatically, which is in my case OSB001 (Operating System Build 001)


Next we need to provide an computer name for our reference build. With the SkipComputerName=YES we prevent the hostname wizard, but when we do this, we also need to provide an hostname for the upcoming deployment. The task sequence variable “OSDComputerName” will be picked up and understood by the scripts if provided.


Then to capture the created reference image we provide the following parameters:
SkipCaptures=YES obviously the wizard pane needs to be skipped. But because we want to capture our reference image, we provide the DoCapture=YES setting too, followed by the backup location which needs to point to an accessible network-share and provide the file-name for the captured WIM file.


So far our custom properties for one particular fully automated Task Sequence. When all the other configurable options will remain the same we can configure these options beginning with the organization name displayed during deployment. The organization name displayed can be modified by providing the parameter “_SMSTSOrgName” and a value for the organizational name, for example “Contoso IT”. Further, OSInstall lets MDT know we want to deploy and operating system.

_SMSTSOrgName=Contoso IT

The following options are for preventing the multiple wizard panes popping up for input or requesting input. At default, we don’t want the Task Sequence wizard to skip, therefore we set this setting to “NO”. With SkipApplications and SkipAppsOnUpgrade we can see the apps that will be installed if the Application Guid has been provided in the customsettings.ini. Once again, Andrew Barnes has written a nice blog about that particular subject.

Skipping the capture, makes sure that your deployment will not ask you to start capturing at the end of the deployment and defining the property DoCapture=NO answers the question that your deployment will not be captured.


Then a few more obvious properties; SkipAdminPassword prevents the wizard pane for providing your local admin password for the machine that will be deployed. SkipProductKey will skip the request for a valid product key which should / could already be filled in in your unattended.xml. The SkipDeploymentType and DeploymentType evaluate what kind of deployment scenario will be used, because there are tree scenario’s possible: NEWCOMPUTER, REFRESH, REPLACE

The target computer is a new computer that has never been a member of the network.
The target computer is an existing computer on the network that needs the desktop environment standard to be redeployed.
An existing computer on the network is being replaced with a new computer. The user state migration data is transferred from the existing computer to a new computer.


Then we are going to join the computer to our domain, SkipDomainMembership=YES means we will not see the domain join wizard pane. If we provide the following additional parameters the computer will automatically join the specified domain:


If there is userdata that needs to be migrated the following can be specified “SkipUserData” and “UserDataLocation”, if any existing profiles are present on the computer an USMT MIG file will be created which can be placed back after the OS deployment has been completed. More information on MDT in combination with USMT, please check this blog


The only wizard pane we would like to see if we cannot prepopulate the hostname in advance is the ComputerName pane, by providing the following setting we will be asked for an hostname:


Then the locale selection can be prepopulated too! “SkipLocaleSelection” and “SkipTimeZone” will hide or show the locale selection wizard pane, providing the following parameters will set the locale settings:

TimeZoneName=W. Europe Standard Time

A new addition to my customsettings.ini (which I have added december 2013) is setting the native resolution for each device, by providing the following settings, the machine will be forced to start “enable auto detection” of display settings. This way, you’re always getting the most optimized resolution settings for your device. See this blog for more information.

; Display Settings

“SkipBitLocker” will show the Bitlocker configuration pane during deployment, and the last of the regular wizard panes “SkipSummary” wil not show the configured properties of which the deployment will commense with after we have clicked next.


Setting the homepage for every deployment that will be executed, use the property: Home_page=


Supplying the eventservice, makes sure that live monitoring will be reported back to the MDT deploymentshare at which current step your deploymentphase actually is.
Providing the value “SLSShareDynamicLogging” provides actual replication of the BDD.log which covers all the actions executed by the task sequence and is a nice feature for centrally logging the deployment progress!
In the end, using “HideShell” makes the Windows 7 GUI disappear and only the MDT progressbar visible for the length of the deployment.


In the end we specify which WSUS updates will not be included in the update process. Because enabling the two steps already present in the task sequence “Windows Update (Pre-Application Installation)” and “Windows Update (Post-Application Installation)” will start querying your WSUS server or Windows Update Server on the internet and download all available Windows update present at that time. To exclude certain updates we can first of al run a /query from which we can easily see which updates are being advertised to our computers.

By providing the following additional command: “/query” to the already existing command: “cscript.exe “%SCRIPTROOT%\ZTIWindowsUpdate.wsf”” we can see in our BDD.log which updates are being advertised to the system.

In my case I wanted to exclude the following updates:

;Microsoft Browser Choice Screen Update for EEA Users of Windows 7 for x64-based Systems (KB976002)
;Microsoft Silverlight (KB2636927)
;Windows Internet Explorer 9 for Windows 7 for x64-based Systems (KB982861)
;Bing Desktop (KB2694771)

Note that each update that needs to be excluded needs to be specified seperately, and numbered each time with a higher number for every new to be excluded updated.

Hope that this provides some insight in creating a fully automated reference image and explains the purpose of each property in the way that I have experienced it.

Download the script here:



SCCM / MDT: identifying SSD’s from your Task Sequence by Windows Performance Index!

Published / by Rens Hollanders / 10 Comments on SCCM / MDT: identifying SSD’s from your Task Sequence by Windows Performance Index!

Many has been written about detecting SSD’s through WMI query’s and scripts to perform optimization settings for SSD’s when deploying Windows 7/8 to an SSD Disk.

And although there is no unique identifier to really determine if we are dealing with an SSD or traditional hard drive I believe I may have found something that works better then all the other available options.

For example there is the SSD Drive Script which queries for the ‘ random read rate’  and if it appears to be higher then 8Mb/s it will mark your drive as SSD.

Then there is also the WMI Query: wmic diskdrive get caption which queries for the disk Caption, and sometimes a vendor has written ‘ SSD’ into the Caption. But that is also to random.

Other alternatives are managing and detecting hard drive product names, but then there is always human intervention required to update the list, because hard drives are being renewed all the time.

Because the value of the SSD Drive Script sometimes outputs not the correct value I have found a better and more reliable tool to determine the hard drive type and speed. The integrated Windows Performance Index that is present within Windows 7/8. Because this performance assessment generates a properly random read/write rate which it looks you have to generate it yourself when your disk is idle at the time the ‘SSD Script’ is being run.

To initiate a Windows Performance Index rating we need our machine during deployment or patching to be rated.

We do this by adding a ‘ run command line’ with the following parameters:

C:\Windows\SysNative\WinSAT.exe formal


Next the Performance Index will rate the system performance and when ready have the hard drive assessed:

performance index

Obviously we cant see the rating when executing a task sequence and the Windows shell being locked, but if we would run a normal WinSAT benchmark this would be the result. And I have noticed that the values of a benchmarked traditional hard drive will not exceed 6.9 while SSD’s exceed 7.0 and more.

No we have something that we can use as a condition to either run or do not run SSD optimalization tasks in a SCCM / MDT task sequence, by using the following condition on a group of optimalization actions:


Because the machine’s hardware has been assessed a performance number has been assigned to the disk. If the disk is not rated the value always responds with zero. In this case we query if the hard drive performance rating is greater then 6.9, if this is the case we execute our SSD optimalization, if it is smaller we skip these steps.

*Alternatively, you can use the same query to execute the WinSAT benchmark for your system if it is allready rated, if it is rated it will skip the benchmark and if a machine is not rated, the benchmark will be executed.

Hope this may help you in your quest to detect and find a reliable condition from which the detection of SSD’s can be queried, and I hope that in the near feature other solutions may be handed to us.


MDT 2012 Settings for fully automated LTI deployment, Part I: Bootstrap.ini

Published / by Rens Hollanders / 16 Comments on MDT 2012 Settings for fully automated LTI deployment, Part I: Bootstrap.ini

So based on some blogs I’ve read and a recent project I have worked on to realize a fully automated Operating System Build, I wanted to share my settings just to clarify which settings need to be present within the bootstrap.ini and the customsettings.ini.

Part I: Bootstrap.ini

First of all, there is the bootstrap.ini. Customizing the bootstrap.ini affects all the settings which a machine will be booted with. In my case it was necessary to provide a static IP configuration because the server back-end where I had a test virtual machine to my disposal had no active DHCP running, therefore it is necessary to specify the IP configuration for one or more machines.

If we want to do this for one machine, we need to have a unique identifier which the settings can be applied to, in this case it would be the MAC Address of the virtual machine which in our case will not change automatically (VMware HyperVisor, on Hyper-V you need to specify a static IP). Therefore we set our Priority to MAC Addres 1st, and then the Default configuration options 2nd because we want those options to be applied to all clients.

Priority = MACADDRESS, Default

Then it is time to configure our network adapter, in case of a virtual machine it is likely that we have only one network adapter present. Therefore we need to specify the MAC Address of that adapter between the “[ ]”.

Next we specify the number of available network adapters, in case there is one we set our “OSDAdapterCount” to 1.
If there is no DHCP available we set the OSDAdapter0EnableDHCP to FALSE to make sure that when the machine boots into WinPE no instruction will be executed to request an dynamic provided IP address.

By specifying the following settings we provide our adapter configuration as we would normally do in Windows also when we want to specify a static IP address:

OSDAdapter0IPAddressList=Enter the machine’s IP address here
OSDAdapter0SubnetMask=Provide the correct subnet here
OSDAdapter0Gateways=Provide the gateway address
OSDAdapter0DNSServerList=Provide multiple DNS servers by using “,”
OSDAdapter0DNSSuffix=Provide the DNS Suffix so that machines that are not domain joined can still communicate with domain joined servers and computers


*Note: working with multiple network adapters needs further explaination and luckely another MDT Exprert “Andrew Barnes a.k.a. Scriptimus Prime” has written a nice blog about that: MDT 2012: Automating Network Interface Configuration

Now we have specified our IP configuration based on MAC Address we can specify our Default settings which will be applied to al machines who will connect to the MDT deploymentshare.

Obviously we need a connection to our deploymentshare which is located on the network, with the property “DeployRoot” we specify the network location where the share is located.

By specifying “SkipBDDWelcome” we skip the screen where we can chose for running a new deployment, so that the wizard will automatically advance to the customized MDT wizard for deploying machines.

It is also possible to specify the keyboard layout allready, this is especially handy when you need to authenticate to your deployment share by password with keyboard symbols and characters.


Then off-course it is time to configure our user account which is used to connect to the deploymentshare. No additional rights other then Read, List and Execute are necessary so an specified service account with ‘Domain User’ rights will do the trick if you set your NTFS and Sharing permissions right on the deploymentshare!


So far my first part of explaining how to realize a fully automated deployment.

Please feel free to contribute in the comments

Download the script here: