Archive for the ConfigMgr 2012 Category

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

While working with my ConfigMgr 2012 lab environment, I figured why not take a look at the new mobile device management capabilities. This would provide me the option to manage mobile devices from within ConfigMgr instead of managing these through Exchange.

When I first tried to configure this setting, I couldn’t get it to work properly since I didn’t entirely know which rights I should give to this new user account that I created for this connector. After trying a couple of combinations, I got it to work; however this was a way to over-privileged account which is far from the desired result. So I began searching again, and found a script on the TechNet Gallery created by the Exchange Team, which created a role group and management roles within Exchange and then adds a user to it, for the Windows Intune Exchange Connector. This was very close to what I was looking for, however Windows Intune requires access to more cmdlets than ConfigMgr does. So I edited the script slightly to reflect the names used for the role group and the management roles for ConfigMgr usage and removed the unnecessary cmdlets. The result is that the user account that will be added to this role group, now only has the minimum rights as needed to perform the device management features from within ConfigMgr 2012.

 

I’ve uploaded the modified version of this script onto the TechNet library, which you can find at the following location: link.

As for how to configure the Exchange Connector within the ConfigMgr 2012 Console, you can add these from the Administration View > Hierarchy Configuration > Exchange Server Connectors.

  • Click “Add Exchange Server”
  • Specify a CAS server in the format: http://fqdn
  • Click next.
  • For the user account to be used, specify an account to connect to the Exchange Server
  • If you have not already added an account within the Security > Accounts section, you’ll have to add a new account. This account needs to be the same account that was used when executing the script to provision it with the proper user rights.
  • Click next, configure the discovery settings if applicable, then configure the group settings for device management (these pages can be accessed at a later time again by opening the properties of the Exchange Connector).
  • After pressing next at the summary screen, the process will start and add the connector to the management console.

 

I hope you found this as useful as I did, since it will save me a lot of time anytime I will need to configure this for a lab or demo environment.

Kind regards,

Stephan Schwarz