Automatically determine target OU from Computername with powershell script for MDT 2012 U1 / ConfigMgr

In this post I describe how I use a powershell script to automate the domain join process in MDT/SCCM to the correct OU based on the comptername.

While installing operating systems, software and troubleshooting the installation processes are one of the things I really enjoy doing, it frustrates me when I see a poorly implemented environment. Our environment unfortunately is one of those, so I’ve spent quite some time in order to get to a point where it’s starting to become fun again.

The Hospital I currently work for has a lot of OU’s, every department has it’s own OU for workstations (114 OU’s just for workstations). Since we didn’t have an automated method to place the computer automatically in the correct OU during deployment, it always meant there was manual work required; either create the computer object in AD before installing Windows, or move the computer account afterwards from the computers container.

At least we have a simple enough naming standard for the workstations, which is built in the following method: “Division number”-“department abbreviation”-“last 2 digits of the year when PC was bought”-“4–digit number, starting with 0001 as first PC bought that year”. To give an example, My workstation would be 0–ICT-12–0011 (11’th PC bought for the IT department in 2012), and the computer object for that PC would need to be placed in the workstation OU for the ICT department. When I went to look for some ready to use scripts to determine the OU based on a computer name I only found a handful of vbscripts that generally used a predefined number of control characters, for example the first 2 letters of the PC name. This was not a viable option for me, since I need to actually do a three step check on the name to place the computer in the proper OU. The following process is that we need in our environment.

  • Lets take 0–ICT-12–0011 as example
  • Check the first 2 characters of the name, if this matches 0–,1–,2–,3–,4– or 5– then go to next step
  • Since the PC name starts with a digit matching a division, it then needs to find the correct department; in my case it now needs to match 0–ICT
  • Once it matches a division and department, it also needs to verify the last 4 digits of the name, if this starts with the letter “K” (we have a few more exceptions) it means it’s a kiosk/panel PC which have their own OU…
  • Based on the last 4 characters of the name, we can determine wether we need to be placed in the workstation OU for ICT, or in the Kiosk OU for Division 0, since the last 4 characters are 0011, it means it’s a WS.
  • If for some reason the name would not match all criteria’s, I defined a “NonCompliant” OU which will contain all computers that do not follow the default naming policy, example: If I made a mistake while typing in the computername during the import computer object in SCCM and named it 1–ICT-12–0011, it would then be placed in the NonCompliant OU, since ICT is a department part of division 0, and not division 1.

I figured powershell would be a good candidate to tackle this for me, since I’m a lot more comfortable with that than with vbscript. So I started to write my own script to follow the exact steps I described above, due to the large amount of different OU’s I needed to define I ended with a 664 lines long script (also due to my formatting, however I find this very easy to read), but I figured I might as well share this in a more compact version that shows just how I applied this logic if you happen to need something similar in your environment.

The functionality of this script is very simple, it will define the task sequence variable ‘MachineObjectOU’ based on the OSDComputerName variable using If, ElseIf and Else statements. It also dumps all TS variables before, and after setting the MachineObjectOU variable to a file named ZTIVariablesExport.log in regular SCCM/MDT log path.

The script can be downloaded from the TechNet Gallery where I’ve also posted a small snippet of the code I’ve used. It can be used in the following scenario’s:

MDT standalone:

  • When using Windows PE 4.0 images, with the powershell component you can execute this script at any stage before the “Configure” step in the [Preinstall] node of a task sequence.
  • When using Windows PE 3.0 you’ll need to configure the task sequence (or your custom settings) in such a way that it does not join the domain by updating the unattend.xml file during the “Configure” step, since this will actually join the computer to the domain during the windows installation. By letting it default to a workgroup, and then run the powershell script during the [State Restore] node in the task sequence prior to the step “Recover From Domain” the PC will be placed in the proper OU during this part of the domain join process.
  • The only drawback for placing computers in a particular OU using the MachineObjectOU variable in MDT is that if the computer object is already present in AD, it will not be moved. Instead the PC will still be joined to the domain but the object will remain at the same location that it was already in. While you can do this with scripts as well, I really like Maik Koster’s web service (link) for this (and other) functionality.

ConfigMgr with MDT:

  • With ConfigMgr, configure a default OU (our staging OU) in the “Apply Network Settings” step in the [PostInstall] node (or when using UDI, configure the Domain Settings in the UDI designer) and during the [State Restore] node add this powershell script which will configure the MachineObjectOU variable, then execute Maik Koster’s ZTI_ExecuteWebservice.wsf script to move the account from the staging OU to the destination OU.


Feedback is always appreciated


Kind regards,

Stephan Schwarz