Blog - Domain Policies that break MDT 2010

Location: Blogs Johan Arwidmark
Posted by: johan	7/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 - 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 2 - Postpone the domain join process I do like option 1 the best, but another solution is to postpone the domain join process. Here is a good article by Keith Garner that explains how to do this. http://deployment.xtremeconsulting.com/2009/12/08/new-for-mdt-2010-ztidomainjoin-wsf/ / Johan

Permalink \| Trackback

Comments (3)

Re: Domain Policies that break MDT 2010

By SX00237 on 8/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.

Re: Domain Policies that break MDT 2010	By Jodale on 8/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?

Re: Domain Policies that break MDT 2010	By johan on 8/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. /Johan