Chris Nackers Blog

ConfigMgr and MDT Deployment Solutions

Useful Blogs

User Groups

April 2010 - Posts

Driver Management - Good Info To Read

If you attended the Driver Management session by Michael Niehaus and Johan @ MMS, or even if you didn't have that opportunity, I would recommend you read the 3-part series that Michael has on his blog right now. The 3 part "novel" pretty much covers every known way to manage/handle drives with ConfigMgr OSD.  Maybe it'll spark a review of your current methods or give you some ideas on how to improve what you are already doing well. 

Michael was kind enough to link back to my post here on Driver Management, so thank you to him for and to Johan for mentioning it during the MMS session.

Take a read:

Johan also added a MDT LTI post on his blog:


Making Sure A ConfigMgr Task Sequence Has All The Packages It Needs To Continue Part 2

I had previously posted on a blog where Michael Niehaus created a powershell script to check for the necessary packages for a task sequence.

Jason Schefelmaer has take it one step further and add some prompts to it.  See his post and download here.


  • ConfigMgr Server Prompt now uses a windows form to keep in form with the other prompts
  • Task Sequence prompt has checkbox to allow ‘All Task Sequences’
  • Distribution Point prompt also has checkbox to allow ‘All Distribution Points’
  • Added new prompt with datagrid showing the missing packages asking to replicate them
  • Updated comments, removed unnecessary code I included in the first version.
  • Fixed an issue with Distribution Points being assigned to the central server, and not their primary server. (Work around for New-SCCMPackageDP function)


Deployment Web Service V7

Maik has updated the Deployment Web Service to V7.  This is a pretty easy upgrade from V6, you just need to replace all the files in your virtual directory with the new files, minus your web.config as that hasn’t changed and saves you from reconfiguring, and then recycle your app pool. 

Download here.

Here are some of the updates:


- AddComputer (MACAddress, UUID, ComputerName, SiteCode) : Adds a new computer to SMS/SCCM and returns the ResourceID if successful

- ClearLastPXEAdvertisementForCollection (CollectionID, SiteCode) : Clears the last PXE advertisement flag for all computers in the specified collection

- ClearLastPXEAdvertisementForComputer (MACAddress, UUID, SiteCode) : Clears the last PXE advertisement flag for the specified computer

- ClearLastPXEAdvertisementForComputerByID (RessourceID, SiteCode) : Clears the last PXE advertisement flag for the specified computer

- DeleteComputer (MACAddress, UUID, SiteCode) : Deletes a computer from SMS/SCCM.

- DeleteComputerAssociation (ReferenceComputerMacAddress, ReferenceComputerUUID, DestinationComputerMacAddress, DestinationComputerUUID, SiteCode) : Deletes an existing association between two computers

- DeleteComputerAssociationByID (ReferenceComputerResourceID, DestinationComputerResourceID, SiteCode) : Deletes an existing association between two computers

- DeleteComputerByID (ResourceID, SiteCode) : Deletes a computer from SMS/SCCM

- GetComputerName (MACAddress, UUID, SiteCode) : Returns the name of the specified computer

- GetComputerNameByID (ResourceID, SiteCode) : Returns the name of the specified computer

- HasAdvertisement (MACAddress, UUID, AdvertisementID, SiteCode) : Checks if a specific advertisement is available for the specified computer

- HasOSDAdvertisementByCollectionID (MACAddress, UUID, CollectionID, SiteCode) : Checks if an OSD advertisement is available to the specified computer limited by a specific collection

- RemoveComputerFromCollection (MACAddress, UUID, CollectionID, SiteCode) : Removes a computer from the specified collection

- RemoveComputerFromCollectionByID (ResourceID, CollectionID, SiteCode) : Removes a computer from the specified collection

- SearchComputerByName (SearchString, SiteCode) : Returns a list of computers with the supplied search string as part of their name/netbiosname


- GetComputerParentPath (ComputerName) : Returns the LDAP path to the parent object of the computer (helpful to save the current OU of a computer at the beginning of a deployment)

Fixed a bug in the GetComputerNameByNetbootGUID and SetComputerDescription functions.


- GetComputerRoles (SerialNumber, AssetTag, MacAddress, UUID) : Returns a list of Roles assigned to the computer

Microsoft Management Summit 2010

I’m currently in Las Vegas this week attending MMS 2010.  There has been some some fantastic content surrounding Configuration Manager V.Next.  Very interesting what they will be doing with that product.  This conference is hands down one of the best conferences you can attend for technical information for Microsoft System Center products.

Also had some great discussions around MDT last night during 2 Birds of a Feather sessions, the first one was a Ask the Experts: MDT 2010 with Michael Niehaus, also attending were Tim Mintner, Johan Arwidmark and Ben Hunter. Following that session, I hosted a Open Forum: MDT/OSD and we also had some great discussions surrounding MDT/OSD and Image creating best practices.  As usual we ran out of time, there is just never enough time to discuss OSD/MDT!

Michael and Johan put on a fantastic presentation today on Driver Management called “A Drivers Saga – The Control Freak Meets the Dynamic Developer”, they showed both management in MDT 2010 LTI, along with ConfigMgr and the associated pains :)  Johan gave me a nice plug for my post on driver management.  So I really appreciated that.  There are many ways to manage drivers with ConfigMgr and for us, the hybrid solution works really well and kind of gives you the best of both worlds.

Also announced today was Configuration Manager R3 beta, read more here.

Well that’s about all for now, I’m sure I’ll have more to post after a few more sessions.


Hiding (and showing) the task sequence progress dialog box

Linking to yet another post from Michael Niehaus :)

He’s got a nice post showing you how to hide and then display the TS progress bar again.  This is nice since the TS progress bar is always on top and sometimes it’s nice to hide that so you can do something else.

Read more here.

Making Sure ConfigMgr Task Sequence Has All The Packages It Needs To Continue

Michael Niehaus posted a blog post with some powershell scripts to help identify what packages you might be missing for your TS.  This can be a frustrating process as you try to identify what packages are missing, since the generic error doesn’t tell you what is all actually missing, just that something IS missing (one at a time). :)

Script files are attached to his post located here.

Configuring Shared Folder Permissions

I was helping someone configure some shares the other day for Migdata and Logs.  I dug this up from the old BDD 2.5 documentation, it’s a good reference point for creating access to shares in order for computers to put files there.

After you have configured the SMS client access accounts, you need to configure the appropriate shared folder permissions. Ensure that unauthorized users are unable to access user state migration information and the deployment logs. Only the workstation creating the user state migration information and the deployment logs should have access to these folders.

To configure the shared folder permissions for each folder listed in Table 24, perform the following steps for each folder:

1. Start Windows Explorer and navigate to SharedFolder (where SharedFolder is one of the shared folders listed in Table 24).

2. Right-click SharedFolder (where SharedFolder is one of the shared folders listed in Table 24), and then click Properties.

3. On the Security tab, click Advanced.

4. On the Permissions tab, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects check box.

5. When the Remove when prompted to either Copy or Remove the permission entries that were previously applied from the parent appears, click Remove.

6. On the Permissions tab, click Add.

7. In the Enter the object name to select text box, type Domain Computers, and then click OK.

This action allows domain computers to create subfolders.

8. On the Permission Entry for Text dialog box, in the Apply onto list, select This folder only.

9. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Create Folders/Append Data permission, and then click OK.

10. Repeat steps 6– 9 substituting Domain Users for Domain Computers.

11. On the Permissions tab, click Add.

12. In the Enter the object name to select text box, type CREATOR OWNER, and then click OK.

This action allows domain computers and domain users to access the subfolders they create.

13. On the Permission Entry for Text dialog box, in the Apply onto list, select Subfolders and files only.

14. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Full Control permission, and then click OK.

15. Repeat steps 11–13 for each group that you want to grant administrative privileges.

The permissions you set in these steps allow a workstation to connect to the appropriate share and create a new folder in which to store user state information or logs, respectively. The folder permissions prevent other users or computers from accessing the data stored in the folder.

Note   The default permissions on the SMS distribution point shares should provide the appropriate resource access by default.

DirectX Versions

Want to know what version of Directx comes with what OS?

Here you go!


Posted: Apr 12 2010, 09:52 AM by cnackers | with no comments
Filed under: , ,
Hiding Cscript Window in Custom Boot Wizards

If you have ever wanted to hide that black cscript window in your custom wizard or pre-execution hook, read more here.  Nice post showing you how to get rid of the window.

MDT 2010 – Testing customsettings.ini rules

There is a very slick/simple way to process your customsettings.ini to see if your rules are processing the results you want.

All you need to do is create a folder called “zti_debug” or something and put the following files in that folder:

ztigather.wsf, ztigather.xml, ztiutility,vbs, ztidataccess,vbs, (copied from deploymentshare\scripts or your ConfigMgr MDT Scripts package) and your customsettings.ini

Also copy Microsoft.BDD.Utility.dll and put it on a \x86 folder, otherwise you will see "Can't load activex object result of missing Microsoft.bdd.utility.dll" in the logs.

Then i would create a batch file like this:


if exist c:\minint\nul rd c:\minint /s /q
cscript.exe ZTIGather.wsf /debug:true


Run that batch file and it will process your rules and spit out BDD.log and ZTIGather.log into the MININT\SMSOSD\Logs folder and you can see how things are being processed.  I usually just leave bdd.log open in trace32 and review it after every time i run it.

Hope this helps!

Configuration Manager 2007 R2/SP2 Driver Management

The post will cover the most common methods that I know of for driver management in ConfigMgr.  For once I won’t be talking about MDT integration!

Auto-Apply Drivers

Auto-Apply consists of importing all your drivers into ConfigMgr and then utilizing the “Auto-Apply Drivers” step in a Task Sequence, this step will match PNP ids and inject the drivers that match the detected ID’s.  You can limit selections by utilizing “Categories” or you can simply just let it have free reign on your driver database.  The only step i’ve had to work with on this TS step is the “Install only the best matched compatible drivers” vs “Install all compatible drivers.”  I had a few models that wouldn’t install all drivers unless I used “Install all compatible drivers.”  The biggest problem with this method is that it will grab the newest compatible driver, so if you just imported the latest greatest for a new model you have, many of those drivers will work for older models and will be used for those models even if you don’t want them to be.


1) Quick, easy

2) Don’t have to know what specific drivers you need, provided there is a matching driver, your device will be installed correctly, that works great for some people

3) Matches drivers based upon PNP


1) Sub-devices can be missed sometimes

2) No control over what drivers are being put where, you have some control with “Categories”, but not the degree of control some people like, it will grab the newest/greatest driver it can find that matches your device

3) Matches drivers based upon PNP :)

Step in the TS this method focus’s around:


Other main focus points you will want to be concerned with:


Using Driver Packages

This is commonly known as the “control freak” method.  When using this method you typically want to control the specific drivers going to each model.  Usually this is driven by a Task Sequence step with a WMI query to match up the Model.  The major issue with this is that ConfigMgr won’t let you import duplicate drivers, and if you are using common manufactures, 50-80% of your drivers could be same for every model.  So what you end up doing is creating driver packages in ConfigMgr, but not actually importing the drivers, you instead put the in the driver package source files and then distribute those to the Distribution Points, thus allowing you full control over what drivers are in the package.  This leads to a bit more maintenance since you have to work with the drivers from a folder perspective and you mostly maintain them outside of ConfigMgr.  You would still import NIC and Mass Storage drivers (for XP) as you would need those imported ideally to inject them into your boot images, although you could inject them into the wim yourself if you really wanted to.  This method works great when you have to be concerned with certain versions of drivers going to certain models, a great example for us is we need our video drivers to be Certified by Solidworks, to get support, we need to ensure the machines are using a correct Certified driver.  The problem with the new unified drivers is that the newest version that i need for my new laptop also happens to work for my 2 year old workstation class machine, however that newest driver isn’t Solidworks Certified.  Again the theme of this method is control.

This is the method i have personally used up to this point, I now use the 3rd method which i’ll talk about in a bit. 


1) Complete control over what is going where

2) Control! x2

3) Injects all drivers in that package, anything in that package is available to the OS


1) Can’t easily import duplicate drivers

2) More administrative overheard

3) Not typically managing most of the drivers from with ConfigMgr

4) You will have the same drivers in multiple packages, taking up more space, possible concern for some


Hybrid of Auto-Apply and Driver Packages

After reading this post by Keith Garner, I got to thinking about how I could do something similar in ConfigMgr.  When i really sat down to think about it, the only drivers that really mattered to us was controlling the video drivers.  So I decided, why couldn’t i do PNP for everything but the video drivers.  Even more on that, unless it’s a machine running Solidworks, i really don’t care what video drivers are installed.  So I basically ended up with this structure:

-Common Drivers (Will use PNP)

-Common Video Drivers (Will use PNP)

-Specific Video Drivers (one package for each model requiring a specific video driver)

I imported all my common drivers into ConfigMgr, imported all my video drivers, then seperated them out into common drivers and the specific drivers.  I then created all the driver packages i needed for each model that required a specific video driver and added the required driver to the package.  I made use of “Categories” to control what was being used for PNP detection.


1) Advantages of PNP detection along with the control over drivers by using driver packages when needed


2) Takes a little configuration and setup

The first section in my Driver Management part of my Task Sequence is for Windows XP Mass Storage drivers, I do a WMI query for the deviceID and then inject the appropriate MSD, this allows me to not have MSD in my other packages and I can have a single driver package for all MSD’s and then just inject when appropriate. 




Next, I do a Auto Apply driver step that injects all my Common Drivers, I have these all under a Category called “Common”, this would be audio, modem, card readers, anything that isn’t a video/display device.



Next I have a section for Video Drivers, the driver(s) I want to control in my case.  First we inject any Common Video Drivers for models I don’t care about. Just get the best video driver available installed for me.



This is driven by a WMI Model query on the backend for all the models I don’t care about, notice I use “LIKE” statements to get around HP’s funky part #’s:


Next we get into the specific models that I want to inject specific video drivers:


Here we are using a Driver Package for each TS step with a WMI query on the backend, this Driver Package contains the Certified driver that I need for that model:



That’s it! That is how i now manage my drivers, I feel this to be the most effective method for our environment.

Hope this helps or inspires someone else.