Tag Archives: task sequence variable

MDT – Put the domain join where it belongs..

Published / by Rens Hollanders / 51 Comments on MDT – Put the domain join where it belongs..

Hi Guys and Gals,

Long time no see. Took me some time to move into our new house which had to be decorated with wallpaper, flooring, additional electric and internet wiring etc. So March 2015 will leave a gap in my blog archive, but I’m hoping to compensate this with writing some new articles.

One of them is this one: Put the domain join where it belongs. If you are like me, I like to work with one MDT deploymentshare to rule them all. When looking on social.technet in the MDT forum’s I see many people struggling to combine build and deployment shares together, or shares that have separate settings regarding computer deployment or domain membership.

Now MDT offers four options to create a deploymentshare so flexible you’ll only need one share to truly rule them all:

  1. The customsettings.ini
  2. Multiple customsettings.ini
  3. The MDT Database
  4. Task Sequence Variables

Allow me to explain each option and the pro’s and con’s:

Customsettings.ini: hey If you can manage it per model, macaddress, tasksequenceid etc. thats fine! But usually you are going to end up with a conflict that either strikes your build deployment or your deploy deployment. Most issues I see here are domainjoin and capture related.

figure 1.1: CustomSettings.ini

customset000

Multiple customsettings.ini, you can specify which ini file to process right into your task sequence “gather” step; this makes your deploymentshare more flexible and forces a specific task sequence to use a different ini file for processing then let’s say the default task sequence. Editing the Gather step is an option, but since you’ll have to edit it multiple times in one task sequence, it’s easy overlooked and prone to error when making typo’s

figure 1.2: Multiple customsetttings.ini

customset002

If you are planning on changing the gather step’s, then please take into consideration there are four of them in every deployment task sequence:

The first is during Initialization, the second during Preïnstall the third during State Restore and the last one can be found during Imaging

figure 1.3: Configuring different CustomSetting.ini

customset001

Then there is the MDT Database, store settings that would otherwise end-up in your customsettings.ini individually based per machine, make and/or model, roles or location, a very good alternative to use but a little bit overpowered when just wanting to make the difference between machines joining a domain or getting captured.

figure 1.4: Using the MDT database integration

mdtdb001

figure 1.5: Properties of a MDT database object (A customsetting.ini of your own)mdtdb002

Task Sequence variables, this to me is the most powerful option of all. Let’s say I want to specify a property which may not occur anywhere else, simply put a task sequence variable at the front of your task sequence.

figure 1.6: Using task sequence variables in your task sequence

tsvars001

Just as you would post information about capturing your reference build in the build task sequence, you could do exactly the same for the following values regarding domain joins:

  • JoinDomain=contoso
  • DomainAdmin=mdt-domainjoin
  • DomainAdminDomain=contoso
  • DomainAdminPassword=P@$$w0rd
  • MachineObjectOU=OU=Computers,OU=Laptops,DC=contoso,DC=local

This prevents machines that are intended to be captured, end up domain joined and machines that are deployed and are domain joined to be captured (which will result in error, since sysprep will not allow a domain joined machine to be generalized for capture).

Hope this helps in gaining insight in how to achieve a more flexible MDT deployment.

Cheers! Rens

 

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 😀