Today’s topic is about the following new computer scenario with SCCM 2012 R2 and specifically, an MDT 2013 integrated Task Sequence:
Lets begin.
Scenario: You set the ‘MachineObjectOU’ variable correctly in CustomSettings.ini (you know because you have triple checked your syntax!), yet it is ignored during a Task Sequence Deployment, joining to the Computers container instead.
In this example we are using a Hyper-V VM. Below is the CustomSettings.ini, which resolves to the [VM-True] section, setting MachineObjectOU to the Desktop OU.
We can see it being logged in ZTIGather.log:
However… the computer always joins the domain in the Computers container. This is of course unless an existing computer object resides in an OU already, making the point of this post null and void. 😛
We can see when looking at NetSetup.log that the OU Value is NULL during domain join, resulting in the Computers container dilemma. 😉
If you’re like me you might be thinking permissions? Lets go check our domain join service account permissions..
As we can see the account has the required permissions (ensuring as well there wasn’t a deny acl afoot!).
Everything sure seems like it should be working?!
Take a deep breath and look to your Task Sequence for guidance…
In the Apply Network Settings step, located in the Post Install phase, are the settings that we are prompted for during the Task Sequence creation Wizard.
If we elected not to assign an OU, the value will be blank.
In reality, you need to have something there.
In this example I will intentionally select the Laptops OU, knowing that my VM will be set to the Desktops OU via CustomSettings.ini to demonstrate that once a value is set, MachineObjectOU will override it.
We then delete the computer from Active Directory to avoid joining right back to the object sitting in the Computers container, and initiate another PXE rebuild.
Upon completion we see the VM joins the computer to the Desktops OU as instructed.
Sometimes it’s the small things that give us a sigh of sweet victory.
