Domain Policies that break MDT 2010

By arwidmark / July 29, 2010

If you have certain domain policies, like renaming the administrator account or setting a legal disclaimer at login, those policies will break MDT 2010. Group Polciies that deploy application may also fail if they are executed when the task sequence is running.Here are some workarounds…


Option 1 – Use a Staging OU

Use a Web Service to move the computer account to a staging OU during deployment, and move it back to the production OU when deployment is completed. Maik Koster has a great post about that:

Option 2 – Prevent the Group Policy to apply as long as the deployment is running

I have seen quite many ways for this, all from creating additional variables to check for, to modifying the built-in script. The simplest solution I have found is simply to add a WMI filter to the Group Policy, so that it does not apply until the deployment is done.

The obvious way would be to check for the existenece of the C:\_SMSTaskSequence folder, but due to the way WMI filter works (or rather not works) it’s better to check for the existence of the C:\Windows\Temp\DeploymentLogs folder. That folder is not created until deployment is completed.

Create thw following WMI Filter and link it to the Group Policy

Select * From CIM_Directory Where Name = ‘C:\\Windows\\Temp\\DeploymentLogs’

Note: Make sure that you don’t have such folder in the wim you are deploying…

Option 3 – Postpone the domain join process

I do like option 1 the best, but yet another solution is to postpone the domain join process. Here is a good article by Keith Garner that explains how to do this.

/ Johan

About the author


RoBL - August 16, 2010

Option 3 – Delaying Domain Join to Avoid Application of Group Policy Objects (Help file MS MDT2010)

Group Policy is a rich and flexible technology providing the capability to efficiently manage a large number of Active Directory Domain Services (AD DS) computer and user objects through a centralized, one-to-many model. Group Policy settings are contained in a Group Policy object (GPO) and linked to one or more AD DS service containers— sites, domains, and organizational units (OUs).

Some organizations have Group Policy settings that are very restrictive and that could cause problems during operating system deployments. For example, the following Group Policy settings can interrupt an automated logon process:

· Autologon restrictions

· Administrator account renaming

· Legal banners and captions

· Restrictive security policies (for example, the Specialized Security – Limited Functionality [SSLF] policy)

One option to overcome the issues that a GPO might cause during deployment is to join the computer to the domain as late as possible in the deployment process. This join can be done using a custom task sequence step that runs the ZTIDomainJoin.wsf script.

To join the target computer to the domain, the ZTIDomainJoin.wsf script uses the DomainAdmin, DomainAdminDomain, DomainAdminPassword, JoinDomain, and MachineObjectOU properties. You can declare these properties using the Windows Deployment Wizard, deployment share rules, the MDT DB, and System Center Configuration Manager computer and collection rules. The account used must have the rights required to create and delete computer objects in the domain.

Typically, the ZTIConfigure.wsf script updates the Unattend.xml or Unattend.txt file with the values that these properties specify. These settings are then parsed by the Windows Setup program, and the system attempts to join to the domain early in the deployment process. Doing so subjects the target computer to settings specified in domain GPOs and can possibly cause the deployment process to fail.

To intentionally delay joining the target computer to the domain during the deployment process, you can remove certain elements from the Unattend.xml file. The ZTIConfigure.wsf script will skip over writing properties to the Unattend.xml file if the associated property element is missing from the file.

Note This sample work-around is only valid when deploying the Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 operating systems.

Prepare the unattend.xml file so the target computer does not attempt to join the domain during Windows Setup

1. Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench.

2. In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares/deployment_share/Task Sequences/task_sequence (where deployment_share is the name of the deployment share and task_sequence is the name of the task sequence to be configured).

3. In the Actions pane, click Properties.

4. On the OS Info tab, click Edit Unattend.xml.

The Windows System Image Manager (Windows SIM) starts.

5. In the Answer File pane, go to 4 specialize/Identification/Credentials. Right-click Credentials, and then click Delete.

6. Click Yes.

7. Save the answer file, and then exit Windows SIM.

8. Click OK on the task sequence Properties dialog box.

With the Credentials elements missing from the unattend.xml file, the ZTIConfigure.wsf script is not able to populate the domain join information in the Unattend.xml file, which will prevent Windows Setup from attempting to join the domain.

To add a task sequence step that joins the target computer to the domain

1. Click Start, and then point to All Programs. Point to Microsoft Deployment Toolkit, and then click Deployment Workbench.

2. In the Deployment Workbench console tree, go to Deployment Workbench/Deployment Shares/deployment_share/Task Sequences/task_sequence (where deployment_share is the name of the deployment share and task_sequence is the name of the task sequence to be configured).

3. In the Actions pane, click Properties.

4. On the Task Sequence tab, go to and expand the State Restore node.

5. Verify that the Recover From Domain task sequence step is present. If yes, proceed to step 9.

6. In the task sequence Properties dialog box, click Add, go to Settings, and click Recover From Domain.

7. Add the Recover From Domain task sequence step to the task sequence editor. Verify that the step is in the desired location in the task sequence.

8. Verify that the settings for the Recover From Domain task sequence step are configured to meet your needs.

9. Click OK on the task sequence Properties dialog box to save the task sequence.

Joseph - August 24, 2010

Not really a Domain Policy but how do you get MDT 2010 to automatically rename computers based on previous entry into Active Directory via GUID, like RIS does?

arwidmark - August 24, 2010

The best way is to create a webservice for that. Niehaus put an example up a while back which is a good starting point.


sj3ff0rds - March 9, 2011

If using Option #1 will that disable the GPO for the existing computers on the domain without the DeploymentLogs folder in windowstemp? In other words I am testing opt 1 and it worked fairly well however I am noticing wierd things with machines that were already on the domain (IE. not locking after time out, no disclaimer, etc…)

Any assistance or guidence would be appreciated.

arwidmark - April 20, 2011

Check Eventviewer (windows7) to see if a policy was filtered out or not.

/ Johan

Ogeccut - April 22, 2011

I am having a problem with the build in MDT functionality to join a domain. It stops on a legal disclaimer and by clicking OK i am able to resume the TS. When i try the method above i am no longer prompted to click OK to continue and workstation joins the domain however to AD has to entry for the workstation. So i have to join the workgroup and back to the domain manually.
I tried using ZTIDomainJoin.wsf and the DomainOUList.xml in the control folder at the end of the TS and before the bitlocker but not able to join the domain this way.
Is there a way to pass domain and OU information on a command line to ZTIDomainJoin.wsf?
Thank you.

Ogeccut - April 25, 2011

With deleted specialize/Identification/Credentials from Unattend.xmland joining domain with ZTIDomainJoin.wsf or with “Recover From Domain”.

When i try to log in to the domain i am getting “The security database on the server does not have a computer account for this workstation trust relationship.”

arwidmark - April 25, 2011

Check the netsetup.log (C:WindowsDebug on the client) to see any domain join issues…

Shawn - August 16, 2011

I tried te steps above and seemed to run into issues. After a lot of searching I found the following blog and have not been tormented by the dreaded legal disclaimer or admin rename.

arwidmark - August 20, 2011

Sorry to hear it did not work for you, but I’m glad you found a solution and thanks for posting it here…

/ Johan

goof1427 - August 27, 2011

this is a great article but I am stuck… I am trying to do the following..rename the administrator and we also have a legal banner. so what happens is that the Z drive share remains and a couple of the folders like MINI and _SMSTask…. I have been searchin for a solution for a few days now and I found this site and a couple others where I found a way to delete the Z drive. But I was wondering if this will cause issues in the future since the deployment didnt fully complete.
I tried the link that SJ3ff sent but I am not having any luck wiith that.

And I just found this link where Johan wrote a cleanup script however how does that run with the banner and admin rename?

arwidmark - September 2, 2011

Alright, so the best workaround I have seen so far, is to use a staging OU (with no policies), and the move the AD object to correct OU (with the policies) at the end of the task sequence.

Check this article/solution by Maik Koster

Comments are closed