Setting the Computer Description in Active Directory during MDT Deployments
A quite common question I got so far is how one would be able to set or update the computer description in Active Directory during the Deployment or maybe also later using a logon script. I personally like to store some additional information about the computer itself in the description property like Asset Tag/Service Tag or the Date of the initial or latest build, the last logged on user, etc. This way this information is available for everybody using the Active Directory Users and Computers snap in or one can use tools like the logparser or AdFind to query for specific information.
There are actually a lot of ways how to achieve this. You can use command line tools like dsmod or script everything in vbscript and a lot more. Powershell would also be a very good choice for this but as long as it is not available in WinPE it will only be second choice. As I like command line tools and custom scripts for all the stuff which vary often, I like to have common or often used scenarios implemented as easy as possible. Especially during Deployments and when running scripts in System context I prefer to use webservices. I don’t need to take care about the specifics of the local computer (32/64 Bit, Server, Old client OS, logged on user, etc). All it requires is to be able to make an http request. And with Version 6 of the Deployment Webservice you now got the possibility to set and read the computer description.
OK, let’s start.
Get the computer description
The first thing we need is the computer Description itself. Generally there are three ways to get it. Manual, automatic or a combination of them. Actually the MDT wizard does already contain the necessary bits to be able to let the user manually enter a computer description. If you just open the DeployWiz_Definition_ENU.xml file and search for Computer Description you should end up at line 328 in MDT 2010 (or line 208 in MDT 2008). There you will see a part to enter a Computer Description which has been commented out on default. So if you would like to make this available just remove the “<!–“ and the following “–>” . Now if you run the wizard it will show the Computer Description field on the same pane where you normally enter the computer name. Also the built-in scripts will make sure that the computer description is now populated into a property called “Description” which can be used during the rest of the Deployment
The easiest automatic way is to use the Set Task Sequence Variable step in a Task Sequence. To e.g. use the SerialNumber as Description (hey, this is just an example) you could create a Step like this:
If you need to have a more complex Description defined automatically, you most probably want to use a custom script to generate it. Let’s assume you want to store the Serial Number and the current Date in the Description. You could now create a small custom script which would do this for you. The function could look like
sDescription = "SN=" & oEnvironment.item("SerialNumber")
sDescription = sDescription & " - BuiltDate=" & Date
'Store Description for future processing
oEnvironment.Item("Description") = sDescription
Now you can add and execute this script at any point in your Task Sequence (preferably after the gather step and before you finally update the description in AD 😉 )
What you exactly need to store in the description and how you create it totally depends on your local needs. This shall just give you an idea on how to do it.
Set Computer Description in Active Directory
Ok, we now have created the computer description. Time to get this information into Active Directory. In this example we will use a small script which will call the webservice function and submit the description. The information on how to reach the webservice is stored in the customsettings.ini. So let’s start with the customsettings.ini. We need to have a new section in there called “[SetComputerDescription]” (replace YourWebServer/DeploymentWebservice with the path to the webservice in your environment. I assume you already set up the Deployment Webservice and verified it is working):
Now we create a small script that executes the webservice based on the information in this section. The main part looks like:
' Create the web service instance
Set oService = New WebService
oService.iniFile = "customsettings.ini"
oService.SectionName = "SetComputerDescription"
' Make the web service call
Set oXML = oService.Query
If oXML Is Nothing Then
oLogging.CreateEntry "Unable to call SetComputerDescription web service.", LogTypeWarning
oXML.setProperty "SelectionNamespaces", ""
If UCase(oXML.SelectSingleNode("mk:boolean").Text) = "TRUE" Then
oLogging.CreateEntry "Computer Description has been set.", LogTypeInfo
iRetVal = Success
Now we add a new “Run Command Line” step to our TaskSequence that executes this script. It should be within the “State Restore” phase of the Task Sequence. If you are running MDT 2010 preferably after the “Recover from Domain” step as your computer might not have joined the domain yet so it could become hard setting the description ;-). The webservice will take care about that it connects to the local Domain Controller of the machine calling the webservice as the new account might not be available on all Domain Controllers yet, depending on how much time it had to replicated after joining the domain.
OK, that’s it actually. Your are now able to set the computer description during a deployment. For your convenience all example scripts can be downloaded from CodePlex. All you need is putting them into your Scripts folder, update the customsettings.ini with the section described above and add the necessary steps to your Task Sequence. If you would like to write (or read) other properties from Active Directory, get back to this blog regularly as a step-by-step guide on extending the webservice for additional properties is coming soon.
[…] almost entirely the work of their respective posters. MaikKoster’s blog provided information on setting the computer description in AD via a web service, which I’m sure works well but seemed overly complicated for our needs. Johan Arwidmark’s blog […]