OSD, Domain Joining, and custom Unattend.xml

I think I have a use case that’s perhaps a bit unique. Several related problems that I think may have a common solution.

  1. Delaying Domain Join
    In my environment, when a client joins the Domain it gets certain domain-wide Group Policies applied, which include a logon warning banner and a requirement to log on with Smart Cards-only. So the AutoAdminLogon fails once the client is joined to the domain.

In the past with TPMfOSD, I used the “Join Domain On-site” option to delay the domain join until after Windows Setup had completed. The Domain Join would run as part of the GuiRunOnce script, during the last automated logon, and all was well.

When we moved to BigFix OSD, we had the same behavior, but it turns out this was only “by accident”. In the Image Profile dashboard, we had configured the domain join credential with the format “username”, not “domain\username”. During Windows Setup, this account is actually failing to join the domain (Windows Setup doesn’t seem smart enough to assume the domain name); but during GuiRunOnce, the Lite Touch scripts are translating the account to assume DOMAIN\username and the join is successful.

  1. Timing out Windows Setup’s Domain Join attempt, and possibly other Unattend.xml settings
    While Windows Setup is failing to join the domain, on our Windows 10 images this domain join is repeatedly attempted for 15 minutes before giving up. We can reduce that to 5 minutes if we set a <TimeoutPeriodInMinutes> in unattend.xml.

  2. Don’t attempt to join domain during Windows Setup
    While we can get that timeout down to 5 minutes, skipping the Domain Join during Windows Setup, and leaving that for LiteTouch to do later, would be ideal. From what I have read, MDT can accomplish that by leaving the unattend.xml set to <JoinWorkgroup> rather than <JoinDomain>; with the Domain setup and credentials still supplied by the Task Sequence, the “Recover from Domain” should still end up joining the domain after Windows Setup.


  • Can we specify custom Unattend.xml settings to use? Would we do this in the OS Resource, before capturing the image? If I added the TimeoutPeriodInMinutes value, will that be preserved?

  • Are there any stanzas of Unattend.xml that will be overwritten by BigFix OSD? I understand “Computername” is replaced, but I think that’s based on the same variable-replacement used by MDT. If I change the JoinDomain to JoinWorkgroup, will that be left in the target machine’s Unattend.xml (as I want it to be)?

To answer some of my own questions -

After creating an MDT Bundle, I can modify the unattend.xml files stored at “C:\BigFixOSD\MDTBundle\Content\Deploy\Control<OS>\unattend.xml”, and remove the entire “Microsoft-Windows-UnattendedJoin” component from each. This is preserved when I upload the modified bundle to the server.

This is used at Deployment time. This does not have to be modified before Capturing the image. The Captured Image actually does not have any unattend.xml within the WIM file at all.

When Deploying using this MDT Bundle, Windows Setup does not attempt to join the domain; after Windows Setup completes, and the AutoAdminLogon executes the ZTIBootStrap.vbs script, the Lite Touch process successfully joins the domain.

This meets my goals of joining the domain at the end of deployment. This domain join runs after the AutoAdminLogon, so the Domain Policies that enforce smart card logon and logon warning banners do not interfere with the deployment process. Removing the UnattendJoin from unattend.xml has shaved 15 minutes off of my deployment time (due to the credential I was using not working during Windows Setup, Windows 10 has a 15-minute retry period for joining the domain).

It looks like manipulating the unattend.xml could be used to add or modify any other settings.

Why not de-couple domain join from the MDT process altogether? That’s what we do. We have a separate task were the relevance can be tuned appropriately so it only joins when your criteria (remote location/subnet/preceding tasks) are met. It is easier to time local versus domain auto-logon as well.

In our join process, we also use relevance substitution to drop the machine into the correct OU for it function and geography. We also do autologon both pre and post domain join for various purposes.

We ran into the same issue with Windows attempting to join the domain, waiting 15 minutes for it to fail and then ultimately having MDT join the domain. IBM support seemed to indicate that the Windows domain join should NOT be occurring and that this was an issue that would be corrected in a future release. The work around they provided is as follows and resolved the issue for us using MDT bundle 3.9.01 and 3.9.04. This relates to bare metal builds.

  1. Make a backup copy of C:\BigFixOSD\MDTBundle\Content\Deploy\Scripts\ZTIConfigure.xml
  2. Edit C:\BigFixOSD\MDTBundle\Content\Deploy\Scripts\ZTIConfigure.xml and remove the following lines below, save the file, re-upload the MDT bundle and attach it to your bare metal profile.

NOTE: I had to add a space after every < in the posting below. If I didn’t add the spaces then the text between the <> brackets would NOT show up. As a result the text posted below won’t match exactly what’s in your ZTIConfigure.xml file. I’d suggest searching ZTIConfigure.xml for mapping id=“JoinDomain” as a starting point to get you to the appropriate location in the file. Hopefully this makes sense.

< mapping id=“JoinDomain” type=“xml”>
< xpath>< /xpath>
< remove>< /remove >
< /mapping>
< mapping id=“MachineObjectOU” type=“xml”>
< xpath removeIfBlank=“Self”>< /xpath>
< /mapping>
< mapping id=“JoinWorkgroup” type=“xml”>
< xpath>< /xpath>
< remove>< /remove>
< remove>< /remove>
< remove>< /remove>
< /mapping>
< mapping id=“DomainAdmin” type=“xml”>
< xpath>< /xpath>
< /mapping>
< mapping id=“DomainAdminDomain” type=“xml”>
< xpath>< /xpath>
< /mapping>
< mapping id=“DomainAdminPassword” type=“xml”>
< xpath>< /xpath>
< /mapping>