The Lite-Touch wizards prompt for a default homepage. This can also be set as a property. Useful to uses when there’s a change in your infrastructure. It will save you changing all your task sequences.
Home_Page=https://scriptimus.wordpress.com
Now that’s branding.
When I previously performed my deployments using MDT there were times when I needed to edit the unattend.xml to change settings that were not available in MDT 2010 by default. One thing I usually did was set the horizontal resolution to 1366 pixels. To do this I’d open the Windows System Image Manager and navigate to the OOBE configuration pass as shown below:
It turns out that there was a setting in MDT that could have saved me the trouble. In the Customsettings.ini simply add this line:
XResolution=1366
Now for the science: Windows 7 automatically defaults to the native resolution (if the correct drivers are installed). It will not however, automatically exceed the maximum resolution limit that is configured in the unattend.xml answer file during the OOBE (Out of Box Experience) configuration pass.
The unattend.xml template that comes with MDT is configured with a horizontal resolution of 1024 and a vertical resolution of 768. This means if you deploy a modern widescreen laptop the maximum resolution is capped to 1024 by 768 so the display appears square. To fix this I currently set the horizontal resolution at 1366 and this covers both laptops and desktops.
There are other display property’s that can also be configured in MDT:
BitsPerPel=32 VRefresh=60 XResolution=1366 YResolution=768
These settings can be used in a customsettings.ini file, a configuration database or used as a task sequence variable.
Although not widely known, you can store your Lite-Touch deployment log files centrally on a network share. This can come in handy when troubleshooting or auditing.
There are 2 types of logging available. The first is standard logging, which stores the logs on a network share at the end of a deployment. The second is dynamic logging which writes the log files in real-time to a network share throughout the deployment process.
To do this simply set the property as usual in the customsettings.ini or deployment database. In this example of standard logging, the log files are copied to a share at the end of the deployment process:
SLShare=\\Scriptimus-01\Logs$
This example shows dynamic logging, where the log files are copied in real-time to a share throughout the deployment process:
SLShareDynamicLogging=\\Scriptimus-01\Logs$
In most cases you can just create a folder called logs in the deployment share itself and target that location for your logs:
SLShareDynamicLogging=\\Scriptimus-01\DeploymentShare$\Logs
OK, so this is a very basic post but if you don’t know it. . . ahem!
The scenario is you want to apply branding to this pesky banner and change the default wording of “IT Organization”. I mean, for one thing, just look! Organisation is spelt wrong.
Solution: In the customsettings.ini create a line like this
_SMSTSOrgName=Scriptimus Ex Machina
Ta-daa! Your Lite-Touch deployments are now branded. Much more handsome I must say.
When working towards a completely automated Lite-Touch deployment it can appear somewhat counter-intuitive to automate the task sequence selection as a final step. After all it’s one of the first things you click on during the deployment wizard. It does makes sense however that you would want at least some manual element left when testing so you know that the automation is working as expected.
Strangely, there are 2 commands you can use to automatically select a particular task sequence. They both target the task sequence ID. They can be used in the customsettings.ini or Deployment Database. The first example is:
TaskSequenceID=Win7x86Custom
the second is:
BuildID=Win7x86Custom
I have no idea why there are 2 options. They both appear to do the same thing. Now all that’s left is to skip the Select a task sequence to execute on this computer pane during the deployment wizard. In your customsettings.ini enter:
SkipBuild=YES
or
SkipTaskSequence=YES
SkipTaskSequence can’t be used in the deployment database. Other than that, they’re the same.
In order to automate the User State Capture and Restore task sequence steps in MDT 2010 you will need to configure your deployment share so it knows where to store the data. MDT 2010 installs the User State Migration Tool for usage prior to capture and restore tasks.
If you’re currently using Windows Easy transfer to migrate user settings and files during deployments then this post will help you to advance to the next level using the User State Migration Tool in MDT 2010.
This first example tells MDT to try to determine where to store the data. If there is enough space it will store it locally utilising the hardlinks feature:
UserDataLocation=Auto
This example shows a User State Migration using a network share:
UserDataLocation=NETWORK UDShare=\\SRV01\MigData$ UDDir=%OSDComputerName%
To skip the Lite-Touch wizard pages Specify whether to capture an image and Specify whether to restore user data enter this property in your customsettings.ini file:
SkipUserData=YES
After using the settings above, MDT is able to automate User State Migrations to the locations you have configured using the power of the ZTIUserState.wsf script.
Now, that takes care of the where but there’s still the matter of what. In the real world you will want control over the data that you migrate so read on for the advance bit.
Firstly the task sequence step Generate Application Migration File runs the script ZTIAppXmlGen.wsf with the /capture switch. It creates a file called ZTIAppXmlGen.xml which contains a list of all the extra file extensions on the machine. This will be used later by scanstate.exe to target new file types.
Next, the task sequence step Capture User State is run. It uses the ZTIUserState.wsf script with the /Capture switch to leverage the Scanstate.exe tool from the USMT to capture the user state data.
Finally, after the new OS is laid down, the task sequence step Restore User State is run. This step uses the ZTIUserState.wsf script with the /Restore switch to leverage Loadstate.exe to restore the captured user state data.
For those who need to know more about USMT, I suggest watching this webcast series, for all others continue reading.
There’s an extra switch in the ZTIUserState.wsf script. /Estimate generates a log file called USMTEstimate.log. This is used for capacity planning your migrations.
You may want to capture specific user profiles, in which case you can use the UDProfiles property in your customsettings.ini to list the user profiles. This is an example:
UDProfiles=Administrator, Scriptimus, User2, User3
If you’ve created customised XML files that surgically target your data you can use them in your migrations by using the USMTMigFiles property to call them in your customsettings.ini. They need to be sequentially numbered like in the example below:
USMTMigFiles001=MigApp.xml USMTMigFiles002=MigUser.xml USMTMigFiles003=MigSys.xml USMTMigFiles004=MigCustom.xml
If you’ve created a custom Config.xml using scanstate.exe to limit which files are migrated then you can use this custom XML file by using the USMTConfigFile property:
USMTConfigFile=Config.xml
Finally, you can use ScanStateArgs and LoadStateArgs to customise the way that USMT is run during the migration process.
ScanStateArgs=/v:5 /o /c
The /v switch in the above example tells scanstate.exe to increase the level detail in your log files (0-15 are the options). The /o switch will overwrite any data in the target migration store as opposed to just returning an error and stopping. The /c Switch will continue on errors unless something really really bad happens.
This is an example of LoadStateArgs usage:
LoadStateArgs=/v:5 /c /lac
It’s the same as ScanStateArgs except for the /lac switch which tells Loadstate.exe that if it’s migrating a local account and it doesn’t exist on the target computer then it should disable it after creation.
Below is a list of resources for the User State Migration Tool.
User State Migration Tool 4.0 User’s Guide
USMT 4.0 XML Elements Reference
My final words are only to say the User State Migration Tool is a powerful way of controlling your large scale enterprise migrations and more imporantly. . .it’s free!
If you are deploying Windows Vista/7 Professional, Enterprise or Server 2008(R2) and you have a KMS host configured, you can simply ignore the sections that ask for product keys during Lite-Touch deployments and skip past them without adding aditional propertys. The KMS keys are stored in the products themselves and the clients will attempt to activate automatically after installation.
If you are using Windows XP, Server 2003 or retail editions of Windows Vista/7 then you will have to provide a product Key at some point during your deployments.
Firstly to skip the pesky product key prompt add this line to your customsettings.ini:
SkipProductKey=YES
Next, to add a product key to your deployment use this example in either the customsettings.ini or as a task sequence variable:
ProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
This will cause MDT to enter the product key in the unattend.xml (for Vista, 7 or 2008) or unattend.txt (for 2003 server, XP) during the deployment.
If you intend to automate your MAK activated deployments you can use this property in either the customsettings.ini or as a task sequence variable:
OverrideProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
If you don’t understand how Microsoft Volume Activation works, I suggest reading up on the Technet website or the Volume Activation Planning Guide.
When automating your Lite-Touch environment, you should first consider the usage of your task sequences. There are 4 task sequence usage scenarios in MDT 2010, they are the new computer scenario, the refresh computer scenario, the replace computer scenario and the upgrade computer scenario.
I will explain deployment scenarios in detail in a future article but for now to bypass the pane displayed in the deployment wizard use this line in your custom settings.ini:
SkipDeploymentType=YES
Then to select your deployment type. For a new computer scenario use this example:
DeploymentType=NEWCOMPUTER
The other options available are REFRESH REPLACE and UPGRADE. Again I will explain deployment scenarios fully in a future article.
To automate the TimeZone setting in your Lite-Touch deployments, edit the CustomSettings.ini file and add the following line for Windows XP/2003:
TimeZone=85
or for Windows Vista/Server 2008/Windows 7/Server 2008 R2 use:
TimeZoneName=GMT Standard Time
Now to hide the pane during the Lite-Touch deployment wizard, enter:
SkipTimeZone=YES
If you are in another timezone you can get a list of the values here. Or you can use the Windows TimeZone Utility from the command line to interogate your current windows 7 machine. Simply open a command prompt and type:
tzutil /g
Remember these settings can also be used as task sequence variables, if you are supporting multiple regions. For Windows XP read my article here.
As you may be aware, the local administrator account is disabled by default in Windows 7. MDT 2010 re-enables it and resets the password. This is initially done when you create a new task sequence so you don’t really need to type it in every time during the Lite-Touch Deployment wizard.
You can skip the Administrator Password wizard page by using this property in the customsettings.ini.
SkipAdminPassword=YES
You can also override the admin password for all of your task sequences by using this property in you customsettings.ini.
AdminPassword=P4$$w0rd
Or you can set it per Task Sequence as a Variable. Handy if your security manager tells you to start using a new admin password immediatly as there’s just one setting to change.
Scriptimus Ex Machina 