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
This information can also be specified elsewhere, specified in three different ways:
- 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
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
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
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
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
So in talking terms of priority:
- Unattended.xml goes above nothing
- CustomSettings.ini goes above Unattended.xml
- Database goes above CustomSettings.ini and Unattended.xml
- 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 😀
Could you explain in detail how you can retrieve all the variables that are used during a TS? you say to use trace64.exe or trace32.exe. But do I need to start this tool in winpe? and where can I find this?
Good question, for more information about where to get and find trace, I can redirect you to this site: Trace64 finally here to stay – But it is hidden and on where to find the right log files witch you can watch with trace: Where to find the right MDT 2010 logs.
A good start for you, will be by adding the following line to your CustomSettings.ini, if not already done so:
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! From there you can view all the properties, queried results and task sequence variables MDT work with, in combination with the Unattended.xml, CustomSettings.ini and Task Sequence Variable.
just do a search, there’s a bunch including a vbs that does lookups:
You made some really good points there. I checked on the internst for
more info about the issue and found most people will go along wityh your views
on this web site.
“So in talking terms of priority:
Unattended.xml goes above nothing
CustomSettings.ini goes above Unattended.xml
Database goes above CustomSettings.ini and Unattended.xml
Task Sequence Variable, goes above Database, CustomSettings.ini and Unattended.xml”
What does Database stand for and at which point of the process does it do it’s input?
Hi Anton, thanks for your comment and question. The database I meant, is the MDT database which can be integrated with MDT optionally. If the database is integrated it will insert/merge the information it holds about computers, make and models, roles or locations between CustomSettings.ini and Unattended.xml. Ok? If it’s still not clear give me a shout out!
Thank you for quick reply! When would I want to use MDT Database (DB)? How would I fill it? What are you referencing to answer these questions?
You would want to use the MDT database to achieve full automation (for example). Let’s say you have 100 machines, which (since you’ve kept a strict CMDB) have it’s MAC-Address / Serial Number and Hostname available. Then you can import this data into the MDT database. This will let you achieve a fully automated Light Touch Installation with MDT.
Since the MDT database can be queried if it has a match with a computer, make and model, location and or role, and have it’s hostname automatically filled in during deployment.
This is an example of why you want to use the database.
The risk of having a fully automated installation, is that for example, if you have configured PXE boot, and an end-user presses F12 for PXE boot, the machine will start installing no mather what, since it’s fully automated 🙂
What is the main purpose of Bootstrap.ini? Is there anything that I can do in it that I can’t do in CustomSettings.ini?
The purpose of the bootstrap.ini is to provide a connection from within WinPE from a target machine to the deployment share, to start a task sequence, to deploy an operating system or perform another task.
Is there any way I can use SkipCapture property in the CustomSettings.ini (CS) to skip the Capture Image page of the Deployment Wizard (DW) but at the same time pass in parameters for initiating sysprep and capture processes along with directory for captured wim placement?
Yeah sure, it’s SkipCapture=YES add this to your cs.ini and the page will never appear again!
If I do that then the Capture process never kicks in. OS gets installed and the process stops. I would like it to continue to sysprep and capture the image.
This is what I’m currently trying to use:
and it is not working out(
By the way thank you for such quick replies!
Have a look at these properties, these need to be present so successfully capture an image, and as far as I can see, you have forgotten the DoCapture=YES in your customsettings.ini:
See this blog: http://renshollanders.nl/2013/02/mdt-2012-settings-for-fully-automated-lti-deployment-part-ii-customsettings-ini/
Thank you for your time and wisdom)
You are most welcome. Did it work?
Yes, it did. Thank you!
How does unattend.xml operate in MDT? Am I correct in my understanding that it gets filled by inputs form the Task Sequence? Or inputs from CustomSettings.ini get passed in there too? I’m looking to create a custom image that I can put on a UFD along with an Unattend.xml so whenever a laptop gets broken(from SW point of view) I could just plugin that UFD, boot from it, and have my tool ready. Could you point me in right direction on how to do it correctly?
The unattend.xml residing in the task sequence ID folder, under .\DeploymentShare\Control\
is being copied to the target system, and merged with the properties that are injected by either the customsettings.ini, task sequence variables or the MDT database. This will generate a dedicated unique unattend.xml for each target machine (since it holds the hostname etc.)
To create the thing that you need, you’ll need to look into these blogs:
Since I haven’t got any hands-on experience with it.
Hope the links provided are usefull.
Do you know if there is a way to retrieve the unique unattend.xml after it has been merged with CS.ini, TS, and MDT DB?
Yes, it’s located in C:\Windows\Panther on every machine deployed with MDT.
Again thank you very much for your time and knowledge!
When you look in ZTIGather.xml, there are some properties that have “last value wins” and some that have “first value wins”. According to your example above, setting the OSDComputerName, it dosen’t look like this is the case? Do you know why?
Had to look up the last writer / first writer wins. Found some info about that here: http://deploymentresearch.com/Research/Post/365/Creating-custom-variables-in-MDT-2013
To my knowledge the OSDComputerName is indeed something that cannot be altered after it has been processed. However you have to see the 4 option’s I’ve explained, happen before or during the gathering process. When ZTIGathering.wsf is finished, the OSDComputerName has to be known, the fact that it either comes from a database, task sequence variable, customsettings.ini or is manually entered in the unattend.xml doesn’t change a thing.
But as the website explains, it seems to me that it is possible to change the %deployroot% for example during deployment, a computername however can’t be changed.
I use Microsoft Deployment Services. I use unattended files and in both domain computers and personal computers. They serve good both in computer naming and user naming and integration in Active Directory. But it has some cumbersome. Installing OS and applications then capturing image. and application installation is not customizable in MDS. Sotware installation is customizable in MDT. Is it possible taking all settings from unattend.xml except software installing which can be from MDT.? Therefore as a result when a user install his computer he will just choose software but other settings will automatically delivered.
Hi Taric, if I understand you correctly, this is basic MDT material. Installing machines, but give the person who installs the machine the option to choose software which he wants to install out of the box.
Have a look at this post: http://renshollanders.nl/2013/02/mdt-2012-settings-for-fully-automated-lti-deployment-part-ii-customsettings-ini/
Import some applications and set the SkipApplications property to NO
Thanks for a really really quick answer. I will check it. I used to deploy computers via powershell scripts, WDS an unttended files. But windows 10 have lots of changes. i am considering if i can merge WDS and MTD. And this post was really helpful for me about precedence
You can import resources that you use in WDS easily in MDT, and choose to use WDS from that moment on only as a transport vehicle for your boot.wim file that MDT generates. From there you can use MDT.
Rens, (me again) Listen what could cause a LiteTouch script to NOT pass the values from CustomSettings.ini to the unattend.xml file?
According to BDD.log there was no value set for computername, _smsorgname and a few others that I def have specified in the ini.
It’s really good article. I’m in a situation where I have MDT 2010 x86 installation with Windows 7 x86 deployment setup and working fine. Now I want to deploy x64 windows 7 using same setup so I have created the x64 wim and separate task sequence and added drivers too. Updated the deployment share with x86 and x64 both option checked.
Now when i network boot the client PC i see winpe x86 and winpe x64 but when i select x64 winpe for deployment it failed with error saying couldn’t make connection to deployment share while if i boot with x86 winpe I only x86 task sequence and not x64 task sequence.
Please advise what im missing here and can i deploy x64 windows 7 using mdt2010 x86 version?
Yes you can deploy Windows 7 x64 with MDT2010 x86 although I strongly advise you to upgrade to the latest MDT version and Windows ADK for Windows 10.
From what you are saying I think your x64 boot image lacks the correct network drivers. Remember that the x86 boot image can be used for both x64 and x86 deployments, while the x64 bit boot image is for x64 bit deployments only.
I created a custom page in the UDI designer with check boxes relating to security group variables. I am trying to call the variable in a script but when checking the smsts.log insee the script running as: script.cmd %AD_group%.
I was expecting it to display the value of the variable so: scrupt.cmd UK_Computers.
Any ideas? I am running the task sequence from media if that makes any difference?
Unfortunately I cannot answer this question, as I have no experience with UDI. The only thing wat you can try is to make the custom variable / property known in the myproperty section of the customsettings.ini. Then MDT will parse this through.
i have some questions for you
What will happen if i delete the customsettings.ini?
who installs drivers present in boot.wim(litetouch.iso) and what happens to them later?
i did a test, i deleted the litetouch.vbs from the X drive just before the deployment starts but when i reboot the machine it comes back, why so?
can u explain task sequence steps for me, please?
During each deployment a number of files (mostly scripts) are copied to the local machine. Therefore, deleting them from your deploymentshare wouldn’t make any difference during the deployment of that machine. If you delete the customsettings.ini MDT does not know how to respond when the file is called. I suspect the entire share and it’s deployment mechanism will stop working. Drivers in the present boot image are selected through selection profiles, this can be altered on the WinPE tab, on your deployment share properties.
not sure if its the right place to ask but i’m really lost so i will give it a shot.
I never had an issue with capturing lite-touch images on MDT 2013, 32 bit machines or 64bit. i am using windows deployment wizard and there i had the capture and sysprep task sequence always. but now when im trying to do so, a lot of my task sequences including the very important Capture and Sysprep are gone. when im using 32bit machine its there but not with the 64bit so im assuming something changed but what? its driving me crazy! I updated the Deployment work bench a couple of time and made sure that Platform supported are both ticked.
I’m using MDT 2013 6.3.8330.1
WDS 64bit machine.
Please check your deploymentshare properties and task sequence properties if there is a checkbox set, preventing it to be shown with x64 systems.
You have checkboxes on the task sequence “This can run on any platform” or “This can run only on the specified client platforms”, and perhaps there is a checkbox enabled there. It is not very easy to see, and easily missed.
On the deploymentshare properties tab, make sure both platforms supported are checked.
thanks for the fast reply!
I triple checked that. “This can run on any platform” is checked and also on the deploymentshare properties both X86 and X64 are checked.
this is what i get from the OSDLOGS under MININT folder: (look at the middle part where it sais – “<![LOG[Skip cross platform x86 install from x64 Windows. CC]LOG]!" CC is my task sequence for "Capture and Sysprep". any idea why it skeeps that task sequence? sorry for dropping on you like this i have searched the web and found nothing.
Thank you again.
If you are deploying a 32 bit operating system with a 64 boot image this will not work. But deploying a 64 bit operating system with an 32 bit boot image wil work.
Perhaps this is the case then.
x86 boot image does x86 and x64, x64 boot image only does x64 operating systems.
I am capturing a 64bit windows with 32bit boot image so no luck there. I will try to deploy a different 64bit image and capture it and see what happens.
Thank you for your time…
by the way – i am using cscript command with litetouch.wsf if it matters.
Hello Rens Hollanders,
I have a question regarding the user accounts. I captured the image on reference computer after disabling the administrator account, and It has an user account ‘abc’. Then I deployed to physical machine using MDT and WDS. After deployment the physical machine directly login in to the admin account. I have to logoff that and login to ‘abc’ account. Is there any changes I can make so that it goes to ‘abc’ account after deployment? The machine is connecting to domain.
Yes you can force a post configuration script that configures the desired account to logon.
Add this in a powershell script:
# Set registry
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” -Name “AutoAdminLogon” -Value “1”
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” -Name “DefaultUserName” -Value “User”
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” -Name “DefaultPassword” -Value “User”
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” -Name “DefaultDomainName” -Value “.”
Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” -Name “AutoLogonCount” -Value 9999
Think this is happening due to the sysprep generalize step before image capturing.