New for MDT 2010: ZTIDomainJoin.wsf December 8, 2009
Posted by keithga in MDT 2010, VBscript.trackback
One of the new scripts for MDT 2010 is the ZTIDomainJoin.wsf script. This script will operate like NetDom.exe, Joining the machine to the Domain specified in the customsettings.ini and/or Deployment Wizard.
Normal Process
Before MDT 2010, the variables collected in the wizard for joining the domain were placed directly into the unattend.xml or unattend.txt file. The OS would then perform the join to the domain during (OOBE) Setup.
This tool came about because of several scenarios that could prevent the machine from successfully joining the domain during Windows Setup. For example. If the network did not have DHCP available, Windows Setup is not programmed with the correct Static IP address settings necessary for the Join Domain feature to contact the domain controller. Later on in the Task Sequence Steps, the ZTINICConfig.wsf script would correctly configure the Network Cards, however it was too late for joining the domain.
So we developed a new script ZTIDomainJoin.wsf as a thin wrapper around the WMI call Win32_ComputerSystem:JoinDomainOrWorkgroup(). If the script sees that the machine is already joined to the correct domain, no problem, it continues on, without any errors. However, if the script sees that a request was made to join the domain, and the machine is *not* in that correct domain, then it will attempt to join the domain and reboot. If there is a failure joining the domain, the script will retry up to 3 times before logging a failure and continuing.
Domain Policies that break MDT
Another scenario where this script works well is when a Domain has a Policy that blocks automation. For example a Legal disclaimer at login, or a rename of the local Administrator Account. Either one of these changes will break MDT.
One possible work around in these scenarios is to *remove* the domain join entries in the unattend.xml and unattend.txt templates on your MDT server, or remove the entries in the ZTIConfigure.xml script. Once removed, the ZTIConfigure.wsf script won’t populate the unattend.txt with the correct variables gathered form the CustomSettings.ini file and/or Deployment Wizard.
Then add the ZTIDomainJoin.wsf script near the *end* of the Deployment Task Sequence. Most of the automation will be complete by that point.
Variables
It takes the following variables:
- JoinDomain – Name of domain to join
- DomainAdmin – User Account used to Join Domain (must have permissions to perform Domain Join)
- DomainAdminDomain – Domain of User account used to Join Domain
- DomainAdminPassword – Password used to Join Domain
- MachineObjectOU – Domain OU to join
- DomainErrorRecovery – [Auto|MANUAL|FAIL]
- Auto – Automatically try to Join to the domain, reboot and retry if there is a failure.
- Manual – Stop processing the Task Sequence, and wait for the user to manually join the domain.
- Fail – Stop the Task Sequence if the machine has not joined the domain.
Notes
Fail could be useful if you have applications that *require* the machine to be part of the domain. If for any reason, the machine failed to join the domain, you could call the ZTIDomainJoin.wsf script with the “Fail” Parameter to crash the installation process if the machine is not joined to the domain.
Manual style is a new feature in MDT 2010, where MDT can “Halt” the execution of the Task Sequence, and allow the user the ability to perform manual steps (without the pesky Task Sequence progress bar, which insists that it remain on “top”). Just follow the instructions to restart the task sequence.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting Group
Hi Keith,
Using the ZTIDomainJoin.wsf and the “MachineObjectOU” variable, would this be the correct syntax to define the OU to join?
MachineObjectOU=OU=Two,OU=One,DC=CompanyA,DC=Com
In Netdom.exe, it uses this syntax:
“/ou:OU=Two,OU=One,DC=CompanyA,DC=Com”.
Thanks,
Roy
Yes, good catch, I forgot to meniton MachineObjectOU, and yes you are using the correct syntax!
Thanks!
I thought unattend.txt was only use to guide an install from the CD source files and sysprep.inf was used for the mini-setup values from a reference machine restore (from image). I’m confused about when sysprep.inf/unattend/custom settings/machines details/roles details come in where. Then you find three or more sysrpeps and unattends and WHAM I’m spinning.
Where is ZTIDomainJoin.wsf pulling its variables from? From the command line in the task sequence? From values in the machine/role/custom settings rules? I think I’m reading custom settings but I didn’t know variables like DomainErrorRecovery was available in there.
I keep getting everying running like a top.. then I have to modify something and the house of cards comes down again
I’m going to hammer this out eventually. So many moving parts!
ZTIDomainJoin is pulling the variables from the wizard values that you populated when you started the deployment process or from variables in the customsettings.ini.
The unattend.txt file would be used for a complete deployment if you were installing XP from source files. When you capture the image, it uses sysprep.inf. When the image is deployed the sysprep.inf in the image is used and updated with variables from the deployment.
keithga – Thank you so much for this help! I am new to MDT and this is my first deployment for a large company. I allso struggle for days with the GPO that renamed the local admin account. I removed the Domain Join Entries from the ZTIConfigure.xml script, and it is now not jouning the Domain at the beginning. I want to join a workgroup at that point, which is correct. What do I have to do to have to workgroup name auto filled in and continue without my interaction at that stage?
Your help is much apreciated!!!
Eben,
(Sorry about the delay in responding)…
Yes, if you do nothing at the start of the MDT installation process, the machine will automatically be joined to a Workgroup. YOu can then add the ZTIDomainJoin.wsf script at the *end* of the MDT installation process, just before the final reboot, that should be good.
Hi,
I’ve got a strange problem using SCCM and MDT 2010, the domian join always works, but sometimes the machine account ends up in the default OU instead of the one specified in the Task Sequence step. It only happens very occasionaly, and there’s nothing of use in the NetSetup.log file as the actual domain join has been successful. Can anyone provide any ideas of where to look next?
Thanks.
One thing to check to see is if the machine existed in that container already before the domain join. When you are joining a machine to the domain that already exists in the domain it will always stay in the OU or container that it was originally part of.
Can u post detailed instructions on how to deploy using the refresh/replace and unattendjoin method that have static IP assigned to the hosts?
I have been successful at getting the task sequence to capture the current hosts network configurations and applying them to the litetouch PE so it can connect to the deployment share, but I can’t get LitetouchPE to pass the network settings after it has deployed the OS (windows 7 ) but before it tries to join the domain. Obviously it will fail and once I manually insert the the correct network configurations, and start the litetouch.wsf sequence again it will contiune the rest of the process and finish the deployment…but now I must join the computer to the domain myself. Any ideas?
Hi Keith,
Just after some advice here – I want to use ztiwindowsupdate.wsf to install all approved updates from a WSUS server, however due to domain policy windows updates are disabled (We’re still using SMS for workstation patching)…therefore script fails.
Unfortunately my application installations are running from a dfs share on the network so I’m not sure how well authentication is going to go without the machine being on the domain prior to application installation.
Is there any way you can think of that I can structure my task sequence in such a way as to 1) Pull Windows Updates from WSUS, 2) Join Domain using ztidomainjoin.wsf and 3) Install Applications.
I’m aware though that there is a post application installation Windows Update task be default in the sequence, but I’d like to think that I would receive most windows updates with just the one task?
Any ideas you might have would be greatly appreciated.
Cheers,
Joseph
Hi,
I have a similar problem where automatic domamin breaks MDT (because we have a GPO in place to deploy SCCM Client). I am trying to use the method you mentioned above but I have some confusions regarding your instructions
So I remove the domain join entries in CS.ini;
add a TS (ZTIDomainjoin.wsf) to the “end” of deployment;
where I put those “Variables”?
Thanks,
[...] blog talks about the workaround for scenario like this, I followed the instruction [...]
how to edit Unattend.xml to remove the join domain ?