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

Automatically remove computers from a collection and reset the last PXE advertisement flag after a Deployment has finished

Maik Koster posted a nice blog discussing the removal of computers from a collection after OSD has completed. This is especially handy if you are using his web service to drive your OSD process.

Read the full post here.

Two of the administrative tasks you often have to do after a SCCM based Deployment has finished is removing the computer from the OSD Collection it has been added to start the Deployment (you don’t really want to leave a computer in a collection with an active OSD advertisement, do you?), and to clear the last PXE Advertisement flag in cases the Deployment has been started via PXE.

The latter is mainly interesting for testing purposes, where you need to re-image the same computers over and over again. But it’s also helpful in cases where the initial Deployment failed. If the underlying problem has now been fixed the Tech (or End-user) might not be able to re-initiate the Deployment before you also cleared the last PXE advertisement flag of that computer. I understand that this has been created to avoid kind of a Deployment loop for computers configured to boot from network first. But as we also remove the computer from the collection there shouldn’t be any bad side-effect. And there is still the caching on the PSP.

Since Version 7.0 the Deployment Webservice (Download) supports a couple methods that let us remove a computer from a specific collection and also to clear the last PXE advertisement flag. So all we actually need to know is the current collection. The following is based on an idea from Richard Zuraff and Jason Scheffelmaer (give credit where credit is due 😉 ). They suggested to simply add the same custom variable to each OSD Collection and then just add the CollectionID to this variable. If the TS executes, this variable will be available for us and filled with the ID of the appropriate collection. This way we can use a generic approach to remove the computer from whatever collection is configured in this variable. Very easy to implement and support.


MDT/ConfigMgr – UDI – Having Multiple Configurations For the UDI Wizard (UDIWizard_Config.xml)

By default the UDI based task sequence will use the UDIWizard_Config.xml contained in your MDT 2010 Update 1 toolkit package.  What if you want to use the same toolkit package for multiple task sequences, but provided different versions of the UDI wizard? For example, if you have different domains you want to join, or possible different applications to be presented to the user, or even skip screens for some task sequences.  Well that is possible, but it’s buried in the documentation!

Reading The Documentation

First, here are the steps outlined in the MDT documentation under the section “Configure the OSD Setup Wizard Behavior.”

To override the configuration file that the Operating System Deployment (OSD) Setup Wizard uses

1.         In the Configuration Manager Console, go to Computer Management/Task Sequence.

2.         Right-click task_sequence (where task_sequence is the name of the task sequence you want to edit), and then click Edit.

3.         Beneath the State Capture phase, click the UDI Wizard task sequence step.

4.         On the Properties tab for the UDI Wizard task sequence step in Command line, modify the text as follows (where path is the path to the configuration file which is relative to the Scripts folder and file_name is the name of the configuration file)

(If you put the xml files in the \scripts folder of your toolkit package, you don’t need to specify a path value, just as you will see I didn’t specify a path in my example below):

cscript.exe “%DeployRoot%\Scripts\UDIWizard.wsf” /definition:path\file_name.xml.

Note   The above text appears on one line. The line wrap seen here is the result of document formatting constraints.

5.         Repeat steps 3 and 4, substituting State Capture with Preinstall/New Computer Only.

6.         Repeat steps 3 and 4 for any custom task sequence steps that run UDIWizard.wsf.

7.         Click OK.

Performing The Steps

Now, lets show you how to actally do that. 

First, in my toolkit package, you can see i have 2 definition xml’s:


Next, we will want to edit our task sequence:


First, we need to to go the first UDI Wizard step located under the State Capture phase:


Then we need to update our command line to add the /definition command and tell it what file to use, if you put the XML in the \scripts folder of the toolkit package then you won’t have to specify a path value here, you can just specify the file:


Perform the same actions for the UDI Wizard step under Preinstall/New Computer Only:


Perform this on any other custom step you might have added that calls the UDI Wizard, then click OK to save your changes:


Now, when we run the task sequence on our client, we’ll see the new welcome page i created to ensure that I’m using the new configuration instead of the default UDIWizard_Config.xml.


Using A Custom Variable To Define The XML

Now another interesting way to set a different XML is to take advantage of the MDT integration and use a custom variable.  This would allow you have a single task sequence that could call any number of UDI config xml’s.  You could take that a step further and use any number of MDT rules to define how that XML gets set, like based upon the location, or chassis type, or a plethora of other things, way cool! I think this is a fantastic idea and was proposed to me by Michael Niehaus in an email exchange we had.  So lets show you how to do that.

First lets change our task sequence to use a custom variable we’ll call “UDIXMLFile”.




Next we will need to configure the customsettings.ini file for our settings package for this task sequence. So here is the package I am going to modify.


Here is a bone stock customsettings.ini file:


Here we’ve added a custom property of “UDIXMLFile”, and we’ve configured a value of UDIXMLFile=UDIWizard_Config_2.xml


Next, save your changes and make sure to update the distribution point for your settings package. Again we launch the task sequence on our client to verify it’s using the XML file we want.


So how about an example were we set different XML’s based upon the DefaultGateway.  Here we’ll set a UDI config XML based upon whether you are in London or the United States. Maybe it’s something as simple as having a different welcome page message, or you’ve configured different OU’s to be selectable.  Here is an example customsettings.ini where we’ve configured either a UDIWizard_Config_2 or UDIWizard_Config_3 file to be used depending on where you are located.


Just a quick example to show you some of the possibilities. 

Hope this helps!



MDT/ConfigMgr – UDI – Web Service 404.3 Error

I was having trouble getting my web service to respond, or even browse to make sure it was working. If i tried to connect to the web service via the UDI Wizard Designer, then I would get the following:


If i tried to browse to the web service, then i would get the following:


I noticed after reading the release notes for Update 1, that there is a known issue with UDI and the 404.3 error.   Basically stating the following:

“If you receive error 404.3 when browsing to the UDI Designer web service, this error is typically the result of the Windows Communication Foundation (WCF) multipurpose Internet mail extensions (MIME) type not being registered correctly. To register the WCF MIME type on the web server, go to %Windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation. From an elevated command prompt, run ServiceModelReg.exe –I to register the MIME type for the .svc extension, which the web service requires.”

Running this, showed a bunch of components getting installed:


Testing the web browser again, I was not able to browse to the web service:


Also, I was able to connect through the UDI Wizard Designer now as well:


Lesson learned, read the release notes 🙂


Setting up the Deployment Web Service

The information in this post is provided as-is, please use at your own risk and test appropriately.

Been meaning to create a post on this for quite some time.  I just want to cover the basic setup of the Deployment Web Service created by Maik Koster.  The latest download can be located here. (V7 as of this posting)  There is some documentation on the Codeplex site, and i urge you to review that as well.  CodePlex Documentation.  If you are going to be using the MDT functions of the web service, then you need to configure the Stored Procedures as well, and I recommend you read Maik’s blog post on this topic as i won’t be covering that in this post.

This will just be a quick-start guide for Server 2003 and IIS 6. So lets get started!

1) First download the files from the site linked above.

2) Extract out the web service files into a directory of your choosing, I still like to put items in Inetpub if it’s IIS related.  So \Inetpub\DeploymentWebService in my case.

3) Next we need to create a Virtual Directory in IIS.

Right-Click on Default Web-Site and select New – Virtual Directory




Name the Virtual Directory and click Next


Browse to the path of the files you extracted


Select Next


Make sure to check “Read” and “Run Scripts”, then click Next


Click Finish


4) Next we need to setup the Application Pool, I generally like to create a separate pool so you can recycle the pool without effecting anything else you might have running on that IIS server.

Right-click on Applications Pools and select New – Application Pool


Name the Web Pool appropriately, then click OK


Next we want to configure the identity of the web pool, here you can select the account that will run the Web Pool, most people will use a service account and specify those credentials here, this account will be the default account the web service is running under, so it will need rights to perform the web service functions you want to use:


5) Next we need to setup the Web Service to use the new Pool:

Go into the properties of the Virtual Directory you created and change the Application Pool to the web pool you previously created (MDTWebPool in screenshot):


You’ll also want to make sure under the ASP.NET tab that ASP.NET versions 2.0 is selected:


6) Next we need to configure the web service settings in the web.config (this step copied from Maik’s documentation)

On default, the webservice will use the configured application pool user for authentication. It requires only a couple Application Settings to be set:

  • RootServer – The SCCM Root Server
  • SLPServer – One SCCM Server with the SLP Role
  • RootSiteCode – The Root site code

For Access to the MDT Database you need to configure at least

  • MDTDBServer – The MDT Database server (with Instance if necessary)
  • MDTDBName – The MDT Database name
  • MDTDBIntegratedSecurity – Set to "True" if you want to use the application pool account for authentication. If set to "False" you need to supply the following two settings
  • MDTDBUser – Username to access the MDT Database
  • MDTDBPassword – Password to access the MDT Database

For Active Directory access, you can optionally configure the following Application Settings. This is only necessary, if the application pool user account does not have enough permissions to do execute the required functions, and/or if you need to access a different domain as the application pool User is member of:

  • ADDomain – Domain to query (use either "" or "DC=Domain,DC=COM" format)
  • ADUsername – Username for authentication
  • ADPassword – Password for authentication

7) Make sure to recycle the app pool for your web service after you’ve made changes to the web.config

8) You should now be able to use the Web Service. Open your browser and go to the following sites to verify they load correctly:

  • http://YourWebServer/YourWebserviceFolder/ad.asmx – For Active Directory related functions
  • http://YourWebServer/YourWebserviceFolder/mdt.asmx – For MDT related functions
  • http://YourWebServer/YourWebserviceFolder/sccm.asmx – for SCCM related functions.

Test a few functions and make sure it returns the data you expect.


There you go, you should now have a functioning web service to use with your deployments!



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