New for MDT 2010: ZTIDomainJoin.wsf December 8, 2009

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.

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.

Share this:

Like this:

Related

I keep receiving a bad username or password error. I’ve tried two accounts, same error (and it will eventually lock the account). I’ve moved a custom task to the bottom the ts and have it run the ZTIDomainJoin.wsf, I’ve set the domain and account information in the cs.ini file. Is there somewhere else where the script is pulling the credentials from? Should I be setting the details it needs somewhere other than the cs.ini file?

Hey all, A few questions on this one. I ware many hats here and my experiences is limited with MDT not non existent just limited.

After a number of changes things on our network are happening much faster SCCM and GPOs are causing my image to fail or hang some of the time. I need to move the join domain to the end of the image process.

If someone has some instructions or could show me exactly what lines I need to remove to make this happen I would be most appreciated.

I made two or three attempts to do this myself but I have failed. I edited CS.ini to remove the domain stuff moved the recovery TS to the end but it never gets their it fails stating it cant pass credentials. I would like to have the Join Domain piece stay automated just happen as the last TS or just before the last TS.

Hi
I’ve moved “Recover From Domain” as the very last action and this does work as expected however an automatic reboot is still performed after this just before the deployment process is completed and final summary is displayed. Because the domain has been joined with GPOs already applied to the computer (Refresh of existing computers) the initial problem where autologon still attempts to logon as the domain administrator rather than local occurs and so doesn’t automatically finish the deployment.

Am I missing something? Should I be adding the ZTIDomainJoin script at the end instead of the “Recover from domain” action?

I use the Recover from domain as basically the last step before the final dialog box comes up, but since the recover from domain script reboots, I still ocassionally run into the policies taking affect and depending on OU changing the admin name or requiring manual login of .\administrator. Is there anyway to suppress the reboot and just have litetouch finish up? I get the legal notice the majority of the time anyway after reboot, so its one manual step regardless if I do a manual reboot myself at the end to apply the domain join.

Hope you are well? The above worked for my Windows XP deployment with MDT 2010. However, I tried the same now with MDT 2010 update 1 and Windows 7, and I’m again strugling with the GPO that break my auto logon in MDT? Any help or advice would be much apreciated.

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”?

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?

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,
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.

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.

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?

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.

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!