The Deployment Guys : Configuration Manager

ConfigMgr Admin Console GUID documentor

DeploymentGuys — Sun, 06 Dec 2009 04:17:00 GMT

ConfigMgr allows for great extensibility to perform right click actions. You can find information on this here http://msdn.microsoft.com/en-us/library/cc143056.aspx . Those of you that have done this before know that the first step is digging through...(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.

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.

Logging All the Configuration Manager Task Sequence Variables

DeploymentGuys — Fri, 29 Aug 2008 18:31:00 GMT

When debugging a MDT based Configuration Manager Task Sequence, it is often helpful to know what certain built-in Configuration Manager variables are set to during a step in the task sequence. For instance, you may want to see if _SMSTSLastActionRetCode was equal to a certain value or perhaps which management point the client is using by checking _SMSTSMP. These variables and more are available in the Microsoft.SMS.TSEnvironment and you can easily log them using the script snippet below:

Dim sVar

Set osdV4 = CreateObject("Microsoft.SMS.TSEnvironment")

For Each sVar in osdv4.GetVariables()
oLogging.CreateEntry sVar & ":" & oEnvironment.Item(sVar), LogTypeInfo
Next

A list of the variables and their values can be found at http://technet.microsoft.com/en-us/library/bb632442.aspx .

The full ZTI-style script is included below. Add the script to the Microsoft Deployment Toolkit package and you can call this script as a task in the task sequence. The variables will be outputted to OutputTSVariables.log.

Try it out and feel free to comment.

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.

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.