The Deployment Guys : ConfigMgr

Approving Windows Updates in an MDT 2010 Standalone Environment from a ConfigMgr Software Update Point

DeploymentGuys — Thu, 22 Oct 2009 01:06:00 GMT

You’ve no doubt read some of the benefits around using the Software Update Point features of ConfigMgr. However, if you are already using MDT standalone as an Image Engineering environment – there is sometimes a duplication in having to manage software...(read more)

Location Deployment Wizard for ConfigMgr 2007

DeploymentGuys — Mon, 17 Aug 2009 19:37:00 GMT

When working on deployment projects, there is often a requirement for a workstation to be customised on a location by location basis. Common workstation customisations which are applied in this manner include:

Localisation settings (locales, keyboard settings, time zones, Windows (Windows Vista/Windows 7) language injection
Domain membership/organisational unit join information
Location based applications to be installed
Site or location based administrator groups or accounts that need to added to the local administrators group

The Microsoft Deployment Toolkit (MDT) and its accompanying database offers features to tailor a workstation based on its location during a deployment. The MDT Database allows locations to be defined and a set of location specific settings can be stored against each entry. When a workstation is been deployed, an MDT database lookup determines its location and collects the relevant build settings for that location. The location is determined by carrying out a lookup of the default gateway on the target workstations assigned NIC against default gateways assigned to locations in the MDT Database. To learn more about the Microsoft Deployment Toolkit and the database supplied with MDT see http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

During a mass deployment it is quite common for workstations to be built in central locations and then to be shipped to other sites for use. In these circumstances, the MDT Database location functionality may not be as useful as any database location lookups will return settings for the site at which the workstations are being built and not the site to which the workstation will be eventually shipped.

A solution to this is to use a location deployment wizard when using the MDT Database along with System Center Configuration Management (ConfigMgr) 2007 Operating System deployments (OSD) in zero touch scenarios. A location deployment wizard is an HTA that is displayed to the user/build engineer at the start of the workstation deployment process to display the location in which they are currently situated. If the location is the site at which the workstation will be based they can click next and the deployment will continue applying all the deployment settings for that site. However, the wizard allows an “override” for the detected location and allow the user/build engineer to select another location from the MDT Database. Overriding the detected location will apply all of the selected location deployment settings from the MDT Database to the workstation despite it not being at that location. This solution allows workstations to be built in a central location whilst being fully customised for their destination locations.

The location deployment wizard is an HTA that is stored in a customised ConfigMgr OSD boot image and is executed before a ConfigMgr task sequence starts. The HTA uses Operating System Media Pre-Execution Hooks (http://technet.microsoft.com/en-us/library/bb694075.aspx) to place itself before the task sequence window. The location deployment wizard allows inputs that are stored as a ConfigMgr task sequence variable. The location variable can then be used by a ConfigMgr deployment task sequence to recover settings from the MDT Database throughout the deployment (During ZTIGather phase).

Pre-Requisites

The following pre-requirements should be configured in your deployment environment:

System Center Configuration Management 2007 (RTM, SP1, R2 or SP2 beta) environment configured for OSD deployments.
Microsoft Deployment Toolkit 2008 / MDT 2010 Workbench + Database hosted on Microsoft SQL 2005 or 2008 (Express / Standard / Enterprise)
ConfigMgr 2007 console with integrated MDT console functions
The MS SQL Database hosting the MDT Database should be configured to allow NamedPipes
A share should be setup on the MDT Database server for authentication when using NamedPipes from a WinPE environment by using the SQLShare$ method.
ConfigMgr “Network Access Account” should have db_datareader access to the MDT SQL Database
Another AD account should be created which is assigned db_datareader access to the MDT Database. Note This account will be stored in a plain text file in the ConfigMgr OSD Boot image. This account should be limited to just db_datareader access on the MDT SQL Server and denied all other rights on the domain

Location Deployment Wizard Setup Steps

Download the location deployment wizard attached to this post and extract the files to a temporary location on the computer/server which has a ConfigMgr 2007 Console with integrated MDT console functions. There are 4 components which need to be configured in your environment for this solution to operate:

Configure the Bootstap.ini file
Create a custom boot image
Configure Location settings in the MDT Database
Configure CustomSettings.ini file

1. Configure the Bootstrap.ini file

The Bootstrap.ini file contains the settings required by the Location Deployment Wizard to make the initial connection to the MDT Database. These settings need to be configured for your environment:

Edit the Bootstrap.ini file in the Location Deployment Wizard\LocationDeploymentWizard folder. This file is used by the location deployment wizard HTA to connect to the MDT Database for the first time:
- Replace <USERNAME> with the AD account created for reading the MDT Database in the pre-requirements e.g. CONTOSO\MDTDBReader
- Replace <PASSWORD> with the password of the account entered above
- Replace <SQL SHARE FOR AUTHENTICATION> with the name of a shared folder on the MDT Database server e.g. \\MDT01.contoso.com\SQLShare$
- Replace <MDT DATABASE SEVER> with the fully qualified domain name of the MDT Database server e.g. mdt01.contoso.com
- Replace <MDT DATABASE NAME> should be replaced with the instance name of the MDT Database in SQL e.g. MDTDB

2. Create a custom boot image

During OSD deployments a WinPE boot image provides the environment for deploying a workstation. ConfigMgr 2007 provides default boot images in the Operating System Deployment -> Boot Images node in the console. A new custom boot image needs to be generated containing the location deployment wizard HTA and its supporting files – this will execute when the boot image first loads on a workstation:

Create a new custom boot image in the ConfigMgr console using the “Create Boot Image Using Microsoft Deployment” wizard:

Follow the wizard, selecting the default options. On the Image Options page set the Extra Folder to Add as the Location Deployment Wizard folder which is found in the root of the files extracted earlier
Complete the wizard selecting the default options. ConfigMgr/MDT will now create a new customised boot image with the location deployment wizard included.
Assign the boot image to the OSD deployment task sequence that you wish to use the location deployment wizard with:

3. Configure location settings in the MDT Database

Locations and their associated settings need to be configured in the MDT SQL Database, these are typically configured through the interface in the MDT workbench. In the MDT workbench go to the Database >> Locations Node. Here you can add as many different locations as are required for your environment.

For a location to be available to the location deployment wizard it must be assigned at least one default gateway. This can be found in a locations properties on the Identity tab.
If no default gateways for a site are initially known then assign 0.0.0.0 as the default gateway for that location. Although this site will never be automatically detected by the location build wizard, it can be manually selected.
In the Details tab of a locations properties use the SERVERA property to populate sites or country e.g. UK. This is used by the location deployment wizard to break down the locations so there is not just one long list:
Populate any other deployment site settings as required for your deployment including locales, time zones, keyboard settings, UI Language, location specific apps and location specific admins.

4. Configure CustomSettings.ini file

The CustomSettings.ini (http://technet.microsoft.com/en-us/library/bb977690.aspx) is a rules file which is used to automate deployments and setup how to query settings from the MDT Database. The location deployment wizard has its own CustomSettings.ini which is used during Gather phases in a ConfigMgr task sequence to retrieve location settings from the MDT Database. The CustomSettings.ini file included in the supplied location deployment wizard must be customised to your environment:

Edit the CustomSettings.ini file located in the root of the extracted files. The customsettings.ini file is a rules file is used by the MDT script ZTIGather.wsf to gather all of the location based settings from an MDT database:
- All instances of <FQDN MDT DATABASE> should be replaced with the fully qualified domain name of your MDT Database server e.g. mdt01.contoso.com
- All instances of <MDT DATABASE NAME> should be replaced with your MDT Database name in SQL e.g. MDTDB
- All instances of <AUTHENTICATION SHARENAME> should be replaced by your shared folder name on the MDT Database server e.g. SQLShare$

Once the customsettings.ini file has been updated it should be wrapped up into a ConfigMgr package (typically this is the MDT Settings package) and sent to all distribution points on your network which will be used for OSD. This rules package must be used by all Gather phases in your MDT integrated deployment task sequence to gather location settings from the MDT Database.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Mark Hooks and Richard Smith, consultants with Microsoft Services – U.K.

Persisting ConfigMgr Packages during a Task Sequence

DeploymentGuys — Fri, 17 Jul 2009 17:30:00 GMT

The MDT Task Sequences for System Center Configuration Manager 2007 use a clever technique to download and persist the MDT Files package during each phase of the Task Sequence. The Use Toolkit Package step uses the ZTISCCM.wsf script to copy the contents of the package to a WDPackage subfolder of the _SMSTaskSequence folder. The Task Sequencer maintains this folder (the path of which is held in the _SMSTSMDataPath variable) for holding the logs and downloaded package contents. So the WDPackage folder will continue to exist until the next reboot. MDT places the path to the WDPackage folder in the DeployRoot variable.

Doing this prevents repeated download of the MDT Files every time the execution of an MDT script is needed. My customer wanted to be able to used the same technique for their custom scripts. They maintain a package of custom scripts so that they are not mixed in with the MDT scripts. This will allow them to update/replace the MDT Files package as needed without having to worry about their custom scripts.

One way of doing this would be to simply create a Run Command Line step (after the Use Toolkit Package step) that simply does an xcopy of the files/folder in the package to either DeployRoot or ScriptRoot or a subfolder of those paths. You can then call your scripts relative to the DeployRoot or ScriptRoot variable.

I wanted to provide my customer with maximum flexibility for this so I created a custom script called ZTI-PersistSccmPackage.wsf. This script should be copied to the root of the package along with a copy of the MDT script ZTIUtility.vbs. The command has the following syntax:

cscript ZTI-PersistSccmPackage.wsf /pathvar:<path variable name> /xcopy:"<additional xcopy switches>"

The /pathvar switch sets the name of the variable the can be used to reference the path to the persisted files. If you specify a variable name that is either DeployRoot, ScriptRoot, or ToolRoot, the script will copy the contents of the package to the corresponding location in the WDPackage folder created by the Use Toolkit Package step. If you specify any other variable name, the script will create a randomly named folder in the _SMSTSMDataPath location, copy the contents of the package to that folder, and set a Task Sequence variable pointing to that folder path with the variable name specified with the /pathvar switch. For example, if you had a package of custom scripts you wanted to persist in their own folder, you would could run the script like this:

cscript ZTI-PersistSccmPackage.wsf /pathvar:CustomScriptRoot

You could then reference your scripts using the CustomScriptRoot variable. For example, if the package contained a script called MyScript.wsf you could run it from a Run Command Line step using the following syntax without having to add the package to the step:

cscript "%CustomScriptRoot%\MyScript.wsf"

The optional /xcopy switch is used to specify additional switches for the xcopy command. By default, the script uses xcopy with the following switches: /s /e /h /y /c. For example, if you wanted to add the /d switch to filter the copy by date or add the /exclude switch to exclude files from the copy, you would specify those using the /xcopy switch.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Single WIM Deployment of Windows XP Professional and Tablet PC Edition (and Other Operating Systems)

DeploymentGuys — Mon, 13 Jul 2009 22:55:00 GMT

Update 2009-07-17: Corrected some errors in the application settings in the Extracting the Sysprep Files section that occured because I did not make all necessary changes after doing a copy/paste.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

In my post on August 3 2009, I promised in an upcoming post I would show you how to create a single WIM file that contains several XP images with a single MDT Lite Touch Task Sequence (rerun four times). Additionally, I said that I would show you how you can deploy these images from that WIM file onto the correct target hardware using either a single MDT Lite Touch Task Sequence or a single MDT Zero Touch Task Sequence in SCCM. Well, that day is finally here!

Image Build: MDT Setup

For building and capturing images, I prefer to use the MDT Lite Touch process over Systems Center Configuration Manager 2007. You have more control over the process, you can have tasks with a visible UI for testing and troubleshooting, and since the Task Sequencer runs as the built-in Administrator account you can configure settings that can get propagated to Default User settings. So the process I'm about to describe will only use MDT Lite Touch for building and capturing images into the single WIM file. Also, everything I describe in the post was done with MDT 2008 Update 1. Once MDT 2010 has released or is close to releasing, I’ll blog what, if any, changes are necessary.

As I described in the August 3rd post, the "Single Image" process for XP Pro/Tablet PC Edition will not be supported for Service Pack 3. Because of this, I moved my current customer's XP deployment process back to separate images. Since they have to support hardware that requires both types of XP ACPI HALs, this deployment process required four XP Images:

Windows XP Professional with ACPI Uniprocessor HAL (APIC HAL)
Windows XP Tablet PC Edition 2005 with ACPI Uniprocessor HAL (APIC HAL)
Windows XP Professional with Advanced Configuration and Power Interface (ACPI) PC HAL (PIC HAL)
Windows XP Tablet PC Edition 2005 with Advanced Configuration and Power Interface (ACPI) PC HAL (PIC HAL)

If you only require a subset of these images (perhaps you don’t need to support Tablet PCs or PIC hardware, etc.), you can modify the steps that follow accordingly.

Using traditional sector-based imaging tool supporting four images would require four times the disk storage and four times the WAN traffic to replicate those images around. However, using file-based WIM images that can take advantage of "single instance storage" that allows you to store all four of these images in a single WIM file that will only be slightly larger than any single image.

All of the above images can be generated from a single MDT Task Sequence by simply running it four times on either the correct computer hardware or by using the correct XP Product Key. Unfortunately, if you try this with MDT 2008 “out of the box”, the process will fail during the attempt to capture the second image. This is because the MDT 2008 script that does the image capture, ZTIBackup.wsf, is hard-coded to use an image name of the format <TaskSequenceID><drive letter>Drive (e.g. XPPROSP2CDrive). Since an image name must be unique within a WIM file, when ZTIBackup.wsf tries to append the next image with the same image name, it fails. Therefore, to capture four image into on WIM with MDT 2008 as is you would need four identical Task Sequences. And you would need to remember to specify the same WIM file in the deployment wizard when each Task Sequence.

So to work around this limitation, I created a custom version of ZTIBackup.wsf (with the exciting name of ZTIBackupCustom.wsf). With this version you can specify the image name prefix (the part before <drive letter>Drive) using either a command line switch, /nameprefix, or a custom property, ImageNamePrefix. I used this script instead of ZTIBackup.wsf in the Create WIM step in the Task Sequence. Using only this change worked well but imposed the limitation the each run of the Task Sequence had to complete before starting the next. Also, all the runs had to be completed in the proper order so that the image index in the WIM would come out the same each time.

To get around this limitation, I changed the BackupFile MDT property (which holds the WIM file name) for each run of the Task Sequence so that each run created a different WIM file. I then created a script that uses imagex /export to combine all the WIM files in to a single WIM. This allows you to run the build in any order (even all at once) and re-run those that fail if needed.

OS Installation Media

You will need to assemble and import the XP SP2-integrated media as I described in my post on August 3 2009.

CustomSettings.ini

To control what edition of XP gets install, what image name prefix gets used, what BackupFile name is used, etc. I used MAC Address sections in CustomSettings.ini. Doing it this way requires four computers with different MAC Addresses. (I used Hyper-V and Virtual Server virtual machine as my build machines so that I didn’t need to be bothered with CD or PXE booting physical machines, but this process will work either way. I used Hyper-V to build the APIC HAL images and needed Virtual Server to build the PIC HAL images.) Here is what the CustomSettings.ini looks like:

[Settings]
Priority=Default, MACAddress, Finish
Properties=MyCustomProperty, CapturedImageIndex, ImageNamePrefix, CompletionFile, BackupFile

[Default]
OSInstall=Y

OrgName=Contoso
_SMSTSORGNAME=Contoso
SLShare=%DeployRoot%\Logs

SkipAppsOnUpgrade=YES
SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
SkipComputerName=YES
    ;ComputerName set in MACAddress sections
SkipDomainMembership=Yes
    JoinWorkgroup=Workgroup
    ;JoinDomain
    ;DomainAdmin
    ;DomainAdminDomain
    ;DomainAdminPassword
SkipUserData=yes
    UserDataLocation=NETWORK
    ;UDDir
    ;UDShare
SkipComputerBackup=Yes
SkipBuild=YES
    ;BuildID set in MACAddress sections
SkipTaskSequence=YES
    ;TaskSquenceID set in MACAddress sections
SkipProductKey=YES
    ;ProductKey
SkipPackageDisplay=YES
    ;LanguagePacks
SkipLocaleSelection=Yes
    UserLocale=en-us
    InputLocale=en-us
    KeyboardLocale=en-us
SkipTimeZone=Yes
    TimeZone=35
    TimeZoneName=Eastern Standard Time
SkipApplications=YES
    ;Applications
SkipAdminPassword=YES
    AdminPassword=*
SkipCapture=YES
    DoCapture=YES
    ComputerBackupLocation=%DeployRoot%\Captures
SkipBitLocker=YES
    ;BDEDriveLetter
    ;BDEDriveSize
    ;BDEInstall
    ;TPMOwnerPassword
SkipSummary=YES
SkipFinalSummary=NO

[00:15:5D:11:AF:FF]
; Vista x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
CapturedImageIndex=1
ComputerName=vx86sp1%HALNAME%
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FE]
; XP Pro APIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=1
ComputerName=xppro%HALNAME%
ProductKey=11111-22222-33333-44444-55555
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FD]
; XP Tablet APIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=2
ComputerName=xptab%HALNAME%
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
WsusServer=http://MDTSERVER

[00:03:FF:64:17:41]
; XP Pro PIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=3
ComputerName=xppro%HALNAME%
ProductKey=11111-22222-33333-44444-55555
WsusServer=http://MDTSERVER

[00:03:FF:64:17:42]
; XP Tablet PIC HAL
BuildID=XPSP3
TaskSquenceID=XPSP3
CapturedImageIndex=4
ComputerName=xptab%HALNAME%
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
WsusServer=http://MDTSERVER

[Finish]
BackupFile=%TASKSEQUENCEID%_%CapturedImageIndex%.wim
ImageNamePrefix=%TASKSEQUENCEID%.%CapturedImageIndex%.%TASKSEQUENCEVERSION%_
CompletionFile=%TASKSEQUENCEID%.%CapturedImageIndex%.txt

The edition of XP (Professional or Tablet PC Edition 2005) that gets install is controlled by using the correct Pro or Tablet Product Key. (In this sample 11111-22222-33333-44444-55555 represents the XP Pro product key and AAAAA-BBBBB-CCCCC-DDDDD-EEEEE represents the XP Tablet PC Edition product key.) The BackupFile name is constructed from the TaskSquenceID and the custom property CapturedImageIndex. So for example the BackupFile name for the XP Pro APIC HAL image would be XPSP3_1.wim. The prefix for the image name within the WIM the TaskSquenceID, the custom property CapturedImageIndex, and the TASKSEQUENCEVERSION. For the the XP Pro APIC HAL image, the ImageNamePrefix would be something like XPSP3.1.05.

Image Build: Task Sequence Details

Installing XP Service Pack 3

As I stated in my post on August 3 2009, the only way to create a supported installation of Windows XP Tablet PC Edition 2005 Service Pack 3 is to first install Tablet PC Edition from Service Pack 2 media and then install the Service Pack 3 Update. So to be consistent, the task sequence creates all the XP images by first installing from SP 2 media and installing the SP 3 Update as an Application in the Custom Tasks group.

I did this by download the Windows XP Service Pack 3 Update from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=5B33B5A8-5E76-401F-BE08-1E1555D4F3D4&displaylang=en. I extracted the contents of the update to a temporary folder with the following command:

WindowsXP-KB936929-SP3-x86-ENU.exe /x:<temporary folder path>

Then I used the temporary folder to import the extracted Service Pack 3 Update as an Application in MDT with the following settings:

Folder name: Microsoft Windows XP Service Pack 3 Update
Name: Windows XP Service Pack 3 Update
Version: 1.0
Publisher: Microsoft
Language: en-US
Source: .\Applications\Microsoft Windows XP Service Pack 3 Update
CommandLine: Update.exe /passive /norestart /n
WorkingDirectory: .\Applications\Microsoft Windows XP Service Pack 3 Update\i386\update

Updating the \Windows\Source folder

MDT copies the XP installation source files into the %windir%\Source folder so that it is available if an optional component needs to be installed later. Unfortunately, since you are installing from SP 2 media and installing the SP 3 Update later the %windir%\Source folder will be at SP2 but the installed OS will be at SP3. To fix this you have to add step to the Task Sequence to update the %windir%\Source folder with the SP3-level installation source files.

To do this, create a temporary folder. Copy ZTIUtility.wsf from the MDT Scripts folder and the custom scripts LTI-ReplaceWindowsSource.wsf and LTI-CopySysprepFiles.wsf (in the ZIP attachment below) into this folder. Create a subfolder of the temporary folder called Source. Copy the contents of the SP3-level integrated media or slipstreamed version of the XP Pro installation CD files into the Source folder (copy all files/folders from the CD especially the Support folder, not just the i386 folder). The folder should look similar to this:

Import this folder as an Application with source files with the following settings:

Folder name: Windows XP Professional Service Pack 3 Integreted Media
Name: Windows XP Professional Service Pack 3 Integreted Media
Version: 1.0
Publisher: Microsoft
Language: en-US
Source: .\Applications\Windows XP Professional Service Pack 3 Integreted Media
CommandLine: cscript.exe LTI-ReplaceWindowsSource.wsf
WorkingDirectory: .\Applications\Windows XP Professional Service Pack 3 Integreted Media

Add this as an Install Application step in the Custom Tasks group.

If you are going to create your media for this step by slipstreaming SP3 into an SP2 installation source, this is what I recommend that you do. Download the Windows XP Service Pack 3 - ISO-9660 CD Image File from here and burn it to a CD using software that can burn ISO images to CD. (I like using ImgBurn for this but there are many others you can use.)

Copy the SP2 installation source that you imported following my instructions in the August 3, 2009 post to a temporary folder. Delete the Dotnetfx, Support, and Valueadd folders from the temporary folder. Replace them with the ones on the XP SP3 CD you just created. Then use the SP3 installer (WindowsXP-KB936929-SP3-x86-ENU.exe) on the root of the CD to integrate SP3 into the temporary folder using the following command:

WindowsXP-KB936929-SP3-x86-ENU.exe /integrate:"<temporary folder path>"

Copy the resulting installation files into the Source folder in the above instructions. Then create a Install Application step in the Custom Tasks group to “install” this as I described above.

Extracting the Sysprep Files

MDT copies the Sysprep files from the operating system folder in the Distribution folder. Because of this, the Sysprep files copied will be the SP2 versions instead of the SP 3 versions. Similar to the above step, we need to make sure the SP3 versions get copied instead.

Create another Application in MDT as Applications without source files or elsewhere on the network with the following settings:

Name: Windows XP Professional Service Pack 3 Sysprep Files
Version: 1.0
Publisher: Microsoft
Language: en-US
CommandLine: cscript.exe LTI-CopySysprepFiles.wsf
WorkingDirectory: %DeployRoot%\Applications\Windows XP Professional Service Pack 3 Integreted Media

Then create a Install Application step in the Custom Tasks group to “install” this.

Changing the Create WIM Step

You still need to copy ZTIBackupCustom.wsf from the attached Zip file, place it in the MDT Scripts folder, and change the command line of the Create WIM step to use it instead of ZTIBackup.wsf.

Merging the WIM files

After completing all four runs of the Task Sequence, there should be four WIM files in the \Distribution\Captures folder: XPSP3_1.wim, XPSP3_2.wim, XPSP3_3.wim, and XPSP4_1.wim. To merge them all into a new single WIM file (XPSP3.wim), I created the following CMD script (MergeXPImages.cmd) to do this. It uses a small VBScript as well (both included in the Zip attachement). This script is run on the MDT Server. Be sure to change the set CAPTURES=D:\Distribution\Captures line to point to your Captures folder path.

@echo off
setlocal

call "%ProgramFiles%\Windows AIK\Tools\PETools\pesetenv.cmd"
set CAPTURES=D:\Distribution\Captures

:: Get the Last Modified date for the previous merged WIM if it exists
:: and create an environment variable
If exist "%CAPTURES%\XPSP3.wim" (
    for /f "tokens=*" %%i in ('cscript //nologo GetFileDateInfo.vbs "%CAPTURES%\XPSP3.wim"') do set %%i
)

:: Rename previous merged WIM so as not to overwrite or merge to the previous WIM
If exist "%CAPTURES%\XPSP3.wim" rename "%CAPTURES%\XPSP3.wim" "XPSP3_%FileLastModified%.wim"

:: Merge the source WIMs into a single destination WIM
call :MERGEIMAGE "%CAPTURES%\XPSP3_1.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_2.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_3.wim" "%CAPTURES%\XPSP3.wim"
call :MERGEIMAGE "%CAPTURES%\XPSP3_4.wim" "%CAPTURES%\XPSP3.wim"

goto :EOF

:MERGEIMAGE

    for /f "delims=<> tokens=2,3*" %%i in ('imagex /info "%~1" 1') do set %%i=%%j
    imagex /export "%~1" 1 "%~2" %NAME%
    imagex /info "%~2"

goto :EOF

Deploying the XP Multi-image WIM

So now that you have this multi-mage WIM file, how do you make sure that the correct image gets applied in the deployment Task Sequence? The steps are different depending on whether you are deploying with MDT Lite Touch Installation or with System Center Configuration Manager 2007 with MDT Integration. You must use MDT Integration and an MDT Task sequence in ConfigMgr so that the Gather step will run.

In both cases you will need to make the changes to CustomSettings.ini and use ZTI-DetectHardwareExit.vbs as shown in the Edit CustomSettings.ini for Detecting Tablet PC Hardware section of my post on August 3 2009. Using this multi-image WIM requires that the IsTablet variable is set correctly to True or False.

System Center Configuration Manager 2007

If you are deploying with System Center Configuration Manager, the setup is very straight forward. Import the WIM files as an Operating System Image Package. In your Task Sequence you will now need to have four Apply Operating System Image steps instead of one. Give each a unique step name like Apply OS – XP Pro APIC HAL to avoid confusion as to why there are four. For all of them you will check Apply operating system from captured image and select the Image package you just created. Then for each one you will select a different Image number (1, 2, 3, or 4). Finally you will set conditions on the Options tab on each Apply Operating System Image step. For example, the conditions for the XP Pro APIC HAL image would look like this:

The table below shows the various settings for all the Apply Operating System Image steps.

Step Name	Image #	Conditions
Apply OS - XP Pro ACPIAPIC HAL	1	HALNAME equals ACPIAPIC and IsTablet equals FALSE
Apply OS - XP Tablet ACPIAPIC HAL	2	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Apply OS - XP Pro ACPIPIC HAL	3	HALNAME equals ACPIPIC and IsTablet equals FALSE
Apply OS - XP Tablet ACPIPIC HAL	4	HALNAME equals ACPIPIC and IsTablet equals TRUE

Similarly, you should have two Apply Windows Settings steps, one with the XP Professional Product Key and one with the XP Tablet PC Edition Product Key:

Step Name	Product key	Conditions
Apply Windows Settings – XP Pro	(Windows XP Professional Volume License Key)	IsTablet equals FALSE
Apply Windows Settings - XP Tablet	(Windows XP Tablet PC Edition 2005 Volume License Key)	IsTablet equals TRUE

MDT 2008 Update 1

If you are using MDT Lite Touch Installation, things get a little trickier. First import the WIM as a Operating System into MDT. After you do you will see four entries in Operating Systems like XPSP3.1.05_CDrive in "Windows XP SP3\XPSP3.wim" if you used a folder name of Windows XP SP3 during import.

When you create your deployment Task Sequence select the one that starts with XPSP3.1 as the operating system to install. This will be the XP Pro APIC HAL image which should be the one that will be installed most often. You can only have the one Install Operating System step in an MDT Task sequence.

When you import a WIM as an Operating System in the Deployment Workbench it creates one or more entries in \Distribution\Control\OperatingSystems.xml. It will create one entry for each image in the WIM files. Below is an example of the entries in OperatingSystems.xml for my multi-image XP WIM file

<os guid="{e22d5b4a-1d2f-4c73-860a-ced219bb8c09}">
<Name>XPSP3.1.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>1</ImageIndex>
<ImageName>XPSP3.1.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpiapic_up</HAL>
<Size>3003</Size>
</os>
<os guid="{1c47ea5f-73cd-44f2-a0a6-37583ac9b774}">
<Name>XPSP3.2.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>2</ImageIndex>
<ImageName>XPSP3.2.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpiapic_up</HAL>
<Size>3236</Size>
</os>
<os guid="{61c15f32-1f9f-4c64-806a-202eaccac425}">
<Name>XPSP3.3.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>3</ImageIndex>
<ImageName>XPSP3.3.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpipic_up</HAL>
<Size>3051</Size>
</os>
<os guid="{a8f8689f-ed34-4595-a2f8-02ef98832979}">
<Name>XPSP3.4.05_CDrive in "Windows XP SP3\XPSP3.wim"</Name>
<Description>
</Description>
<Platform>x86</Platform>
<Build>5.1.2600.5512</Build>
<Type>Windows XP</Type>
<Source>.\Operating Systems\Windows XP SP3</Source>
<IncludesSetup>False</IncludesSetup>
<SMSImage>False</SMSImage>
<ImageFile>.\Operating Systems\Windows XP SP3\XPSP3.wim</ImageFile>
<ImageIndex>4</ImageIndex>
<ImageName>XPSP3.4.05_CDrive</ImageName>
<Flags>
</Flags>
<HAL>acpipic_up</HAL>
<Size>3284</Size>
</os>

You will notice that each entry is assigned a unique GUID. This is what MDT uses to track what OS to install when you select an OS in the Install Operating System step. Unfortunately, MDT takes the GUID from the entry selected in the Install Operating System step and sets a global Task Sequence variable called OSGUID with the value. This means that to change what OS gets installed within the Task Sequence, you have to override the OSGUID value with the GUID for the OS you want to install. You also need to override the variable IMAGEINDEX as well. To do this you need to create a series of Set Task Sequence Variable steps to override both variables using conditions similar to those on the ConfigMgr steps. Below is a table showing the Set Task Sequence Variable steps for my sample above that should immediately precede the Install Operating System step and their conditions. There should be no conditions on the Install Operating System step.

Step Name	TS Variable	Value	Conditions
Set OSGUID - XP Tablet ACPIAPIC HAL	OSGUID	{1c47ea5f-73cd-44f2-a0a6-37583ac9b774}	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Set IMAGEINDEX - XP Tablet ACPIAPIC HAL	IMAGEINDEX	2	HALNAME equals ACPIAPIC and IsTablet equals TRUE
Set OSGUID - XP Pro ACPIPIC HAL	OSGUID	{61c15f32-1f9f-4c64-806a-202eaccac425}	HALNAME equals ACPIPIC and IsTablet equals FALSE
Set IMAGEINDEX - XP Pro ACPIPIC HAL	IMAGEINDEX	3	HALNAME equals ACPIPIC and IsTablet equals FALSE
Set OSGUID - XP Tablet ACPIPIC HAL	OSGUID	{a8f8689f-ed34-4595-a2f8-02ef98832979}	HALNAME equals ACPIPIC and IsTablet equals TRUE
Set IMAGEINDEX - XP Tablet ACPIPIC HAL	IMAGEINDEX	4	HALNAME equals ACPIPIC and IsTablet equals TRUE

You will also need to set the ProductKey property to either the XP Pro or XP Tablet key depending on whether IsTablet equals FALSE or TRUE respectively. This can be done using conditioned Set Task Sequence Variable steps or using CustomSettings.ini by adding sections like the ones shown below:

[Settings]
Priority=IsTabletCheck, ByTabletType, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

[ByTabletType]
Subsection=Tablet-%IsTablet%

[Tablet-True]
ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
OSInstall=Y

[Tablet-False]
ProductKey=11111-22222-33333-44444-55555

OSInstall=Y

[Tablet-Error]
OSInstall=N

[Default]

where 11111-22222-33333-44444-55555 represents the XP Pro product key and AAAAA-BBBBB-CCCCC-DDDDD-EEEEE represents the XP Tablet PC Edition product key.

Creating Multi-image WIM files with Other Operating Systems

Creating and deploying multi-image WIM files can be done with other operating systems. For example, you could use a single task sequence to create an custom WIM that contains custom images of Windows Vista Business and Windows Vista Enterprise. Or create a single WIM file with Windows Server 2008 Standard, Enterprise, and Datacenter. (You would generally only include images of the same OS and the same architecture with a single WIM. You would not benefit from single instance storage if you tried to include x86 and x64 images in the same WIM.) To do this, the image build process would have to be done more like the MDT 2008 deployment method described above. What is unique about XP is all the images were created for the same source “Operating System” (the XP SP2 media). For including multiple editions of other operating systems in a single WIM requires using multiple MDT “Operating Systems” in the Task Sequence. This requires overriding the OSGUID and IMAGEINDEX like the process above except you would have to condition off another variable.

For example, let’s say you wanted to create a WIM that contains custom images of Windows Vista Business and Windows Vista Enterprise. You could set a custom variable call Edition like this:

[Settings]
Priority=Default, MACAddress, Finish
Properties=MyCustomProperty, CapturedImageIndex, ImageNamePrefix, CompletionFile, BackupFile, Edition

[Default]
OSInstall=Y

.
.
.

[00:15:5D:11:AF:FF]
; Vista Business x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
Edition=Business
CapturedImageIndex=1
ComputerName=vbx86sp1
WsusServer=http://MDTSERVER

[00:15:5D:11:AF:FE]
; Vista Enterprise x86
BuildID=Vistax86SP1
TaskSquenceID=Vistax86SP1
Edition=Enterprise
CapturedImageIndex=2
ComputerName=vex86sp1
WsusServer=http://MDTSERVER

.
.
.

In the image build Task Sequence you would select the most often deployed OS (let’s say Windows Vista Enterprise for example) in the Install Operating System step. You would then create Set Task Sequence Variable steps that override the OSGUID and IMAGEINDEX with the ones for Windows Vista Business with a condition of Edition equals Business.

For deploying the resulting WIM you would do similar conditioned steps for ConfigMgr and MDT but you would have to again use a custom variable for the condition that perhaps get set per computer, location, or role in CustomSettings.ini or the MDT database.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

User Experience for Configuration Manager Task Sequences - Part I

DeploymentGuys — Fri, 05 Dec 2008 02:24:00 GMT

Ever wanted to add your own user communication and interaction to a Configuration Manager task sequence? Below is an HTML Application (HTA) that has a user interface for the task sequence with information about the deployment, a button to cancel or pause the deployment and even a button for a desktop support person to get debug information. This first post will cover how to implement a User Experience HTA and how to send messages to it.

A Configuration Manager Task Sequence runs as SYSTEM and therefore anything launched from it will also run in the SYSTEM context . In WinPE, this will be visible to the user and you can simply launch the HTA from the task sequence. However, if you try to run a User Experience HTA from the task sequence, it will be invisible to your user in the Full OS. Fortunately, you can get around this with by launching your user experience application as a package that runs before the task sequence:

1. Download the sample HTA files provided in the link.

2. Create a package in Configuration manager with the files from (1) as the source files (in the exact directory structure, with CopyUE.bat in the root of the package and the UserExperience subfolder)

3. Create a program that runs the CopyUE.bat file included in the download. Use the following properties for the program

<Choose Allow users to interact with this program> and <Run the program as hidden>

4. Right click on the task sequence in Configuration Manager and choose Properties

5. On the Advanced tab choose "Run another program first" and browse to the Package/Program with the HTA

6. In your task sequence scripts add the following header:

                <script language="VBScript" src="OutputMessage.vbs"/>

7. In your script to output to the user experience screen use the following syntax in Vbscript:

                OutputMessage <severity>,<LeftColumnText>, <RightColumnText>

Where <severity> is either "Info", "Success, "Warning" or "Error"

               e.g. OutputMessage "Info", "Validating machine", "Please wait while your deployment begins"

8. Copy the OutputMessage.vbs file to the package where your script in (7) is located.

Feel free to try out the HTA and customize it as you please. Stay tuned for the future installments of this post that will talk about how to allow users to cancel a deployment, show debug information or perform other interactions.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

Porting Configuration Manager Task Sequences to a Different Environment

DeploymentGuys — Wed, 15 Oct 2008 23:27:00 GMT

Many scenarios arise in which you may want to port your task sequence from one environment to another. Common scenarios include promotion through Lab and QA environments and migration between disconnected hierarchies. Configuration Manager allows you to export task sequences into XML files as an out-of-the-box feature, however there are some things to remember when doing this.

Here is a checklist I like to follow:

1. Passwords: The exported task sequence will replace passwords in the task sequence for known steps before performing an export to ensure no clear-text passwords exist in the XML. This means any passwords in the "Apply Windows Settings" and "Join Domain" steps will replaced with ???????? . Remember to re-enter passwords when importing the task sequence or it will be set to 8 consecutive question marks.

2. Product Keys: Any product keys you enter will be blanked out in the "Apply Windows Settings" step. Remember to re-enter these for your XP task sequences.

3. Package IDs*: If the new Configuration Manager Site Server is not in the same hierarchy, you will have to re-associate all the steps in the task sequence to the packages in the new environment. You may also need to reassociate the boot image and any packages selected to run before the task sequence. Read below for a script to automate this process.

4. Inject Drivers in the Apply Driver Package step: If you have configured the task sequence with an Apply Driver Package step and chosen a boot-critical driver for Pre-Vista OSes, you will need to reselect this driver in the new environment.

5. Setup Windows and Config Manager step: If you are migrating to a new hierarchy, you will also want to see whether any of your Config Manager client properties need to be changed - such as reference to an FSP or SLP.

6. Domain references: You may have to also change any Join Domain steps you have in the Task Sequence to point to a new domain and use different credentials to perform the join.

7. MDT Database: If you are moving to a new hierarchy, the packageIDs in your MDT Database will still point to packageIDs in your previous environment. I am working on a script to help automate this and will post it once it is ready.

*Steps 3 can be a tedious process and often times can result in a manual configuration error. Luckily, we've created some powershell scripts to help make the process less manual:

Automated Scripts:

ExportTSRefs.ps1 - Exports the name, packageID and version of any referenced packages of a given task sequence to a RefIDsFile. This includes OS Packages, OS Install Packages, Driver Packages, Boot Image Packages and Software Packages. Note this only exports the refIDsFile not the packages or XML themselves.

Usage:

."ExportTSRefs.ps1" -sitecode <sitecode> -refIDsFile <filename> -delim <delimiter> -tsID <taskSequencePackageID>
For Example to Export the references of the CEN00001 TaskSequence Package:
."ExportTSRefs.ps1" -sitecode "CEN" -refIDsFile "refIDs.txt" -delim "=" -tsID "CEN00001"
Running the script multiple times with different tsIDs and an existing refIDs file will append only unique packageIDs to the refIDs File.

ScrubTS.ps1 - Reads a RefIDsfile generated by the ExportTSRefs.ps1 script. It then scrubs all the Task Sequence XML files in the given folder for package IDs, looks up packages with the same name and version in the new environment and replaces the XML with the new package IDs. Note: packages in Configuration Manager and source files must already exist in the new environment.

Usage:

."ScrubTS.ps1" -sitecode <sitecode> -refIDsFile <filename> -delim <delimiter> -path <folderpath>
For Example to scrub the package IDs of all the XML files in the C:\ExportedTaskSequences folder
."ScrubTS.ps1" -sitecode "CEN" -refIDsFile "refIDs.txt" -delim "=" -path "C:\ExportedTaskSequences"

Remember the path is a folder name and the script will read all the .XML files in the folder. The new XML files will have the extension _scrubbed.XML.

For both scripts you can use any delimiter you like , I prefer "=" but feel free to experiment.

We are working on developing more scripts to add further automation around the promotion and migration process of task sequences. Stay tuned! As always try out the scripts and feel free to add any comments or contributions.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

Documenting Your Task Sequences Automagically

DeploymentGuys — Sun, 17 Aug 2008 08:53:00 GMT

Often times, after creating an MDT or SCCM task sequence, you need to document it for yourself or your customers. Usually, this involves creating a table with the groups and steps, extracting their descriptions, identifying conditions and denoting the step actions and variables and then having format it all nicely and with indents denoting hierarchy. All of this information is usually already in the XML of the task sequence and all you're really doing is formatting. You can automatically format XML documents by using an XSL transform with the right logic. In order to do this:

1. Copy the attached file at the bottom of the post to the same folder as your task sequence.

2. Open your task sequence in your favourite text editor.

3. After the first line which should look something like this:

<?xml version="1.0"?> or <?xml version="1.0" encoding="utf-8"?>

enter the following as the second line:

<?xml-stylesheet type="text/xsl" href="tsDocumentorv1.xsl"?>

4. Save your task sequence file and open it in Internet Explorer. Presto! The XSL takes care of formatting, indents and sizing.

Your Task Sequence should look like this:

You can even change the styles of groups and steps easily.

1. Open up the tsDocumentorv1.xsl file

2. Edit the following section:

<STYLE TYPE="text/css">
TD.group { background-color:teal;color:white }
TD.step { background-color:beige }
</STYLE>

Change the colours or any other css properties you choose!

The XSL should work with task sequences created with BDD 2007, MDT 2008 and SCCM 2007.

Please try it out and post comments.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region. Credit to Michael Murgolo for initial idea and effort.

How to Setup ConfigMgr 2007 on Windows Server 2008

DeploymentGuys — Thu, 07 Aug 2008 18:32:09 GMT

Installing ConfigMgr 2007 onto a Windows Server 2008 based server can be a challenge. Having recently been through the process for my own lab environment I thought I’d share the process in the hope that it will save you some time when you need to create this configuration. Before you begin you will need to gather the following components:

Windows Server 2008 Enterprise RTM (x86) and Licence Key
SQL Server 2005 and Licence Key
System Center Configuration Manager 2007 and Licence Key

You will also need to download the following components:

Microsoft WebDAV Extension for IIS 7.0 (x86) : http://www.microsoft.com/downloads/details.aspx?FamilyID=036269fa-0040-4ccd-ad3d-78da1ee132fb&DisplayLang=en
Windows Software Update Services 3.0 SP1: http://technet.microsoft.com/en-us/wsus/bb466190.aspx
SQL 2005 SP2: http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&DisplayLang=en
SQL critical update 934458: http://support.microsoft.com/kb/934458
ConfigMgr 2007 SP1: http://www.microsoft.com/downloads/details.aspx?familyid=5AAE62E8-4B7F-4AF7-BE01-AEFAA4BF059A&displaylang=en
ConfigMgr 2007 R2 - available from your Volume Licence web site

Step 1 – Install Windows Server 2008

Install Windows Server 2008 (x86) Enterprise on a machine with the following minimum specification:

Memory: 2GB
Hard Disk 2 x 70GB disks

This could be a physical machine or a virtual machine based on Virtual PC, Virtual Server or Hyper-V

Step 2 – Configure Windows Server 2008

Once the Windows Server 2008 installation has completed, log in as Administrator and carry out the following initial tasks:

1. Set a static IP address for the server

2. Unbind IPv6 from the network card (this is not a full fix for removing IPv6 - look out for a future post on this subject)

3. Enable the AD role as a new domain controller for your chosen domain (not required for ConfigMgr - it's just that all my lab machines are DCs)

Step 3 – Add Additional Windows Server 2008 Roles and Features

Additional Windows Server 2008 roles and features (through Control Panel > Programs and Features) are required to support the ConfigMgr 2007 installation:

1. Add the Windows Deployment Services (WDS) role with default settings (do not configure WDS as ConfigMgr will do that later)

2. Add the IIS role with the following settings (carry out the tasks in the order shown below):

Add ASP.Net Role. Accept defaults.

Add ASP (required for ConfigMgr Reporting Point to function - thanks to Jens Ole Kragh for pointing this out)

Add Windows Authentication

Add Static Content

Add IIS 6 Management Compatibility and all of the sub-components of it.

3. Add the Remote Differential Compression feature

4. Add the BITS Server Extensions feature

5. Install the Microsoft WebDAV Extension for IIS 7.0 (x86) (location for download listed at the beginning of this article)

Use the instructions at http://technet.microsoft.com/en-us/library/cc431377(TechNet.10).aspx to configure WebDav. You will need to follow Steps 4 and 5 in this document under the section “Install and Configure WebDAV”

____________________________________________________________________________________________________________________

WebDAV UPDATE: In some circumstances, WebDAV may not configure correctly when installed as per the instructions. This then causes the issue that clients cannot install via the push method. In this case follow these steps:

1. Open %windir%\system32\inetserv\config\applicationhost.config in your favourite text editor

2. Between the entries <add name=”optionsverbhandler…> and <add name=”staticfile…> (you will find these entries in the <handlers></handlers> section) add the following line

<add name="WebDAV" path="*" verb="PROPFIND,PROPPATCH,MKCOL,PUT,COPY,DELETE,MOVE,LOCK,UNLOCK" modules="WebDAVModule" resourceType="Unspecified" requireAccess="None" />

Your section should look like this:

<add name=”optionsverbhandler…...

<add name="WebDAV" path="*" verb="PROPFIND,PROPPATCH,MKCOL,PUT,COPY,DELETE,MOVE,LOCK,UNLOCK" modules="WebDAVModule" resourceType="Unspecified" requireAccess="None" />

<add name=”staticfile…....

3. Close the file and save it back as %windir%\system32\inetserv\config\applicationhost.config

I'm indebted to one of my MCS colleagues - John Husband for finding a fix for this issue and letting us know)

____________________________________________________________________________________________________________________

Step 3 – Add Additional Non Windows Server 2008 Components

Now that Windows Server 2008 is configured to install ConfigMgr 2007 we now have to add some additional software services for use by ConfigMgr 2007

1. Install Windows Software Update Services 3.0 SP1 32bit (location for download listed at the beginning of this article)

2. Install SQL 2005

3. Install SQL 2005 SP2 (location for download listed at the beginning of this article - carry out the tasks in the order shown below):

Stop the SQLServer service in preparation for SP2 installation. This is to avoid a system restart.

As suggested by SQL SP2 setup wizard, launch sqlprov

Run services.msc and re-start the SQL 2005 service.

Add a domain account to the SQL sysadmin role. This is unique requirement in Server 2008 environment.

4. Install SQL Critical Update 934458 (location for download listed at the beginning of this article)

Step 4 – Install ConfigMgr 2007

Now we are ready to install ConfigMgr 2007 – this is a two stage process to first install ConfigMgr 2007 RTM and then apply ConfigMgr 2007 SP1 – if you have access to the SP1 slipstreamed version of ConfigMgr 2007 then you can skip step 2 below.

1. Install ConfigMgr 2007

Extend the schema by running the \smssetup\bin\i386\extadsch utility. Run this under Enterprise Administrator credentials and review c:\extadsch.log for results.

Either use an Internet connection (for auto-download) or a pre-staged folder for setup update files required by ConfigMgr setup application.

2. Install ConfigMgr 2007 SP1 (location for download listed at the beginning of this article) and the ConfigMgr 2007 R2 components (if available via your licence agreement).

Either use Internet connection (for auto-download) or a pre-staged folder for setup update files required by ConfigMgr SP1 setup application.

NOTE: SP1 is the minimum requirement for running ConfigMgr 2007 on Windows Server 2008 - however ConfigMgr 2007 R2 will give you additional deployment features such as integration with Application Virtualization Management (APP-V), unknown computer support and multicast integration with Windows Deployment Services (Windows DS)

3. After installation, add the PXE Service Point and Reporting Point site system roles.

That's it - you are now ready to start using all the lovely features of ConfigMgr 2007 SP1 or ConfigMgr 2007 R2 based on a Windows Server 2008 platform - simple wasn't it? :-)

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Useful Script Number 6 - Pausing the Task Sequence

DeploymentGuys — Mon, 07 Jul 2008 19:59:18 GMT

Have you ever wanted to pause the task sequence in MDT 2008 or ConfigMgr 2007 for a few seconds while something catches up...? I had a requirement to do this recently where I ran a task to close and cancel the Windows Sidebar at the start of the State Restore phase of the task sequencer and then turn the Windows Sidebar back on again at the end of the State Restore phase - I was doing this as the Windows Sidebar can sometimes get in the way of some customisation scripts and you can also see peculiar VB messages when 2007 Office System updates are applied. When the Windows Sidebar is turned back on, there is a couple of seconds before the Sidebar actually appears - yet my task for turning on the Sidebar had returned and the task sequence had moved on...it made be think that there may be other situations where a slight delay in returning to the task sequence may be useful - sure you could add sleep commands to the scripts that your running as commands - but that doesn't help with the tasks that are not scripted - so here is an MDT based script that will pause the task sequence for a specified number of seconds (specified on the command line)

I first have a couple of variables to store the time to pause (strTime) and the script name (strSName - for logging purposes) and the integer argument for the sleep method

Dim strTime, strSName, IntTime

ZTIProcess=1

...I then use a call to ZTIUtility.wsf to set the script name to the strSName variable - this is then used to insert the script name at the start of each line in the log.

strSName=oUtility.ScriptName

...then it's another call to ZTIUtility.wsf to use the arguments class - this makes passing input to the script via the command line easy - in this case I am setting a command line input called "Time"

strTime = oUtility.Arguments("Time")

oLogging.CreateEntry strSName & ": Starting Actions ********************************************* ",LogTypeInfo

...then I check that Time has been specified as a command line input (exit if not) or set the IntTime to number of seconds from the command line x 1000 to get milliseconds

If strTime="" Then
    oLogging.CreateEntry strSName & ": No pause time was specified on the command line.",LogTypeError
    ZTIProcess=90
    Exit Function
Else
    oLogging.CreateEntry strSName & ": Pause time has been set to " & strTime & " seconds",LogTypeInfo

IntTime = strTime * 1000
End if

...I then take the intTime (in milliseconds) and add it to the sleep method to pause the script

oLogging.CreateEntry strSName & ": Task Sequence will pause for " & int(IntTime/1000) & " seconds",LogTypeInfo

wscript.sleep intTime

oLogging.CreateEntry strSName & ": Task Sequence has been paused for " & int(IntTime/1000) & " seconds - returning control to the Task Sequence now",LogTypeInfo

oLogging.CreateEntry strSName & ": Completed Actions ********************************************* ",LogTypeInfo
ZTIProcess = 0
End Function

The script is called CFG-TSPause.wsf so the command line to run it would be CFG-TSPause.wsf /Time:xx (where xx = the number of seconds that you want to pause the task sequence for) Drop the script into your <Deployment Share>\Scripts directory. You can then add the script anywhere in your task sequence by adding a Run Command Line task and specifying the script and the command line input for the number of seconds you want to pause.

As usual, the full script is up on the Deployment Guys SkyDrive:

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

SCCM 2007 and Microsoft Deployment Toolkit - Video Walkthrough

DeploymentGuys — Thu, 20 Mar 2008 11:35:00 GMT

Are you struggling with setting up SCCM 2007 Operating System Deployment and integrating MDT? - I have created a video walkthrough that shows you how to:

Setup the server environment for SCCM 2007 OS deployment
Configure the SCCM 2007 Site Settings
Configure the SCCM 2007 Computer Management Settings
Configure the SCCM 2007 Operating System Deployment Settings
Setup and use MDT integration with SCCM 2007
Add a reference machine object to SCCM 2007
Create a build and capture reference image for mass deployment using SCCM 2007

View the SCCM and MDT Video Walkthrough from the Windows Media Servers here!

View the SCCM and MDT Video Walkthrough from the TechNet Edge Media Servers here!

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Driver Management (Part 1) - Configuration Manager

BenHunter — Fri, 15 Feb 2008 12:08:00 GMT

I am often asked what the best way is to manage drivers with both BDD/MDT and ConfigMgr. With this in mind I thought I would create two blog posts dealing with this topic. The first post (this one) will cover ConfigMgr and the second BDD/MDT driver management.

Please note this is not the only way to manage drivers, there are many different ways to manage drivers. However this is an approach that I have used many times with much success.

Overview

Before I get into the details I would like to provide a quick overview of driver management.

The first thing we must understand is the type of drivers that you need to manage. I place drivers into two categories:

NICE Drivers - Drivers that install using an INF file.
BAD Drivers - Drivers that must be "installed" - This could be a Bluetooth driver, finger print reader software or even DVD software that is specific to a particular model type. I also refer to these drivers as "Hardware based applications".

Next we need to understand where drivers are used during the deployment process. There are two areas where they are used:

Host OS - These are drivers that are installed on the Host OS.
Boot images - These are drivers that are required by the ConfigMgr Windows PE boot images to enable OS deployment. The key driver types are network and mass storage drivers.

Finally we need to understand the options ConfigMgr provides for installing drivers. Whenever you import drivers you must add them to a driver package. Once the drivers have been added to a package there are two methods you can use to install the drivers:

Auto apply drivers - Driver packages are primarily for distribution purposes. ConfigMgr performs a PnP scan of the computer and chooses which drivers to install from all available drivers in all available driver packages. You can filter by driver categories, is tells ConfigMgr to only consider certain categories when choosing drivers.
Apply driver package - All the drivers in the package are injected, whether they are needed or not.

So now that I have covered the basics lets discuss how I manage drivers.

Process

I find the simplest way to describe how I manage drivers is by using an example. The example I will use I perhaps the most common scenario in OS deployment, adding support for a new hardware model.

At a high level the process involves the following steps:

Create a new package that contains all of the required drivers for this hardware type
Add an “Apply driver package” task to the task sequence with a WMI filter based on model type
If required I configure the “Apply driver package” to apply a Mass Storage driver
Create an application for each driver that must be installed
Add all applications to the task sequence with a WMI filter based on model type

I can hear everyone asking the question, why do I use the "Apply driver package" process rather than the "Auto apply drivers" process? Well nice of you to ask, I appreciate the flexibility that the "Auto Apply Drivers" action gives but it does not cover all scenarios. I prefer to use one method of driver installation that will install all drivers (simple is best). The two scenarios that are not covered by "Auto apply drivers" process are:

Devices that aren’t found by a PnP scan such as USB devices, multi level drivers and devices not enabled during deployment (like Bluetooth).
Mass Storage drivers. On pre Vista operating systems, boot critical drivers have to be installed with Apply Driver Package.

The second obvious question is what is a WMI filter and why do we use it? You cannot add one “Apply driver package” task to the task sequence that will automatically determine the hardware and install only the package you require (this is what I would like :)). So to get around this issue you need to add an "Apply driver package" task to the task sequence for each hardware type. You do not want to apply every package to every machine so we need some way of ensuring that each package is installed on the correct hardware type only. Fortunately ConfigMgr has the ability to filter tasks based on a WMI query.

It is also worth noting that if a Mass storage is required for a particular hardware type then ConfigMgr will inject it for you! This was not previously possible with pre Vista operating systems. This is one of my favourite features of ConfigMgr.

Steps

So enough of all this talk lets get down to the actual steps required to implement driver management.

Create a driver package (GOOD Drivers)

1. Gather together all of the good drivers for the new hardware type and place them in a folder.

2. Open the deployment console and Navigate to Site Database - Computer Management - Operating System Deployment - Drivers

3. Right click on Drivers and select Import (This will launch the Import new driver wizard)

4. On the Locate Driver screen select Import all drivers in the following network path (UNC)

5. Specify a UNC path to your drivers folder in the Source folder field and click Next

6. On the Driver Details screen ensure all drivers are selected and click Next

7. On the Add Driver to Packages screen click New Package

8. On the New Driver Package window update the Package Name filed will an appropriate name (e.g. Toshiba - Tecra M5)

9. Update the Driver Package Source field with an appropriate location, this will most likely be stored with your other packages. Click Next.

10. If you need to add any network or mass storage drivers to your boot images then perform the following step. On the Add Driver to Boot Images screen select any boot images that require the updated drivers and click Next.

NOTE: You will need to update the boot image distribution points for this change to take effect.

11. At the Summary Progress and Confirmation screens accept the default settings and Close the wizard.

12. Once you have created your driver package then you should assign it to distribution points at all sites where this hardware type is deployed.

Add driver package to the task sequence

Once we have created the driver package we need to add it to our task sequence.

1. Create a folder that will contain all of your "Apply Driver Package" tasks. This folder must be added before the Setup windows and ConfigMgr task. When I have a group of similar tasks to add to the task sequence then I create a folder for these tasks. This is shown in the screen shot below.

2. Add an"Apply Driver Package" task to this folder specifying the driver package that you have created in the previous step. If this model type requires a mass storage driver then select it as shown below.

3. Next we need to add a WMI condition to this task. The first thing we need to do is determine the value of the WMI model field for our hardware type. I have found the simplest way to do this is via a WMIC query.

The following steps detail how to perform a WMI, ensure that these steps are run on the new hardware NOT the server:

a. Open a Command Prompt

b. Type WMIC

c. To determine the Model, type CSProduct Get Name

4. Select the task Options tab

5. Select the Add condition drop down menu and select Query WMI.

6. Add the following text to the WQL Query field where <MODEL> is replaced by the WMI value for your hardware type - SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" and click OK

NOTE: For some model types there can numerous variations of the WMI model value. For example the HP D530 or many IBM computers. In these scenarios you can specify part of the value in the <MODEL> field. For example when the WMI value for a HP D530 is "HP D530 [ABC12345]" then you can specify "HP D530".

Install Hardware based applications (BAD Drivers)

The last part of the driver management puzzle is the BAD Drivers or hardware based applications.

The first thing you need to do is create an application in ConfigMgr that will install the application. I will not provide step by step guidance on this process but it is important that the following two settings are enabled:

1. The program must be set to run "Whether or not a user is logged on"

2. The option "Allow this program to be installed from the Install Software task sequence without being advertised" must be enabled

Once you have created the application you need to add it to our task sequence.

1. Create a folder that will contain all of your "Application Installation" tasks. This folder must be added after the Setup windows and ConfigMgr task. I usually call this folder "Hardware Based Applications".

2. Create a folder within the folder you created in the previous step. This folder should be named after the hardware type (e.g. Toshiba - Tecra M5).

NOTE: When installing hardware based applications I create a folder for each hardware type that contains all of the applications for that hardware type. I then apply the WMI conditions to the folder, NOT the application.

4. Next we need to add a WMI condition to this folder.

5. Select the task Options tab

6. Select the Add condition drop down menu and select Query WMI.

7. Add the following text to the WQL Query field replacing <MODEL> with the WMI value for your hardware type - SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%<MODEL>%" and click OK

8. Add an"Install Software" task to this folder specifying the application that you have created in the previous step.

9. Repeat this process for all hardware based applications!

So that's how I manage drivers .... simple :)

For more information no driver management please refer to the ConfigMgr online documentation library.

Driver Management (Part 2) - BDD/MDT will be coming shortly to the deployment guys.

This post was contributed by Ben Hunter a Consultant with Microsoft Services New Zealand.