Written by Famous first words of a consultant: “I had a strange issue at a customer”.
The customer had the well known message box during logon. You know the message the states that you are not allowed to logon if you are not a authorized user and so on.(legal disclaimer).
So I have read that this will break MDT. I first read about it in Johan Arwidmarks blog (this guy has seen it all). This article here:
http://www.deployvista.com/Blog/JohanArwidmark/tabid/78/EntryID/147/language/en-US/Default.aspx
It suggested 2 workarounds. One is to enable WMI queries on the group policy object that has the logon message box setting. This was not an option in my scenario. So I choose to go for option number 2. Postpone the domain join process. Johan referred to a blog article by Keith Garner (on of the MDT developers). This one:
http://deployment.xtremeconsulting.com/2009/12/08/new-for-mdt-2010-ztidomainjoin-wsf/
This article states that you should remove DomainJoin settings in the zticonfigure.xml (or the unattend.xml and unattend.txt). So I removed the settings from the zticonfigure.xml. I did a search and delete for these variables in the XML file:
- JoinDomain
- DomainAdmin
- DomainAdminDomain
- DomainAdminPassword
- MachineObjectOU
The next thing I did was to remove these variables from the customsettings.ini file. And I added the following command directly in the Task sequence in the very end:
cscript.exe "%SCRIPTROOT%ZTIDomainJoin.wsf " /JoinDomain:childdomain.customer.int /DomainAdmin:mdt-joinaccount /DomainAdminDomain:childdomain.customer.int /DomainAdminPassword:SoNowYouKnowThePasswordToMyCustomer /DomainErrorRecovery:Auto /MachineObjectOU:OU=Workstations Standard,OU=Arendal,DC=childdomain,DC=customer,DC=int
Well I actually added this command twice in the task sequence. One for laptops and one for desktops. With conditions of course (isLaptop, isDesktop). I also disabled the default step “Recover from the Domain”. After all of this I was ready to test a deployment and see if the computer was actually joined to the domain. After 15 minutes I was ready to check the results. What….Not in the domain..But But….. Okay, log checking time.
I started checking out the netsetup.log. It stated:
NetpDoDomainJoin: status: 0x534
I converted this to Hex by using this command: set /a c=0x534
The command returned 1332.
I the asked net helpmsg for help with this command:
Net helpmsg 1332
It stated:
No mapping between account names and security IDs was done.
Okay that’s strange. There is no machine object in the domain with this computer name. I looked at the ztidomainjoin.log file also and it said that there is probably a machine account already in a different OU.
Just to be sure I did a search in Active Directory….No machine account.
The next thing I did was to check google. I stumbled over this one:
http://social.technet.microsoft.com/Forums/en-US/mdt/thread/152aba62-5442-45d6-a626-7454838d5dd5
okay, no direct solution. But what I noticed was the discussion about if there should be “ “ in the MachineObjectOU. I then came to think about the OU structure at my customer.
OU=Workstations Standard,OU=Arendal,DC=childdomain,DC=customer,DC=int
Yeah. There is a space in the Workstations Standard OU. And since I have done my part of VBscripting I know that this could easily be an issue. So I changed the command to this:
cscript.exe "%SCRIPTROOT%ZTIDomainJoin.wsf " /JoinDomain:childdomain.customer.int /DomainAdmin:mdt-joinaccount /DomainAdminDomain:childdomain.customer.int /DomainAdminPassword:SoNowYouKnowThePasswordToMyCustomer /DomainErrorRecovery:Auto /MachineObjectOU:"OU=Workstations Standard,OU=Arendal,DC=childdomain,DC=customer,DC=int"
And voila. It worked. So this is probably a bug in the ZTIDomainJoin.wsf script. If you are very observant you can see in the ZTIDomainJoin.log that it says MachineObjectOU=Workstations and not the whole path as it should. I will check if this is resolved in MDT 2012 and make a new post then.