If you’re just learning MDT perhaps you’ve have had some time to look at and tweak your customsettings.ini file, or at the very least heard about what this one little file can do to take your deployments to the next level.
The real magic of MDT lies in its flexibility, as its scripts allow us to not only dynamically install and configure an OS, but they give us the ability to automate many, many steps of the MDT 2012 lite touch wizard as well. Granted, getting everything automated does take some work as well as some trial and error, but believe me, it’ll pay off in dividends down the road. Joining 200+ workstations to the domain is tedious and prone to user error. Automate just that one step and you can save hours and hours down the road.
The best way to automate all of this even further is with tweaks to the customsetting.ini file a deployment share. This one file is quite easily the single most important ini file in your whole share, it’s here where you can control just about everything and anything regarding how your share behaves, and with the right tweaks, you can get your share to an almost “zero touch” deployment, and automate everything down to the host name of the systems being deployed, domain and OU to join, and applications to install.
By default, MDT ‘Lite Touch’ isn’t very light. A stock MDT configuration’s WinPE wizard requires you to answer well over a dozen questions before you can start, and forces you babysit the deployment from beginning to end, answering tedious questions about whether you’re backing up user info, regarding passwords or info about the time zone. To fully automate your deployments, changes will need to be made to the customsettings.ini file.
The rules set here are what the lite touch wizard uses to know about such info as time zone, default keyboard layout, the mandatory applications, and even how the PCs are named. An extensive portion of the logic and custom settings configured in the deployment share are controlled by this file. Again, by default, very little is configured with this file, but a well configured deployment share will have most if not all prompts skipped in the deployment process. Ideally there should be very few questions that must answered by a tech when rebuilding a PC, if any at all.
NOTE:Make sure to backup this file and\or use the Volume Shadow Copy feature on the server to restore it if you mess it up. You can edit this file directly using notepad, I prefer Notepad++ by loading it from:
Below is a list of my favorite Tips and Tricks to use in a MDT 2012 CustomSettings.ini file…
Display Task Sequence and Hostname during Deployment
_SMSTSOrgName=Running %TaskSequenceID% on %OSDComputername%
This is a newer, trick I love, it’s genius. Rather than putting some worthless info about your organization name, make the wizard at least display what task sequence you’re running on what hostname. It’s brilliant.
This will name the system with the very last four of the serial. Useful for HP systems which have very long serials.
Block Pesky Updates
IE10, Bing Toolbar or some other update not needed at update time? Block them here with WUMU_Exclude, just look up the KB number and they’ll be blocked during the ZTIUpdate phase.
Take Control of Drivers
Note this trick only works if your drivers are organized in such a hirearchy AND if the make and models used in the folders match what WMI reports, but if setup correctly, will save you hours and hours of stress with drivers.
No Product Key? No Problem!
This special setting should allow you to skip the prompt for a product key during deploy.
Got a MAK Key?
This is where you can put a MAK key or a generic install key if you so desire, if this causes trouble leave this out and inject the MAK key into the unattended file.
Do it Live!
Enable this special setting in the customsettings.ini file that hides the windows shell during the deployment so that deployments can safely run from the user’s desk. Some applications don’t like this, I’ve seen older versions of Adobe Acrobat fail to deploy with this setting, but not reader, go figure. This is a setting that’s really best for after you go to production, just make sure it works with your apps first.
Once a final summary is displayed, the system will reboot when you select Finish. Other options are available, but a final reboot is always a good idea. Combine this with the Skip Final Summary command, and your systems will give no final report and simply reboot. I wouldn’t recommend doing that until you’re 100% confident your deployment share is working well and your logs are reporting correctly.
This is where MDT will report all information for live reporting in the monitoring section in the Deployment Workbench. Obviously you need to change SERVER in this example to the IP or preferably hostname of your server
Set TimeZone and Skip prompt in lite touch Wizard
TimeZoneName=Mountain Standard Time
This is an easy thing to skip, especially if you’re only deploying in one time zone.
Set Local Admins
Define groups you want set as a local admin. Make sure restore groups is set in your task sequence for this to work.
Enable Dynamic Logging
Deployment logs are stored in this location. Make sure you have the SMTrace log viewer installed to easily view these files.
Setting Application Defaults
These entries require the GUID of the applications you want to set as default. Installation of these applications will be selected by default but can be unselected at deploy time.
Skipping Application List in Lite Touch Wizard
If you would prefer to set the applications once and not be prompted period, set this and move on with your life.
Some Apps not up for Debate?
These entries will also need the GUID of the applications you want to mandate. Installation of these applications are not up for debate, and will be done on every PC the share deploys. Handy for Office and/or your security software.
Enabling Automatic USMT w/ Hardlinks
ScanStateArgs=/v:5 /o /c /ue:*\* /uel:90
LoadStateArgs=/v:5 /c /lac
The Userstate Migration Toolkit comes with both the WAIK and the ADK. It allows you to save user information either locally using hardlink migration or to save to server or USB. The settings above allow you to store the data on the local disk for all users who have signed into the domain in the last 90 days. Note: Hardlink Migrations don’t work on XP.
Also note that deployment shares can be configured to use a generic service account to both kick off the install and to join systems to the domain. Ideally, there should be two separate accounts for this, but for the sake of time and simplicity one could be used now. These credentials are stored in different places depending on when and where they are being used. The account used for logging into the share will only need permissions to the share. Ideally, the information for the Administrator account to join the domain should be obsufcated in the unattended.xml file.
For more info:
Questions? Comments? Something you think should be on this list? Let me know.