Move Computer Object during OSD

Hey there everyone,
Today I wanted to talk about an issue I have run into multiple times in working with ConfigMgr OS deployment (OSD) over the years and show you how through a fairly easy process you can overcome it!

The Problem:

You calculate the target OU of the machine you are imaging through CustomSettings.ini, User Driven Installation wizard, or any other method that sets the TS variable “MachineObjectOU”, however the computer object already exists in Active Directory in a different OU. As you have likely seen, this results in the MachineObjectOU variable being ignored and the computer simply rejoins to the existing object. If you are like me, you probably want your machine to be in the OU you specify in your deployment process.

DISCLAIMERS:

-This should be validated and tested in a Lab environment before moving it into production.
-Microsoft does not support ADSI in Windows PE.

A Solution:

Notice this is titled “A Solution”. There are many ways to accomplish this process, including using a Web Service. This is an alternative solution that may or may not fit your needs. 🙂

This solution is comprised of the following components:

-A delegated Service account
-ADSI Plugin for Windows PE
-PowerShell components for Windows PE
-PowerShell Scripts
-SCCM Collection Variables
-List of Domain Controllers
-SCCM Package
-Run Command Line Task in your Task Sequence

The Service Account

This account requires delegated permissions to the source and destination OU’s. I like to use the account I already have setup for joining machines to the domain that has the following rights delegated to the OU’s:

  • This object and all descendants
    • Create Computer objects
    • Delete Computer objects
  • Descendant Computer objects
    • Read all properties
    • Write all properties
    • Change password
    • Reset password
    • Validated write to DNS host name
    • Validated write to service principal

 

The ADSI Plugin

ADSI plugins for Windows PE are continually updated by our friend Johan Arwidmark and be can found here with installation instructions:
Windows PE 10
Windows PE 5
Windows PE 4

PowerShell components for Windows PE

Once you have your Windows PE updated with the ADSI plugin, you will also need to make sure you add PowerShell support to your boot image as well. This can done via the properties of your boot image in the ConfigMgr console.

1. Open the properties of your boot image.
2. Select the Optional Components tab.
3. Click the orange star to add additional components.
4. Select PowerShell.
WinPE-1
5. Click OK to accept additional components.
WinPE-2
6. Click OK again to save the changes.
WinPE-3
7. Update your boot image on your distribution points which will apply the new components to the boot image (and of course distribute the new image out to your DPs).

The Scripts

We are now ready to create a PowerShell script (2 actually) that you will turn into an SCCM Package. This package will be referenced in a “Run Command Line” Task in your Task Sequence.

Copy and Paste the scripts below into separate documents in Notepad, ISE, or whatever your favorite editor is. You can always replace the log script (Script 2) with your own. This one is about as basic as it gets. Please be mindful of word-wrap and adjust accordingly

Script 1: Move-ADObject.ps1

Script 2: WriteLog.ps1

The Collection Variables

Create 2 new collection variables for your delegated service account. At a minimum when setting the variable for the password, select “Not not show this value in the console”. This will ensure its not stored in clear text.

Variable Name: TSUSER, Value: DOMAIN\ServiceAccountName
Variable Name: TSPWD, Value: ServiceAccountPassword

Obvious I am sure however, change the values to match your service account and domain. 🙂

The DC’s

Edit Script 1 and modify $Global:DCArray = “MYDC01”, “MYDC02″,”MYDC03” to 3 (or more!) Domain controllers you want your script to attempt to talk to.

Each domain controller will be contacted in order. Once any of the DC’s respond the script will continue. I like to use 3, in various locations.

The SCCM Package

Create a new Package in SCCM that contains both script files. Do not create a program when prompted. Don’t forget to distribute the package to your DP’s 😉

The Task Sequence

Now that you have everything you need to perform the process, add a new Task in your Task Sequence before the State Restore phase (Prior to joining the domain) with the command:

Click the package check-box and select the new package containing the scripts.
TS

You are now ready to start testing.

As with any problem, there are numerous paths to victory. I find this one easy and painless and works like a charm. No more manually moving Computer objects! Automation is awesome.

By |2016-05-27T09:46:34+00:00May 17th, 2016|PowerShell, SCCM|0 Comments

About the Author:

Partner – Model Technology Solutions William is an experienced and results-driven IT geek who is passionate about the “automation of things,” with an extensive background in systems management, advanced OS deployment automation, and overall infrastructure automation. He has more than 19 years of experience in IT, and has designed and implemented management solutions that have dramatically reduced support costs and ultimately brought consistent and well managed operating environments to organizations across the US.

Model Technology

Let us help you get your end point and data center strategy on cruise control!  Ask about our Calibration Assessment.

CONTACT US

  • 12125 Woodcrest Executive Drive, Ste. 204 Creve Coeur, MO 63141
  • (314) 254-4138
  • sales@model-technology.com

RECENT TWEETS