Mikael Nystrom has another good post on "back to basics". This time on CustomSettings.ini which is a file that commonly gets people confused because of it’s many uses and ways to do things.
One of the most important files in MDT (and in SCCM with MDT) is customsettings.ini, it is the rule file to rule your deployment. Yesterday Johan and I did a session at MMS and besides getting great scores and that is always fun. During that session I did a couple of demos around customsettings.ini and I would like to explain this a bit more. Because if you do understand the rules you can become much more dynamic and that will hopefully lead to less hassle and more work done in less time.
Johan has put up a new post over on his blog.
This procedure works like this: If they computername is in the database already (known), it will assign that name to the PC. If the computer is not in the database (unknown), it will generate a computername based on the prefix and the next sequencenumber.
Step 1- Setting up the Database – detailed step-by-step guide & Video tutorial for this step is available for download in the Videos section – Part 18 of the MDT 2010 Lite Touch – Unleashed series
Step 2 – Add and configure a Stored Procedure + Table for generating computernames based on prefix + sequencenumber. Detailed step-by-step guide & Video tutorial for this step is available for download in the Videos section – Part 19 of the MDT 2010 Lite Touch – Unleashed series
Step 3 – Configure the Deployment Share rules
MDT Documentation Example:
It also is possible to run the custom code as a user exit script from CustomSettings.ini. This provides a mechanism for information to be passed into the CustomSettings.ini rule validation process and provides a dynamic update of MDT 2010 properties.
A user exit script is effectively a function library that can be called during the processing of CustomSettings.ini:
· A user exit script will contain one or more functions that can be called during CustomSettings.ini processing.
· The user exit script is called by specifying the UserExit property and assigning the property name of the script to be called; for example, UserExit=TrimAssetTag.vbs.
· A function is called by specifying the name of a function enclosed in the # characters. For example, if the user exit script contains a function called TrimAssetTag(), it would be called by specifying #TrimAssetTag()#.
· Parameters can be passed to the function in the usual way by specifying the parameter while calling the function. For example, to pass the variable %ASSETTAG% to the function TrimAssetTag(), the function would be called by specifying #TrimAssetTag(“%ASSETTAG%”)#.
· The value returned by the function can be assigned to a variable by assigning the function to that variable. For example, to take the asset tag of a computer and trim it using the function TrimAssetTag(), and to then reassign the trimmed asset tag to the variable AssetTag, the CustomSettings.ini file would read AssetTag=#TrimAssetTag(“%ASSETTAG%”)#.
An example of how this could be used is to determine the task sequence to be run based on a rule that sets the TaskSequenceID property.
Listing 26 is an example user exit script that determines the task sequence to be run based on the amount of available RAM. This script also uses the ZTIUtility logging class.
Listing 26. Example User Exit Script
Function UserExit(sType, sWhen, sDetail, bSkip)
UserExit = Success
oLogging.CreateEntry "UserExit – Determining Task " & _
"Sequence to run based on available RAM", LogTypeInfo
If vMemory <= 2048 Then
SetTaskSequence = "XP_X86"
oLogging.CreateEntry "UserExit – Available RAM: " & _
vMemory & ". Selecting XP_X86 TS.", LogTypeInfo
SetTaskSequence = "Vista_X86"
oLogging.CreateEntry "UserExit – Available RAM: " & _
vMemory & ". Selecting Vista_X86 TS.", LogTypeInfo
The user exit script should be placed in the Scripts folder on the deployment share (for example, D:\Production Deployment Share\Scripts).
To create the user exit script
1. Create and test the custom script to be used.
2. Locate the MDT 2010 Scripts folder (for example, D:\Production Deployment Share\Scripts).
3. Copy the custom script to the Scripts folder.
With the user exit script added to the deployment share (in this case, Z-RAMTest.wsf), it must then be referenced in the CustomSettings.ini file for the deployment share so it is called during deployment.
To call the user exit script from CustomSettings.ini
1. Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench.
2. In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares/deployment_share (where deployment_share is the name of the deployment share to configure).
3. In the Actions pane, click Properties.
4. Click the Rules tab to display the CustomSettings.ini file.
5. Add sections to UserExit.vbs to call the required functionality using the principles described in the previous section. An example CustomSetting.ini file is shown in Listing 27.
6. Click OK to submit the changes.
7. In the details pane, click deployment_share (where deployment_share is the name of the deployment share to configure).
8. In the Actions pane, click Update Deployment Share.
The Update Deployment Share Wizard will start.
9. On the Options page, select Optimize the boot image updating process, and then click Next.
10. On the Summary page, verify the details are correct, and then click Next.
11. On the Confirmation page, click Finish.
Another common use for the user exit script is to dynamically set the computer name from known MDT 2010 properties such as SerialNumber, Model, or Product.
Listing 27. Example CustomSettings.ini for Calling the User Exit Script
Another example of a User Exit script setting the WDS Server name
You can also use %WDSServer%, however that variable work work when launched from an existing OS or boot media.
Function UserExit(sType, sWhen, sDetail, bSkip)
oLogging.CreateEntry "entered UserExit ", LogTypeInfo
UserExit = Success
oLogging.CreateEntry "Entered UserExit Function ‘GetWDSServerName’", LogTypeInfo
on error resume next
oShell.run "wpeutil updatebootinfo", 1, true
sWDSServerName = oShell.RegRead("HKLM\System\CurrentControlSet\Control\PEBootServerName")
sWDSServerName = Left(sWDSServerName, InStr(sWDSServerName ,".")-1)
oLogging.CreateEntry "WDSServerName = " & sWDSServerName, LogTypeInfo
oLogging.CreateEntry "Exiting UserExit Function ‘GetWDSServerName’", LogTypeInfo
GetWDSServerName = sWDSServerName
There is actually a little known built-in feature for prompting you with a wizard screen to select the Deployment Share you want to connect to. There is actually a built in pane in the main deployment wizard that will only show up if you haven’t specified a DeployRoot value in bootstrap.ini
By default, if you don’t provide a DeployRoot value, then the wizard will pop up and allow you to manually specify the server location.
If you create a LocationServer.xml and put that on your boot image, then the wizard will display a drown down list of the Deployment Shares you have configured in the xml file. Here is a screenshot example.
You can see that I have 2 Deployment Shares to choose from in the drop down:
The tricky part that isn’t documented well is the LocationServer.xml file and what to do with it. Here is the correct format for the xml file as per the MDT documentation.
<?xml version="1.0" encoding="utf-8" ?>
Deployment San Antonio
This file needs to be added to the boot image. The easiest and most flexible way of doing this is by using an “Extrafiles” directory. The files added to this directory will be automatically added to the boot images when they are created or updated. This is the same method you would typically use for adding something like Trace32 to your 32-bit boot image.
I typically create an Extrafiles directory in the root of the DeploymentShare, so:
Then we need to add a Deploy\Control folder structure:
The LocationServer.xml needs to be in this Control folder.
Next we need to configure our boot images to use this Extrafiles directory. Go to the Windows PE x86 (or x64) Settings tab under your DeploymentShare properties:
Next configure the path for the Extrafiles directory you created.
Next we need to configure bootstrap.ini to allow the wizard to come up. Edit your bootstrap.ini:
You need to either remove or comment out your DeployRoot path that you have:
Next, update your DeploymentShare to rebuild your boot images.
Next you can launch your boot media through PXE (remember to update the WDS boot images), CD/DVD, or a USB thumb drive.
We have our Deployment Shares to choose from.
Once you select a share, you will be prompted for credentials to connect to that share.
After providing valid credentials, we see our Task Sequences to choose from.
If we had chosen the other Deployment Share, then we would have only see the following Task Sequences available to us.
That’s it! Hope you find this information useful.
Integrating Microsoft Deployment Toolkit 2010 Update 1 With System Center Configuration Manager 2007 SP2/R2 – Part 2 “Boot Images”
This will be a
quick-start guide for integrating MDT 2010 Update 1 with ConfigMgr
SP2/R2. This information is provided as-is.
This will be a
three part series covering the Setup, Boot Images and Task Sequences.
If you want
specific information on UDI (User Drive Installation) setup and components,
then I would point you to one of my previous posts on UDI.
Creating a Microsoft Deployment Toolkit based Boot Image
When MDT is integrated with ConfigMgr, a new option is available in the ConfigMgr console when creating a new Boot Image:
If we select this option, we are presented with a wizard to create a new MDT based boot image for ConfigMgr.
The first screen requires us to provide a source directory for the boot image:
I will typically recommend a path similar to below, putting all boot images in a subfolder called “boot”, and naming the folder with something descriptive.
Once you have entered in the path, you can click “Next” to proceed to the next screen.
Next, we need to provide the name of the Boot Image we are creating, and the version and any other comments if desired.
Click on “Next”:
The “Image Options” page has several selections that we can choose from.
First we can select the architecture of the boot image we want to create:
Next we can select to include ADO components (necessary for access to SQL databases) and optional fonts:
We can also select to add a pre-execution hook/media hook to enable the Deployment Wizard for the boot media. By default this will give us a Computer Name prompt for any unknown device, however this can be expanded to launch a custom front-end or other custom options.
We can also opt to include a custom background image into our boot image:
Lastly, we can choose an Extra directory to add if we want to automatically include additional files to our boot image, for example putting Trace32 into our image for easier reading of log files.
I’m going to add the Media Hook and include an Extra Files in this example:
My extra files directory simply contains Trace32:
The next screen presents you with a summary of the options you selected:
Click on “Next”:
The final screen, will show a confirmation of successful boot image creation:
Click “Finish” to exit:
Once completed, you will now have a new boot image under the Boot Images node in the ConfigMgr console:
Lets open the properties of the boot image:
Under the Data Source tab, you will see that the source points to the directory we had specifies previously:
On the “Windows PE” tab we have a few options we’ll want to set:
You will want to enable command prompt support for testing, so you can open up Trace32 and view log files. This isn’t recommended for your production boot image, however many people will leave it enabled to be able to quick troubleshoot. However, there is a security risk in having this left enabled.
You can also add drivers to your boot image in this tab, however if you have to add multiple drivers, it’s much easier to do this from the drivers node rather than selecting the drivers from here. Please keep in mind that the boot image is based upon Windows 7 and thus you will need Windows 7 drivers for the boot image, and for the appropriate architecture.
Adding from the Drivers node can be easier if you have multiple drivers, as you can select them all and then select “Add or Remove Drivers to Boot Images”
You would also see your custom background set here if you had previously set that in the wizard. Or you can change it here if ever needed.
Once you have made the appropriate changes, you will be prompted to update the boot images if required. I typically say “No” here and finish adding my drivers and any other changes I need, then add the boot image to the Distribution Points manually. Otherwise you can end up updating the boot image several times as you are making changes.
I will not cover adding the boot image to the Distribution Points in this guide as I assume you already have that knowledge. Keep in mind whenever drivers are added/removed you will have to recreate the boot image and update the DP’s.
In order to assign the boot image to a Task Sequence, we will need to go into the Task Sequence properties box.
Go to the “Advanced” tab:
Pick our custom boot image we created:
Select “Ok” again:
Manually modifying the boot image to add/remove/replace files
If you want to later add additional files to the boot image, this can be done using Imagex and the Deployment Tools Command Prompt (part of the Windows Automated Installation Toolkit aka WAIK).
Open up the command prompt:
Make a local directory to mount the image to, I generally use “C:\Mount”:
Next we will want to mount our image to that directory so we can add files to it. (DO NOT mount the WinPE.PackageID.WIM file)
You want to mount the “WinPE.Wim” using the command line:
Imagex /mountrw [path]\winpe.wim 1 [destination]
The “1” is the image index, if you need to use a different index, be sure to change that to the appropriate index.
If you just want to verify files in the image, you can use /mount instead (read-only) access.
Successfully mounted image:
Through explorer, we can see the files contained in the image now:
If we browse to windows\system32 we can see that our Trace32.exe is there now that we had included in our Extrafiles directory when we created the boot image:
Using explorer, you can add/remove any files you need to the c:\mount directory. Once completed, close explorer and return to your Deployment Tools command prompt.
To just unmount an image and discard any changes, use:
imagex /unmount [mountdir]
Example: imagex /unmount c:\mount
To save your changes, you need to commit the changes to the image and unmount the image. This can be done together using the following command:
imagex /commit /unmount [path]
Example: imagex /commit /unmount c:\mount
Once you have successfully unmounted the image, then be sure to update your Distribution Points to reflect the new changes you have made.
Michael Murgolo has a nice post over on The Deployment Guys Blog about using command shell (CMD) scripts within MDT.
“OK… I’ll admit it, I like to write Command Shell (CMD) scripts when I can. For me it’s like putting on an old broken-in pair of sneakers… so comfortable and familiar. Unfortunately, using them in MDT task sequences can be challenging. I this post I’ll demonstrate some techniques and helper scripts that can bring Command Shell scripts into the MDT era. There are four main tasks that I’ll address today: calling other scripts and executables, getting Task Sequence Variables, setting Task Sequence Variables, and logging.”
Read more here.
I was helping someone configure some shares the other day for Migdata and Logs. I dug this up from the old BDD 2.5 documentation, it’s a good reference point for creating access to shares in order for computers to put files there.
After you have configured the SMS client access accounts, you need to configure the appropriate shared folder permissions. Ensure that unauthorized users are unable to access user state migration information and the deployment logs. Only the workstation creating the user state migration information and the deployment logs should have access to these folders.
To configure the shared folder permissions for each folder listed in Table 24, perform the following steps for each folder:
1. Start Windows Explorer and navigate to SharedFolder (where SharedFolder is one of the shared folders listed in Table 24).
2. Right-click SharedFolder (where SharedFolder is one of the shared folders listed in Table 24), and then click Properties.
3. On the Security tab, click Advanced.
4. On the Permissions tab, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects check box.
5. When the Remove when prompted to either Copy or Remove the permission entries that were previously applied from the parent appears, click Remove.
6. On the Permissions tab, click Add.
7. In the Enter the object name to select text box, type Domain Computers, and then click OK.
This action allows domain computers to create subfolders.
8. On the Permission Entry for Text dialog box, in the Apply onto list, select This folder only.
9. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Create Folders/Append Data permission, and then click OK.
10. Repeat steps 6– 9 substituting Domain Users for Domain Computers.
11. On the Permissions tab, click Add.
12. In the Enter the object name to select text box, type CREATOR OWNER, and then click OK.
This action allows domain computers and domain users to access the subfolders they create.
13. On the Permission Entry for Text dialog box, in the Apply onto list, select Subfolders and files only.
14. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Full Control permission, and then click OK.
15. Repeat steps 11–13 for each group that you want to grant administrative privileges.
The permissions you set in these steps allow a workstation to connect to the appropriate share and create a new folder in which to store user state information or logs, respectively. The folder permissions prevent other users or computers from accessing the data stored in the folder.
Note The default permissions on the SMS distribution point shares should provide the appropriate resource access by default.
If you have ever wanted to hide that black cscript window in your custom wizard or pre-execution hook, read more here. Nice post showing you how to get rid of the window.
There is a great article on Microsoft written by Jeremy Chapman. This is great read.
Here is a summary of the contents:
Deploying Windows 7 from A to Z
Migrating User Files and Settings from Windows XP to Windows 7
Application Management and Preparing for a Windows 7 Deployment
Choosing an Image Strategy and Building Windows 7 System Images
Quick History Lesson for System Imaging
Building Your Image
Getting to Thin Images
Automating the Migration from Windows XP to Windows 7 End-to-End
Automating the End-to-End Migration Process
Tricks for More Automation