In Part 1 of this series we walked through installing and configuring MDT 2013 for the first time. In this part I’ll show you how to globally automate the deployment. In terms of automation there are two types of automation, global automation settings that are applied by default to all machines and then those that are directed at individual machines. Firstly I will explain and demonstrate the global settings and then I will run through how to centrally apply individual settings to different makes and model of machines.

If we right click our deployment share we can access the configuration settings (properties) used for that share. Under the rules tab we can access two sets of settings, customesettings.ini (the settings you see in the pane) and Bootstrap.ini (the settings accessed by clicking the button).

 

These settings are held on the hard drive in the deployment share.

 

 

BootStrap.ini is used at boot time to provide basic configuration to the machine and allow it to connect to the deployment share. Because of this, changes to bootstrap.ini have to be placed inside the WinPE image by updating the deployment share whenever changes are made to bootstrap.ini.

Once the machine is booted customSettings.ini takes over and controls the rest of the deployment process typically automating entries in the MDT GUI to drive the deployment.

Let’s deal with bootstrap.ini first. If we click on the button above to open the ini file we see that, by default, its settings look like the below:

The [Settings] section is read in first and the process then follows the value in the priority field. Here it loads up the section [Default] which only has one value, the location of the deployment share to read data from. By default, all installations will use the same deployment share in this location.

We can add additional item to bootstrap.ini. The “typical” values we may want to add are:

UserID=Administrator

UserDomain=Example

UserPassword=Pa$$w0rd

KeyboardLocale=en-GB

SkipBDDWelcome=YES

 

I have highlighted the values to be changed in RED. A word of caution though, the username and password are held in plain text in the boot.ini file and, as you can see, this is held in the deployment share which, by default, provides all users with read access. If you were to use your domain administrator account in a production environment users could possibly have access to this high privilege level account !

Instead, I prefer to create a new account and grant access to that account to that share at the NTFS levek. I also remove the account from the Domain Users group and add it to a “No Access” group. This prevents the account being used to access information shared to domain users. It does not prevent it being used to access data shared to everyone or authenticated users though so the amount of protection this strategy supplies will depend on your internal environment. For those shares, access can be denied to the “No Access” group securing the environment once more.

 

He account is granted read access to the share and the built in users group removed. In this way admins still have access to the share but standard users do not and so the likelihood of someone “seeing” any user names or passwords in the customsettings.ini or bootstrap.ini files are limited.

 

Applying these settings, my boostrap.ini file therefore looks as below:

 

Once the boorstrap.ini file has been updated, we need to update the deployment share (to regenerate the WinPE boot .iso and .wim files) and then redeploy those, either to DVD / USB sticks or to WDS as needed. That is, we run the “Update Deployment Share” as below and once that is completed (after 15 – 20 minutes) we copy the files created from the “D:DeploymentShareBoot” location to wherever we will be using them to boot our endpoints.

 

Once the boot.ini file has been updated, we can re-test out deployment and ensure that the keyboard set to be used is the correct language (in my case, British English) and that we are not asked for a user name and password to connect to the deployment share. If you prefer you can leave out the line that passes the Password through. In that case anyone accessing the setup screen will not be able to reuse your image without first entering the password. However, if you would like remote users to self service their rebuilds then this would mean you would need to tell them the password so it’s a little bit of “swings and roundabouts” and how you configure this will, to an extent, depend on your circumstances.

Assuming that the test passes, you can now move on to customizing your customsettings.ini file. By default, the customsettings.ini file looks as below:

 

The Information Center provides detailed information on which settings can be applied to the customsettings.ini file. This information can be found by clicking on the “Planning MDT Deployments” link.

 

 

This will open a PDF file and under the “Toolkit Reference | Properties | Providing Properties for Skipped Deployment Wizard Pages” node you will find listed the values you need to enter into customsettings.ini to skip these items in the wizard.

 

 

Accessing the Properties Definition item (1 level up) allows you to get a fuller explanation of each property together with examples of how to configure it.

So, for example, If we want to automatically select the Task Sequence name to be run and just build 2012 R2 servers we enter the two lines below.

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

To automate the complete process you may want to consider using the settings below as well as setting the pre-set items to Yes:

SkipComputerName=YES

SkipDomainMembership=YES

SkipUserData=YES

SkipCapture=YES

DoCapture=NO

SkipLocaleSelection=YES

SkipTaskSequence=NO

SkipTimeZone=YES

SkipApplications=YES

SkipSummary=YES

TimeZone=085

TimeZoneName=GMT Standard Time

 

The Time Zone values for all regions are listed at http://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx.

The above settings will allow you to select a task sequence to be run but will assign a random name to the computer and, unless your task sequence adds the computer to the domain, will add the computer to a workgroup. If you want to pre-set any of the values you add the corresponding entry from the right hand column of the above table and assign a value to it as demonstrated by the task sequence example above.

A completed “basic” customsettings.ini file which would allow you to select the task sequence to apply would therefore look like the below:

Booting using our boot media now results in a single screen asking us which task sequence we would like to run.

 

 

The only thing is, configuring MDT as above means that ALL of your deployments must be identical other than the contents of the task sequence. Now, this may or may not be OK. For example, if we want to use MDT to refresh workstations and laptops as well as build new servers it could be that, when we are booting to a client machine we want to preserver (or be asked to preserve) user data whereas if we are booting to a server machine then we will not want to be given this option. This can be achieved by detecting (gathering) information about the endpoint at boot time and then applying different settings based on characteristics of the endpoint.

Luckily, this isn’t as different as it may sound. When the boot process runs, MDT runs a gather script named ZTIGather.vbs. This script is located in the Scripts folder of the deployment share meaning we can run it ourselves against an existing client and inspect the output of the script quite easily.

 

We can then use those discovered values to drive our deployment proves using customsettings.ini. If we run the script it creates a folder called MININT in the root of the operating system drive.

 

 

Drilling down inside that folder we eventually get to the ZTIGather.log file created.

 

This can be opened in notepad or you can download the SCCM 2007 log reader as part of the System Center Configuration Manager 2007 Toolkit V2 from http://www.microsoft.com/en-us/download/details.aspx?id=9257. This will allow you to install the “Trace32” application (the log file reader) by selecting to install “Common Tools” only.

 

 

An example of the type of information gathered is displayed below.

 

 

As can be seen, we can see whether the device is a laptop, desktop or server architecture, the make and model of the machine, the amount of RAM, processor speed etc. This can therefore allow us to use these values to determine the endpoint type which in turn allows us to determine what happens in our deployment based on the endpoint itself. For example, we can auto select the task sequence to run based on the endpoint type. We can also read items such as the endpoints IP address or gateway address. If we know the gateway address we can determine which site the endpoint is in. If we know which site it is in we may know which department it is in (if the LAN is subnetted in that way) or, in the alternative, which country it is in allowing us to determine which language packs should be installed.

A sample deployment decision tree may look like the below:

 

 

To accommodate this, we create additional sections within our customsettings.ini file. The first thing we do is create a new section which we will call [ClientType]. We then give that the highest priority of sections to be parsed.

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

 

In the [ClientType] section we have instructed the file to go to a subsection named either Server-True or Server-False based on the value of IsServer in the ZTIGather.log file. This leads us to have 2 additional sections – [Server-True] and [Server-False].

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

 

From the above we can see that if the IsServer value is true then we will build using the WIN2K12R2-001 task sequence. If the endpoint is not a server then it must either be a desktop or a laptop so we then query the IsDesktop value. Based on that value we will either be directed to the [Desktop-True] or the [Desktop-False] section.

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

[Desktop-True]

SkiptaskSequence=Yes

TaskSequenceID=HPDesktop-001

[Desktop-False]

SubSection=%make%

 

If the device is a desktop, the HP task sequence will be run, if not, we will progress to a subsection based on the make of the device – either [Dell] or [Lenovo], the two types of laptops we have in use

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

[Desktop-True]

SkiptaskSequence=Yes

TaskSequenceID=HPDesktop-001

[Desktop-False]

SubSection=%make%

[Dell]

SkiptaskSequence=Yes

TaskSequenceID=DellLaptop-001

[Lenovo]

SkiptaskSequence=Yes

TaskSequenceID=LenovoLaptop-001

 

These settings are also accompanied by our [Default] section to cover those items which are not picked up by the above and also to supply the balance of settings. So, our complete customsettings.ini file will look as below:

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

[Desktop-True]

SkiptaskSequence=Yes

TaskSequenceID=HPDesktop-001

[Desktop-False]

SubSection=%make%

[Dell]

SkiptaskSequence=Yes

TaskSequenceID=DellLaptop-001

[Lenovo]

SkiptaskSequence=Yes

TaskSequenceID=LenovoLaptop-001

[Default]

OSInstall=Y

SkipCapture=YES

SkipAdminPassword=YES

SkipProductKey=YES

SkipComputerBackup=YES

SkipBitLocker=YES

SkipComputerName=YES

SkipDomainMembership=YES

SkipUserData=YES

SkipCapture=YES

DoCapture=NO

SkipLocaleSelection=YES

SkipTaskSequence=NO

SkipTimeZone=YES

SkipApplications=YES

SkipSummary=YES

TimeZone=085

TimeZoneName=GMT Standard Time

 

In our [Default] section we have set SkipTaskSequence=NO so that the full list of task sequences will be displayed if an unknown endpoint type is used.

NOTE: The above may or may not work for you – it is merely shown as an example of how to automate the deployment process. The best advice is to start the boot process for MDT and then press F8 to access a command prompt and then read the ZTIGather.log file. You will then be able to see exactly what values and settings will be detected by the boot process (information gathering process) for each end point type. The above process flow can be simplified for very basic deployments by just creating section names based on endpoint attributes such as make, model, serial number, MAC address etc. In this way an appropriate task sequence can be applied to each machine type with separate settings applied to individual machines. For example:

 

[Settings]

Priority= SerialNumber,Make,Default

[AFD1258E]

MandatoryApplications001={GUID}

[Dell]

SkiptaskSequence=Yes

TaskSequenceID=DellLaptop-001

[Lenovo]

SkiptaskSequence=Yes

TaskSequenceID=LenovoLaptop-001

 

Here, we apply the task sequence based on the make of machine. However, on the CEO’s laptop we want to always install a piece of software whenever it is rebuilt and so we record the serial number of his machine and assign the application to that serial number. The GUID is the GUID displayed in the application we have imported into MDT (example below). The GUID needs to be enclosed by the braces, { and }, when being entered in the customsettings.ini file.

 

Indeed, if this application is ONLY to be installed by particular people (and hence automatically) we can tick the “Hide this application in the Deployment Wizard” check box to ensure that it is not offered mistakenly to unknown machines.

As well as using discovered values in this way we can also use items such as the endpoints default gateway to determine what to install, for example language packs. Below is an example of how to configure the customsettings.ini file based on default gateways.

 

[Settings]

Priority=DefaultGateway, Default

[DefaultGateway]

10.1.1.1=LONDON

10.2.2.1=TOKYO

10.3.3.1=NEWYORK

[LONDON]

Packages001=XXX00004:Program4

Packages002=XXX00005:Program5

[TOKYO]

Packages001=XXX00006:Program6

Packages002=XXX00007:Program7

Packages003=XXX00008:Program8

[NEWYORK]

Packages001=XXX00006:Program4

I’d just like to finish up this post by showing you the settings used to join the endpoint to the domain. Any account used must have the rights to join computers to the domain delegated to it and any other rights removed. Remember, anyone with access to the MDT server hard drive or deployment share will be able to see the user name and password used as they are in clear text which is why I create a separate account for accessing that share and then restricting the permissions to only that account.

 

[NEWYORK]

SkipDomainMembership=NO

JoinDomain=EXAMPLE.COM

DomainAdmin=svc_DomainJoin

DomainAdminDomain=example

DomainAdminPassword=Password01

MachineObjectOU=OU=Computers,OU=NYC,DC=Example,DC=com

 

Here, we have detected from the machines default gateway that it is based in New York and so will join our domain and place the machine in the computers OU under the NYC OU. JoinDomain is the domain we want to join and DomainAdmin, DomainAdminDomain and DomainAdminPassword are the credentials of the account that will be used to join the computer to the domain.

If you want some good examples of customsettings.ini configuration I would refer you to http://scriptimus.wordpress.com/2011/06/23/mdt-2010-sample-customsettings-ini-for-fully-automated-deployments/. While this refers to MDT 2010 they should still work with MDT 2013 and, as above, you can confirm the corrected values from the built in documentation and the examples provided there.

In the next part of this blog series we will be covering off Selection Profiles and application of drivers to endpoints and to the WinPE images used to boot client machines for MDT.