Tag Archives: customsettings.ini

MDT 2013 – Configuring your environment for Bitlocker deployments with TPM, Windows 8.1 and MDT 2013

Published / by Rens Hollanders / 18 Comments on MDT 2013 – Configuring your environment for Bitlocker deployments with TPM, Windows 8.1 and MDT 2013

In a previous post I explained how we could deploy the HP Elitepad 900 with the Microsoft Deployment Toolkit.

For that same project that I have recently worked on, it was a requirement that this tablet would be deployed unattended, securely and reproducible.

I defined the following actions that needed to be done:

  1. Extending the AD Schema
  2. Update policy templates (since we where running Server 2008 R2)
  3. Configure ‘Bitlocker’ Group Policy Settings
  4. Configure CustomSettings.ini
  5. Configure Task Sequence
  6. Configure Unattended.xml
  7. Use a domain account
  8. Perform a test deployment

1. Extending the AD Schema

On the internet there was a lot of information to find on how to achieve this. The information that I found useful was mostly from Microsoft’s own blog sites and was very helpful in configuring this to get it to work first time right.

The blogs that helped me achieve this:

From the link below a complete documentation guide and 4 vbs scripts help you configure the Active Directory Domain Environment to be prepped for storing Bitlocker information into Active Directory.

Requirements

The basic requirements on how to achieve having bitlocker write information into active directory, can be derived from the document: “Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information.doc” which can be downloaded from the link I have provided.

2. Update policy templates

Updating the policy templates makes sure, that the Group Policy Manager can posses over the latest available policy templates out there. When running a Server 2012 R2 domain controller, these templates are already available, but if you’re running an earlier version of Windows Server (from 2003 sp2 up to 2008 R2), it is recommended that the policy templates are updated.

This can be done by:

  1. Downloading the Administrative Templates (.admx) for Windows 8.1 and Windows Server 2012 R2
  2. Updating the current templates with the new templates

Step 2. is actually quite easy, type in your FQDN followed by “\SYSVOL\Policies” which brings you to the folder where the policy templates are located. Just in case before you do anything, creating a back-up of the current policy files might come in handy in case you want to rollback or something goes wrong.

Just paste the new templates in the Policies folder, to find the new Server 2012R2 and Windows 8.1 policies available in the Group Policy Manager straightaway.

3. Configure ‘Bitlocker’ Group Policy Setting

Configuring the required group policy settings for Bitlocker, makes sure all the necessary information about the computer object will be stored in Active Directory that is being deployed. In the zip file at the bottom of this page you will find the desired GPO configuration in HTML, needed to store the information Active Directory. Also these policies are perfectly explained in the referenced document above, and in the provided ‘useful links’  section at the bottom of this page. And to get you started, I have provided a screenshot of those policies right here:

figure 1.1: Bitlocker GPO Configuration

bitlocker-policy

4. Configure CustomSettings.ini

Configuring the CustomSettings.ini. Basically there is enough information to find in the documentation of MDT itself on how to configure the properties for bitlocker, and which properties you can configure and what their values are. However I did some investigation, and came up with the following configuration:

figure 1.2: DeploymentShare properties, Rules (customsettings.ini)

bitlocker-csini

codeblock 1.1: customsettings.ini rules

As you can see I have set my priority on Model 1st and Default 2nd.

So all rules stated under  HP Elitepad 900 overrule the Default section, and only apply for this model.

For clarification I often comment my customsettings.ini, since the people who are going to work with it, may want to understand why a certain setting is set.

BDEInstallSuppress=NO
BDEWaitForEncryption=FALSE
BDEDriveLetter=S:
BDEDriveSize=2000
BDEInstall=TPMKey
BDERecoveryKey=AD
BDEKeyLocation=C:\Windows\BDEKey

5. Configure Task Sequence

When the CustomSettings.ini is configured, the next thing we need to do is make some adjustments in the task sequence on the Bitlocker part:

figure 1.3: Task Sequence properties, configuring bitlocker

bitlocker-ts

In the ‘State Restore’ section, click on the “Enable Bitlocker” step, and check the following:

  • Current Operating System Drive
  • TPM Only
  • Choose where to create the recovery key
  • In Active directory

Alternatively you may check: “Wait for bitlocker to complete the drive encryption process on all drives before continuing the task sequence execiution

This means, that the Task Sequence will wait until the entire drive is encrypted, then perform a reboot, and continue with the task sequence.

6. Configuring Unattended.xml

Configuring the Unattended.xml has little to nothing to do with configuring bitlocker, however, to achieve a fully unattended installation. It is recommended you extend your Windows 8.1 Unattended.xml in the TaskSequenceID folder with the following additions:

codeblock 1.2: Windows 8.1 unattended.xml additions to suppress Windows 8.1 setup wizard

The following strings make sure the Windows 8.1 setup will not interfere with the process.

7. Use a domain account

Since we are configuring deployments to work with Bitlocker and storing the recovery password into Active Directory we at least need some form of authentication. My experiences are, that the domain join account which is used to join the machine to the domain, has enough privileges to first: create the computer object in Active Directory and second: write the bitlocker recovery key and TPM owner information into Active Directory on the same computer object.

A domain account does not need all kind of fancy privileges and certainly not needs to be an Domain Admin. To see which privileges are required, please visit the following two blogs which explain it perfectly:

8. Perform a test deployment

The only thing that remained was performing a deployment test, which of-course I did, and the results were very satisfying 🙂

figure 1.4: trace64.exe – bdd.log

trace64-tmp

figure 1.5: computer object properties – active directory

computer-object-properties

figure 1.6 computer object properties – bitlocker-recover

computer-object-bitlocker

Usefull links

These links helped me on my way achieving this:

Find attached the resultant set of policy that has been configured in Group Policy Manager, a copy of the BDD.log of a successful deployment, the screenshots used in this blog, and a copy of my customsettings.ini rules that I have used.

zip
BlogContents.zip

If there are any questions or improvements you’d like to share, please feel free to contribute in the comment section!

Thanks for reading this blog! 😀

ps. forgive me for the Dutch computer object property screenshots, this is just for the moment until I can retrieve some English looking panes.

MDT – Unattended.xml, CustomSettings.ini, Task Sequence Variable, which setting takes precedence over which setting?

Published / by Rens Hollanders / 43 Comments on MDT – Unattended.xml, CustomSettings.ini, Task Sequence Variable, which setting takes precedence over which setting?

I sometimes see a question on social.technet, which gets me thinking, this could be good material for a blog.

So was this, a question about which specified values take precedence over each other.

As some of you might know, MDT works with, and can be provided with certain values that are needed as input for an Operating System Deployment.

Normally certain values can be and will be provided during deployment. For example, when the MDT wizard pages are displayed, to ask for a specific information, like “Computer Details”, where the OSDComputerName of the machine can be injected.

figure 1.1: Deployment Wizard – Computer Details

osdcomputername_cs.ini

This information can also be specified elsewhere, specified in three different ways:

  • Unattended.xml
  • CustomSettings.ini
  • Task Sequence Variable

The question however is, which setting takes precedence over which setting? Only one way to find out 🙂

So I have set-up my MDT environment like this:

figure 1.2: Deployment Share Properties – Rules

cs_rules

As we can see here, the Wizard pane “SkipComputerName” is set to NO, which means it should show the computer details wizard. The value underneath “OSDComputerName” already reveals, that if this value is specified in the customsettings.ini this value will be used as the designated name for this particular machine.

However, we can also specify the OSDComputerName property somewhere else, and what happens if it is specified twice or triple?

Therefore I have created the following step in my deployment task sequence:

figure 1.3: Task Sequence Variables

osdcomputername_tsvar

a Task Sequence variable which holds the following information: Task Sequence Variable (Name) and (Task Sequence Variable) Value. As we can see the value is: “OSBUILD-TSVAR” while in my CustomSettings.ini the value for OSDComputername is OSBUILD-CSINI.

Now when I start a deployment I can see the following in my logfile (which can be perfectly read with trace64.exe or trace32.exe (depending on the version of the operating system architecture):

figure 1.4: BDD.log

trace_csini_vs_tsvar

In the logfile we see, that at first the value which resides in the CustomSettings.ini is used while a little bit after, the task sequence variable value specified in the task sequence is being used.

Lastly there is the Unattended.xml a file we haven’t discussed before, but I think along the way we all know the answer, since it’s already hidden (or visible 😉 ) in the logfile:

figure 1.5: BDD.log

trace_unattended

Because when we look in the logfile of a running or completed deployment we will find values like the following everywhere: “Updated C:\MININT\Unattend.xml with BitsPerPel=32 (value was 32)” which means, that any value specified in either CustomSettings.ini or Task Sequence Variable, or settings stored in a database, will take precedence over a specified value in the Unattended.xml. So that right after the deployment has started, the gather step will run, and will collect information from all available ‘sources’, CustomSettings.ini, Task Sequence Variable or the default Unattended.xml which resides in your “DeploymentShare\Control\TaskSequenceID” folder:

figure 1.6: Running Lite Touch Installation

 

rh

So in talking terms of priority:

  1. Unattended.xml goes above nothing
  2. CustomSettings.ini goes above Unattended.xml
  3. Database goes above CustomSettings.ini and Unattended.xml
  4. Task Sequence Variable, goes above Database, CustomSettings.ini and Unattended.xml

And then there’s also the possibility to influence values in the CustomSettings.ini with the “Priority” parameter, which I will discuss in a later blog.

I hope this can be an eye opener for everyone who is working with these three types of files and configuration settings, and hopefully it will enable you to create a flexible and transparent way to deploy your operating system to multiple computers, hardware, different types of machine. As long as you remember, the greatest common divisor (or denominator) of a setting, should always be provided, on an area where it’s impact is the smallest.

Meaning, that it has no use to modify the OSDComputerName variable each time when doing a new computer deployment. If you are going to deploy 1000 machines, leave the field empty. If you need to specify a workgroup for a particular task sequence or type of deployment, specify it in the customsettings.ini (or in the task sequence itself) whatever suits you best.

I think a nice goal to strive to, is to adjust both your task sequence and/or customsettings.ini as little as possible or as necessary.

Thanks for reading and keep on automating my padawan learners 😀

 

 

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

Published / by Rens Hollanders / 46 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:

[Settings]
Priority=MACAddress, Default
Properties=MyCustomProperty

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.

[00:00:00:00:00]
OSDAdapterCount=1
OSDAdapter0EnableDHCP=FALSE
OSDAdapter0IPAddressList=192.168.1.45
OSDAdapter0SubnetMask=255.255.255.0
OSDAdapter0Gateways=192.168.1.1
OSDAdapter0DNSServerList=192.168.1.11,192.168.1.12
OSDAdapter0DNSSuffix=contoso.local

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)

SkipTaskSequence=YES
TaskSequenceID=OSB001

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.

SkipComputerName=YES
OSDComputerName=OSBUILD

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.

SkipCapture=YES
DoCapture=YES
ComputerBackupLocation=\\server01.contoso.local\deploymentshare$\Captures
BackupFile=W7ENTSP1x64EN.wim

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.

[Default]
_SMSTSOrgName=Contoso IT
OSInstall=Y

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.

SkipTaskSequence=NO
SkipApplications=NO
SkipAppsOnUpgrade=YES
SkipCapture=YES
DoCapture=NO

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

NEWCOMPUTER
The target computer is a new computer that has never been a member of the network.
REFRESH
The target computer is an existing computer on the network that needs the desktop environment standard to be redeployed.
REPLACE
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.

SkipAdminPassword=YES
SkipProductKey=YES
SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER

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:

SkipDomainMembership=YES
MachineObjectOU=OU=Computers,OU=Laptops,DC=contoso,DC=local
NetworkLocation=Work
JoinDomain=contoso
DomainAdmin=srv-rollout
DomainAdminDomain=contoso
DomainAdminPassword=

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

SkipUserData=YES
UserDataLocation=\\server01.contoso.local\deploymentshare$\USMTdata

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:

SkipComputerName=NO

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:

SkipLocaleSelection=YES
SkipTimeZone=YES
TimeZoneName=W. Europe Standard Time
TimeZone=110
AreaCode=045
Language=00000413
SystemLocale=00000413
UserLocale=en-US
UILanguage=en-US
InputLocale=nl-US
KeyboardLocale=nl-US

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
BitsPerPel=32
VRefresh=60
XResolution=1
YResolution=1

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

SkipBitLocker=YES
SkipSummary=YES

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

Home_page=http://www.contoso.com

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.

EventService=http://CONTOSO01:9800
SLShareDynamicLogging=%DeployRoot%\Logs\%COMPUTERNAME%
HideShell=YES

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)
WUMU_ExcludeKB1=976002
;Microsoft Silverlight (KB2636927)
WUMU_ExcludeKB2=2636927
;Windows Internet Explorer 9 for Windows 7 for x64-based Systems (KB982861)
WUMU_ExcludeKB3=982861
;Bing Desktop (KB2694771)
WUMU_ExcludeKB4=2694771

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:

zip
CustomSettings.txt