Tag Archives: unattended

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 😀

 

 

 

Installing ‘N-Able’ N-Central client agent to target computers silent / unattended

Published / by Rens Hollanders / 3 Comments on Installing ‘N-Able’ N-Central client agent to target computers silent / unattended

So the company I work for uses N-able’s solution ‘N-central’ to deploy agents to targetted computers to monitor, manage and control them. Because our services department supports multiple customers with the same tool, it is key that we specify customers in N-central with customer pools.

Now when we are installing the N-central client to targetted computers manually, we always need to provide configuration information, for instance the CustomerID, the N-Central servers ip-address and the serverport over which the N-central will communicate.

Having said that, when I first started to look at deploying the client unattended or silent if you will. It became clear to me that documentation about this software is very rare to find. The things that I found were not unambiguous, eventually with some fooling around, testing and trying I came to the following command line:

First of all it is necessary that we extract the provided executable, which contains the real executable “WindowsAgentSetup.exe”, if we dont do that, the provided parameters will not  work.

Then the following additional parameters need to be added to the executable via CMD, BAT or application deployment software like MDT, SCCM:

WindowsAgentSetup.exe /s /v” /qn CUSTOMERID=<ID> CUSTOMERSPECIFIC=1 SERVERPROTOCOL=HTTPS SERVERADDRESS=192.168.1.107 SERVERPORT=443 “

Mind the quote directly after /v” and the space after the SERVERPORT=443 ” command, if we do not provide an additional space, the command will also not work.

For reference, please check N-able’s website about installing probe’s / agents from the command prompt