Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X
Aside

Back to Basics – CustomSettings.ini – Explained

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.

Read the full post here.

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.

Aside

Back to Basics – DomainOUlist.xml or not…

Mikael Nystrom has a good "back to basics" post up.

Read his post here.

Aside

Generate Computernames in MDT 2010 based on prefix and a sequencenumber

Johan has put up a new post over on his blog.

Be sure to read his original post here.

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

….

Aside

Microsoft Deployment Toolkit (MDT)–User Exit Scripts

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

End Function

 

Function SetTaskSequence(vMemory)

 

  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

  Else

    SetTaskSequence = "Vista_X86"

    oLogging.CreateEntry "UserExit – Available RAM: " & _

      vMemory & ". Selecting Vista_X86 TS.", LogTypeInfo

  End If

End Function

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

[Settings]

Priority=Default

 

[Default]

OSInstall=Y

TaskSequenceID=#SetTaskSequence("%MEMORY%")#

UserExit=Z-RAMTest.vbs

 

UserDataLocation=NONE

SkipAppsOnUpgrade=NO

SkipCapture=YES

SkipAdminPassword=NO

SkipProductKey=YES

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.

This example is from Johan Arwidmark’s blog.

Bootstrap.ini
[Default]
UserExit=UserExit.vbs
DeployRoot=\\#GetWDSServerName#\Distribution$

UserExit.vbs
Function UserExit(sType, sWhen, sDetail, bSkip)
                oLogging.CreateEntry "entered UserExit ", LogTypeInfo
                UserExit = Success
End Function

Function GetWDSServerName
                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
End Function

Aside

Microsoft Deployment Toolkit 2010 Lite Touch Providing a Wizard To Select The Deployment Share

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. 

image

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.

image

You can see that I have 2 Deployment Shares to choose from in the drop down:

image

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" ?>

<servers>

    <QueryDefault></QueryDefault>

    <server>

        <serverid>1</serverid>

        <friendlyname>

          Deployment San Antonio

        </friendlyname>

        <UNCPath>\\TX-Server\DeploymentShare$</UNCPath>

    </server>
        <server>

        <serverid>2</serverid>

        <friendlyname>

          Deployment Madison

        </friendlyname>

        <UNCPath>\\WI-Server\DeploymentShare$</UNCPath>

    </server>

</servers>

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:

DeploymentShare\Extrafiles

Then we need to add a Deploy\Control folder structure:

DeploymentShare\Extrafiles\Deploy\Control

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:

image

Next configure the path for the Extrafiles directory you created.

image

Next we need to configure bootstrap.ini to allow the wizard to come up.  Edit your bootstrap.ini:

image

You need to either remove or comment out your DeployRoot path that you have:

image

Next, update your DeploymentShare to rebuild your boot images. 

image

Next you can launch your boot media through PXE (remember to update the WDS boot images), CD/DVD, or a USB thumb drive.

image

We have our Deployment Shares to choose from. 

image

Once you select a share, you will be prompted for credentials to connect to that share.

image

After providing valid credentials, we see our Task Sequences to choose from. 

image

If we had chosen the other Deployment Share, then we would have only see the following Task Sequences available to us.

image

That’s it! Hope you find this information useful.

Aside

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.

Part
1: Setup

Part
2: Boot Images

Part
3: 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:

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:

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. 

image

Once you have entered in the path, you can click “Next” to proceed to the next screen.

image

Next, we need to provide the name of the Boot Image we are creating, and the version and any other comments if desired.

image

Click on “Next”:

image

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:

image

Next we can select to include ADO components (necessary for access to SQL databases) and optional fonts:

image

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.

image

We can also opt to include a custom background image into our boot image:

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.

image

I’m going to add the Media Hook and include an Extra Files in this example:

image

My extra files directory simply contains Trace32:

image

The next screen presents you with a summary of the options you selected:

image

Click on “Next”:

image

The final screen, will show a confirmation of successful boot image creation:

image

Click “Finish” to exit:

image

Once completed, you will now have a new boot image under the Boot Images node in the ConfigMgr console:

image

Lets open the properties of the boot image:

image

Under the Data Source tab, you will see that the source points to the directory we had specifies previously:

image

On the “Windows PE” tab we have a few options we’ll want to set:

image

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.

image

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.

image 

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”

image

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.

image

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.

image

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.

image

Go to the “Advanced” tab:

image

Select “Browse”:

image

Pick our custom boot image we created:

image

Select “Ok”:

image

Select “Ok” again:

image

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).

image

Open up the command prompt:

image

Make a local directory to mount the image to, I generally use “C:\Mount”:

image

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)

image

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:

image

Through explorer, we can see the files contained in the image now:

image

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:

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.

image

To just unmount an image and discard any changes, use:

imagex /unmount [mountdir]

Example: imagex /unmount c:\mount

image

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

image

Once you have successfully unmounted the image, then be sure to update your Distribution Points to reflect the new changes you have made.

image

Aside

Using Command Shell Scripts with Microsoft Deployment Toolkit (MDT)

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.

Aside

Configuring Shared Folder Permissions

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.

Aside

Hiding Cscript Window in Custom Boot Wizards

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.

Aside

Deploying Windows 7 from A to Z

There is a great article on Microsoft written by Jeremy Chapman.  This is great read.

Here is a summary of the contents:

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

Application Compatibility

Application Packaging

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

 

Download Here:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dfafb346-97dd-4fca-947e-3d9149834da6