Archive

Archive for December 13th, 2011

Dfsrmig: Migrating SYSVOL replication from File Replication Service (FRS) to Distributed File System (DFS) Replication

December 13th, 2011 No comments

Applies To: Windows Server 2008, Windows Server 2008 R2

The dfsrmig command migrates SYSVOL replication from File Replication Service (FRS) to Distributed File System (DFS) Replication, provides information about the progress of the migration, and modifies Active Directory Domain Services (AD DS) objects to support the migration.

For examples of how to use this command, see the Examples section later in this document.

Syntax

Copy Code

dfsrmig [/SetGlobalState <state> | /GetGlobalState | /GetMigrationState | /CreateGlobalObjects |

/DeleteRoNtfrsMember [<read_only_domain_controller_name>] | /DeleteRoDfsrMember [<read_only_domain_controller_name>] | /?]

Parameters

Parameter

Description

/SetGlobalState <state>

Sets the desired global migration state for the domain to the state that corresponds to the value specified by state.

To proceed through the migration or the rollback processes, use this command to cycle through the valid states. This option enables you to initiate and control the migration process by setting the global migration state in AD DS on the PDC emulator. If the PDC emulator is not available, this command fails.

For information about the states for migration and rollback, see SYSVOL Migration States. You can only set the global migration state to a stable state. The valid values for state, therefore, are 0 for the Start state, 1 for the Prepared state, 2 for the Redirected state, and 3 for the Eliminated state.

Migration to the Eliminated state is irreversible and rollback from that state is not possible, so use a value of 3 for state only when you are fully committed to using DFS Replication for SYSVOL replication.

/GetGlobalState

Retrieves the current global migration state for the domain from the local copy of the AD DS database, when run on the PDC emulator.

Use this option to confirm that you set the correct global migration state. Only stable migration states can be global migration states, so the results that the dfsrmig command reports with the /GetGlobalState option correspond to the states you can set with the /SetGlobalState option.

You should run the dfsrmig command with the /GetGlobalState option only on the PDC emulator. Active Directory replication replicates the global state to the other domain controllers in the domain, but replication latencies can cause inconsistencies if you run the dfsrmig command with the /GetGlobalState option on a domain controller other than the PDC emulator. To check the local migration status of a domain controller other than the PDC emulator, use the /GetMigrationState option instead.

/GetMigrationState

Retrieves the current local migration state for all domain controllers in the domain, and determines whether those local states match the current global migration state.

Use this option to determine if all domain controllers have reached the global migration state. The output of the dsfrmig command when you use the /GetMigrationState option indicates whether or not migration to the current global state is complete, and it lists the local migration state for any domain controllers that have not reached the current global migration state. Local migration state for domain controllers can include transition states for domain controllers that have not reached the current global migration state.

/CreateGlobalObjects

Creates the global objects and settings in AD DS that DFS Replication uses.

You should not need to use this option during a normal migration process, because the DFS Replication service automatically creates these AD DS objects and settings during the migration from the Start state to the Prepared state. Use this option to manually create these objects and settings in the following situations:

· A new read-only domain controller is promoted during migration. The DFS Replication service automatically creates the AD DS objects and settings for DFS Replication during the migration from the Start state to the Prepared state. If a new read-only domain controller is promoted in the domain after this transition, but before migration to the Eliminated state, then the objects that correspond to the newly activated read-only domain controller are not created in AD DS causing replication and migration to fail.

· In this case, you can run the dfsrmig command with the /CreateGlobalObjects option to manually create the objects on any read-only domain controllers that do not already have them. Running this command does not affect the domain controllers that already have the objects and settings for the DFS Replication service.

· The global settings for the DFS Replication service are missing or were deleted. If these settings are missing for a particular domain controller, migration from the Start state to the Prepared state stalls at the Preparing transition state for the domain controller. In this case, you can use the dfsrmig command with the /CreateGlobalObjects option to manually create the settings.

clip_image001Note

Because the global AD DS settings for the DFS Replication service for a read-only domain controller are created on the PDC emulator, these settings need to replicate to the read-only domain controller from the PDC emulator before the DFS Replication service on the read-only domain controller can use these settings. Because of Active Directory replication latencies, this replication can take some time to occur.

/DeleteRoNtfrsMember [<read_only_domain_controller_name>]

Deletes the global AD DS settings for FRS replication that correspond to the specified read-only domain controller, or deletes the global AD DS settings for FRS replication for all read-only domain controllers if no value is specified for read_only_domain_controller_name.

You should not need to use this option during a normal migration process, because the DFS Replication service automatically deletes these AD D
S settings during the migration from the Redirected state to the Eliminated state. Because read-only domain controllers cannot delete these settings from AD DS, the PDC emulator performs this operation, and the changes eventually replicate to the read-only domain controllers after the applicable latencies for Active Directory replication.

You use this option to manually delete the AD DS settings only when the automatic deletion fails on a read-only domain controller and stalls the read-only domain controller for a long time during the migration from the Redirected state to the Eliminated state.

/DeleteRoDfsrMember [<read_only_domain_controller_name>]

Deletes the global AD DS settings for DFS Replication that correspond to the specified read-only domain controller, or deletes the global AD DS settings for DFS Replication for all read-only domain controllers if no value is specified for read_only_domain_controller_name.

Use this option to manually delete the AD DS settings only when the automatic deletion fails on a read-only domain controller and stalls the read-only domain controller for a long time when rolling back the migration from the Prepared state to the Start state.

/?

Displays Help at the command prompt. Equivalent to running dfsrmig without any options.

Remarks

  • Dfsrmig.exe, the migration tool for the DFS Replication service, is installed with the DFS Replication service.
    For a new Windows Server 2008 server, Dcpromo.exe installs and starts the DFS Replication service when you promote the computer to a domain controller. When you upgrade a server from Windows Server 2003 to Windows Server 2008, the upgrade process installs and starts the DFS Replication service. You do not need to install the DFS Replication role service to have the DFS Replication service installed and started.
  • The dfsrmig tool is supported only on domain controllers that run at the Windows Server 2008 domain functional level, because SYSVOL migration from FRS to DFS Replication is only possible on domain controllers that operate at the Windows Server 2008 domain functional level.
  • You can run the dfsrmig command on any domain controller, but operations that create or manipulate AD DS objects are only allowed on read-write capable domain controllers (not on read-only domain controllers).
  • Running dfsrmig without any options displays Help at the command prompt.

Examples

To set the global migration state to prepared (1) and initiate migration to or rollback from the Prepared state, type:

Copy Code

dfsrmig /SetGlobalState 1

To set the global migration state to start (0) and initiate rollback to the Start state, type:

Copy Code

dfsrmig /SetGlobalState 0

To display the global migration state, type:

Copy Code

dfsrmig /GetGlobalState

This example shows typical output from the dfsrmig /GetGlobalState command.

Copy Code

Current DFSR global state: ‘Prepared’

Succeeded.

To display the information about whether the local migration states on all of the domain controllers match the global migration state and the local migration states for any domain controllers where the local state does not match the global state, type:

Copy Code

dfsrmig /GetMigrationState

This example shows typical output from the dfsrmig /GetMigrationState command when the local migration states on all of the domain controllers match the global migration state.

Copy Code

All Domain Controllers have migrated successfully to Global state (‘Prepared’).

Migration has reached a consistent state on all Domain Controllers.

Succeeded.

This example shows typical output from the dfsrmig /GetMigrationState command when the local migration states on some domain controllers do not match the global migration state.

Copy Code

The following Domain Controllers are not in sync with Global state (‘Prepared’):

Domain Controller (Local Migration State) – DC Type

===================================================

CONTOSO-DC2 (‘Start’) – ReadOnly DC

CONTOSO-DC3 (‘Preparing’) – Writable DC

Migration has not yet reached a consistent state on all domain controllers

State information might be stale due to AD latency.

To create the global objects and settings that DFS Replication uses in AD DS on domain controllers where those settings were not created automatically during migration or where those settings are missing, type:

Copy Code

dfsrmig /CreateGlobalObjects

To delete the global AD DS settings for FRS replication for a read-only domain controller named contoso-dc2 if those settings were not deleted automatically deleted by the migration process, type:

Copy Code

dfsrmig /DeleteRoNtfrsMember contoso-dc2

To delete the global AD DS settings for FRS replication for all read-only domain controllers if those settings were not deleted automatically by the migration process, type:

Copy Code

dfsrmig /DeleteRoNtfrsMember

To delete the global AD DS settings for DFS Replication for a read-only domain controller named contoso-dc2 if those settings were not deleted automatically by the migration process, type:

Copy Code

dfsrmig /DeleteRoDfsrMember contoso-dc2

To delete the global AD DS settings for DFS Replication for all read-only domain controllers if those settings were not deleted automatically by the migration process, type:

Copy Code

dfsrmig /DeleteRoDfsrMember

Additional references

Command-Line Syntax Key

SYSVOL Replication Migration Guide: FRS to DFS Replication

Migrating to the Prepared State

Migrating to the Redirected State

Migrating to the Eliminated State

Rolling Back SYSVOL Migration to a Previous Stable State

SYSVOL Migration Series: Part 2–Dfsrmig.exe: The SYSVOL Migration Tool

Dfsrmig

Categories: Active Directory Tags:

Offline Domain Join (Djoin.exe) Step-by-Step Guide

December 13th, 2011 No comments

Applies To: Windows 7, Windows Server 2008 R2

This guide explains the steps that you complete to perform an offline domain join. During an offline domain join, a computer is configured to join a domain without contacting a domain controller. This guide includes the following sections:

Offline domain join scenario overview

Offline domain join is a new process that computers that run Windows® 7 or Windows Server® 2008 R2 can use to join a domain without contacting a domain controller. This makes it possible to join computers to a domain in locations where there is no connectivity to a corporate network.

For example, an organization might need to deploy many virtual machines in a datacenter. Offline domain join makes it possible for the virtual machines to be joined to the domain when they initially start after the installation of the operating system. No additional restart is required to complete the domain join. This can significantly reduce the overall time that is required for wide-scale virtual-machine deployments.

A domain join establishes a trust relationship between a computer running a Windows operating system and an Active Directory® domain. This operation requires state changes to Active Directory Domain Services (AD DS) and state changes on the computer that is joining the domain. To complete a domain join in the past using previous Windows® operating systems, the computer that joined the domain had to be running and it had to have network connectivity to contact a domain controller. Offline domain join provides the following advantages over the previous requirements:

  • The Active Directory state changes are completed without any network traffic to the computer.
  • The computer state changes are completed without any network traffic to a domain controller.
  • Each set of changes can be completed at a different time.

The following sections explain some of the benefits that offline domain join can provide.

Reduced total cost of ownership in data centers

Offline domain join can reduce the total cost of ownership for computers by reducing the startup time that is required for each server and by increasing the reliability of domain join operations in production environments.

Data centers commonly have a provisioning server that configures an image and then sends that image to be deployed on a production computer. The production computer is set up, joined to the domain, and restarted. If there are any problems associated with the domain join, such as network connectivity problems or problems that are associated with necessary servers that are offline, the problems have to be diagnosed and resolved at that time. In this situation, an offline domain join helps prevent problems that can arise with the communication between the production computer and a domain controller by configuring the domain join information during the setup for the production computer. The total amount of time to set up each server is reduced by eliminating the additional restart that is required to complete an online domain join.

Improved experience for performing domain joins using an RODC

In Windows Server 2008, there is a mechanism to perform domain join operations against a read-only domain controller (RODC). However, to perform a domain join operation an RODC you have to complete the following multiple steps:

1. Precreate the computer account in the directory, and set some additional attributes using scripts.

2. If necessary, modify the Password Replication Policy (PRP) of the RODC to allow the password for the computer that you want to join to the domain to be cached by the RODC.

3. Force replication of the secrets of the computer that is to join to the domain.

4. Communicate the password offline to the computer that is about to join to the domain.

5. Run a custom script that targets the RODC to complete the join.

When you use offline domain join, the steps for performing domain join operations against an RODC are simplified, as follows:

1. Precreate the account in AD DS.

2. Force replication of the secrets of the computer that is to join to the domain.

3. Send the relevant state information that the domain-joining computer needs to consume to a text file.

4. The computer consumes the information in the text file; then, when it starts it is joined to the domain.

Rapid enterprise deployments

By using deployment tools, such as Windows System Image Manager, you can perform an unattended domain join during an operating system installation by providing information that is relevant to the domain join in an Unattend.xml file. Using the same Unattend.xml file, you can supply the information that is necessary for the computers that run Windows 7 and Windows Server 2008 R2 to perform offline domain join.

The Unattend.xml file for Windows 7 and Windows Server 2008 R2 includes a new section to support offline domain join.

Requirements for offline domain join

To perform an offline domain join, you run commands by using a new tool named Djoin.exe. You use Djoin.exe to provision computer account data into AD DS. You also use it to insert the computer account data into the Windows directory of the destination computer, which is the computer that you want to join to the domain. The following sections explain operating system requirements and credential requirements for performing an offline domain join.

The offline domain join does not have to be completed within a specific time period. The computer account that is provisioned remains in AD DS unless an administrator intervenes. However, many organizations run scripts every 30 to 60 days to clean up stale or unused computer accounts.

Operating system requirements

You can run Djoin.exe only on computers that run Windows 7 or Windows Server 2008 R2. The computer on which you run Djoin.exe to provision computer account data into AD DS must be running Windows 7 or Windows Server 2008 R2. The computer that you want to join to the domain must also be running Windows 7 or Windows Server 2008 R2.

By default, the Djoin.exe commands target a domain controller that runs Windows Server 2008 R2. However, you can specify an optional /downlevel parameter if you want to target a domain controller that is running a version of Windows Server that is earlier than Windows Server 2008 R2.

Credential requirements

To perform an offline domain join, you must have the rights that are necessary to join workstations to the domain. Members of the Domain Admins group have these rights by default. If you are not a member of the Domain Admins group, a member of the Domain Admins group must complete one of the following actions to enable you to join workstations to the domain:

  • Use Group Policy to grant you the required user rights. This method allows you to create computers in the default Computers container and in any organizational unit (OU) that is created later (if no Deny access control entries (ACEs) are added).
  • Edit the access control list (ACL) of the default Computers container for the domain to delegate the correct per
    missions to you.
  • Create an OU and edit the ACL on that OU to grant you the Create child – Allow permission. Pass the /machineOU parameter to the djoin /provision command.

The following procedures show how to grant the user rights with Group Policy and how to delegate the correct permissions.

Granting user rights to join workstations to the domain

You can use the Group Policy Management Console (GPMC) to modify the domain policy or create a new policy that has settings that grant the user rights to add workstations to a domain.

Membership in Domain Admins, or equivalent, is the minimum required to grant user rights. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To grant rights to join workstations to a domain

1. Click Start, click Administrative Tools, and then click Group Policy Management.

2. Double-click the name of the forest, double-click Domains, double-click the name of the domain in which you want to join a computer, right-click Default Domain Policy, and then click Edit.

3. In the console tree, double-click Computer Configuration, double-click Policies, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then double-click User Rights Assignment.

4. In the details pane, double-click Add workstations to domain.

5. Select the Define these policy settings check box, and then click Add User or Group.

6. Type the name of the account that you want to grant the user rights to, and then click OK twice.

Delegating permissions to join workstations to the domain

You can use a tool such as Ldp.exe to delegate permissions to join workstations to a domain. As a best practice, you should delegate permissions to a group, and then add users to the group or remove them as needed.

Membership in Domain Admins, or equivalent, is the minimum required to delegate permissions. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To delegate permissions to join workstations to a domain

1. Click Start, click Run, type ldp, and then click OK.

2. Click Connection, click Connect, and in Server type the name of a domain controller. If you are logged on to a domain controller, you can type localhost. When you are done, click OK.

3. Click Connection, and then click Bind. If you are logged on as a member of the Domain Admins group, click Bind as currently logged on user. If you are logged on as a different user, click Bind with credentials, and then type the name, password, and domain of an account that is a member of the Domain Admins group. Click OK.

4. Click View, click Tree, select DC=<domain>, and then click OK.

5. In the console tree, double-click DC=<domain>, right-click CN=Computers,DC=<domain>, click Advanced, click Security Descriptor, and then click OK.

6. Click ACE, click Add ACE, type the name of the account that you want to be able to join workstations to the domain, select the Create child check box, and then select the Inherit check box. In Object type, select computer – class (you might have to type computer to select computer – class), click OK, and then click Update.

Offline domain join process and Djoin.exe syntax

Run Djoin.exe at an elevated command prompt to provision the computer account metadata. When you run the provisioning command, the computer account metadata is created in a .txt file that you specify as part of the command. After you run the provisioning command, you can either run Djoin.exe again to request the computer account metadata and insert it into the Windows directory of the destination computer or you can save the computer account metadata in an Unattend.xml file and then specify the Unattend.xml file during an unattended operating system installation of the destination computer.

For more information about the NetProvisionComputerAccount function that is used to provision the computer account during an offline domain join, see NetProvisionComputerAccount Function (http://go.microsoft.com/fwlink/?LinkId=162426). For more information about the NetRequestOfflineDomainJoin function that runs locally on the destination computer, see NetRequestOfflineDomainJoin Function (http://go.microsoft.com/fwlink/?LinkId=162427).

Djoin.exe syntax

This section describes the syntax for Djoin.exe.

Copy Code

djoin /provision /domain <domain_name> /machine <destination computer> /savefile <filename.txt> [/machineou <OU name>] [/dcname <name of domain controller>] [/reuse] [/downlevel] [/defpwd] [/nosearch] [/printblob]

Copy Code

djoin /requestodj /loadfile <filename.txt> /windowspath <path to the Windows directory of the offline image> /localos

Parameter

Description

/provision

Creates a computer account in AD DS.

/domain <domain name>

Specifies the name of the domain to join.

/machine <destination computer>

Specifies the name of the computer that you want to join to the domain.

/machineou <OU Name>

Specifies the name of the organizational unit (OU) in which you want the computer account to be created. By default, the computer account is created in the Computers container.

/dcname <domain controller name>

Specifies the name of a specific domain controller that will create the computer account. If you do not specify a domain controller, the domain controller Locator (DC Locator) process is used to select a domain controller.

/reuse

Specifies the reuse of any existing computer account. The password for the computer account will be reset.

/downlevel

Supports the use of a domain controller that runs a version of Windows Server that is earlier than Windows Server 2008 R2.

/savefile <filename.txt>

Saves provisioning data to a file.

/defpwd

Uses the default machine account password (not recommended).

/nosearch

Skips account conflict detention. Requires the /DCName parameter.

/printblob

Return a base64-encoded metadata blob for an answer file.

/requestodj

Requests an offline domain join at the next start.

/Loadfile

Specifies the output from a previous provisioning command.

/windowspath <path to the Windows directory of the offline image>

Specifies the path to the Windows directory of the offline image. If you are using the /localos parameter, specify %systemroot% or %windir% as the value of the /windowspath parameter.

/localos

Targets the local operating system installation, instead of an offline image, with the domain join information. If you use this parameter, the value that you specify for /windowspath should be %systemroot% or %windir%. Run this parameter only on a destination computer that you want to join to the domain. This parameter is blocked from being run on a domain controller. Because this parameter injects the blob data into the locally running operating system image, you must restart the computer to complete the domain join operation, as you must also do for an online domain join.

Steps for performing an offline domain join

The offline domain join process includes the following steps:

1. Run the djoin.exe /provision command to create computer account metadata for the destination computer (the computer that you want to join to the domain). As part of this command, you must specify the name of the domain that you want the computer to join.

2. Run the djoin.exe /requestODJ command to insert the computer account metadata into the Windows directory of the destination computer.

3. When you start the destination computer, either as a virtual machine or after a complete operating system installation, the computer will be joined to the domain that you specify.

The following sections explain different ways for you to perform these steps. You can use the Windows Server 2008 Hyper-V™ virtualization feature to create virtual machines, you can use different physical computers, or you can run an unattended setup to perform an operating system installation on the destination computer. In any of these cases, the computer where you run the provisioning command and the computer where you run the request command must be running Windows 7 or Windows Server 2008 R2.

You can also perform these steps using a dual-boot computer. In this case, follow the steps to perform an offline domain join using Hyper-V, but substitute the virtual machines with physical partitions that are running Windows 7 or Windows Server 2008 R2.

Performing an offline domain join by using Hyper-V

To perform an offline domain join using Hyper-V, create the following virtual machines:

  • VM1: A domain controller that runs Windows Server 2008 R2.
  • VM2: A domain-joined computer that runs Windows 7 or Windows Server 2008 R2. This computer will serve as a provisioning server on which you can run the djoin /provision command. As an alternative, you can complete these steps without using this virtual machine by running the djoin /provision command on the domain controller that is VM1. This additional VM2 is shown to provide a more realistic example of how computers are provisioned in production environments, where a domain-joined computer is used typically as a provisioning server.
  • VM3: A computer that runs Windows 7 or Windows Server 2008 R2 that you want to join to the domain.

clip_image001Note

Do not use differencing disks from the same parent virtual hard disk (VHD) for these virtual machines. The differencing disk will not start correctly after you complete the steps to perform the offline domain join. You should also not use copies of the same VHD, because it will cause one virtual machine to be disabled when you try to mount it from the other virtual machine.

Complete the following steps to perform the offline domain join:

1. Log on to VM2 as a user who has rights to add workstations to a domain.

2. Type the following command to provision the destination computer:

Copy Code

djoin /provision /domain <domain to be joined> /machine <name of the destination computer> /savefile <filename.txt>

clip_image002Security Note

The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

3. Shut down VM3 and VM2, and then mount VM3 from VM2.
To do this in Hyper-V, right-click VM2, and then click Settings. Click IDE Controller, and then click Add. Select Virtual hard disk (.vhd) file, click Browse, navigate to the location of the .vhd file for VM3, click Open, and then click OK.

4. Restart VM2, and then use Windows Explorer to locate the drive where VM3 is mounted. At an elevated command prompt, type the following command to request the offline domain join data:

Copy Code

djoin /requestODJ /loadfile <filename.txt> /windowspath <path to Windows directory of the offline image>

5. Shut down VM2, and then unmount VM3 from VM2. To do this in Hyper-V, right-click VM2, and then click Settings. Click the integrated device electronics (IDE) controller that corresponds to VM3, and then click Remove.

6. Start VM3. The computer will be joined to the domain after i
t starts.

If you experience any problems running the Djoin.exe commands, you can view the log file on VM2 at %windir%debugnetsetup.log for more information.

Performing an offline domain join using different physical computers

To perform an offline domain join using physical computers, you can complete the following steps. The best practice in this case is to have one domain controller, one domain-joined computer to use as a provisioning server, and one client computer that you want to join to the domain.

1. On the provisioning server, open an elevated command prompt. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

2. Type the following command to provision the computer account:

Copy Code

djoin /provision /domain <domain to be joined> /machine <name of the destination computer> /savefile blob.txt

3. Copy the blob.txt file to the client computer.

4. On the client computer, open an elevated command prompt, and then type the following command to request the domain join:

Copy Code

djoin /requestODJ /loadfile blob.txt /windowspath %SystemRoot% /localos

clip_image003Caution

You cannot run this command with the /localos parameter on a domain controller.

5. Reboot the client computer. The computer will be joined to the domain.

Performing an offline domain join by using an unattended operating system installation

To perform an offline domain join during an operating system installation, you must first run Djoin.exe to provision the computer account metadata. Then, you create an Unattend.xml file and include a new section in it for the offline domain join data. In the new section, you can insert the computer account metadata.

The component name for the new section is Microsoft-Windows-UnattendJoin/Identification/Provisioning, and it includes the following structure:

  • <Component>
  • <Component name=Microsoft-Windows-UnattendedJoin>
  • <Identification>
  • <Provisioning>
  • <AccountData>Base64Encoded Blob</AccountData>
  • </Provisioning>
  • </Identification>
  • </Component>

You have to insert the computer account metadata within the <AccountData> and </AccountData> tags. After you create the Unattend.xml file, start the computer that you want to join to the domain in Safe Mode or start the computer in Windows Preinstallation Environment (Windows PE), and then run the setup command with an answer file, as shown in the following example:

Copy Code

setup /unattend:<answer_file_path>

Source: Offline Domain Join (Djoin.exe) Step-by-Step Guide

Categories: Active Directory Tags:

How to create a Central Store for Group Policy Administrative Templates in Window Vista

December 13th, 2011 No comments

This article describes how to use the new .admx and .adml files to create and to administer registry-based policy settings in Windows Vista. This article also explains how the Central Store is used to store and to replicate Windows Vista policy files in a domain environment.

Back to the top

MORE INFORMATION

Overview Windows Vista uses a new format to display registry-based policy settin…

Overview

Windows Vista uses a new format to display registry-based policy settings. These registry-based policy settings appear under Administrative Templates in the Group Policy Object Editor. In Windows Vista, these registry-based policy settings are defined by standards-based XML files that have an .admx file name extension. The .admx file format replaces the legacy .adm file format. The .adm file format uses a proprietary markup language.
In Windows Vista, Administrative Template files are divided into .admx files and language-specific .adml files that are available to Group Policy administrators. The changes that are implemented in Windows Vista let administrators configure the same set of policies by using two different languages. Administrators can configure policies by using the language-specific .adml files and the language-neutral .admx files.

Back to the top

Administrative Template file storage

In earlier operating systems, all the default Administrative Template files are added to the ADM folder of a Group Policy object (GPO) on a domain controller. The GPOs are stored in the SYSVOL folder. The SYSVOL folder is automatically replicated to other domain controllers in the same domain. A policy file uses approximately 2 megabytes (MB) of hard disk space. Because each domain controller stores a distinct version of a policy, replication traffic is increased.
Windows Vista uses a Central Store to store Administrative Template files. In Windows Vista, the ADM folder is not created in a GPO as in earlier versions of Windows. Therefore, domain controllers do not store or replicate redundant copies of .adm files.

Collapse this tableExpand this table

Note
If you use a client that is running an earlier version of Windows to modify a policy that is created or administered on a Windows Vista-based computer, the client creates the ADM folder and replicates the files.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

816662 (http://support.microsoft.com/kb/816662/ ) Recommendations for managing Group Policy Administrative Template (.adm) files

Back to the top

The Central Store

To take advantage of the benefits of .admx files, you must create a Central Store in the SYSVOL folder on a domain controller. The Central Store is a file location that is checked by the Group Policy tools. The Group Policy tools use any .admx files that are in the Central Store. The files that are in the Central Store are later replicated to all domain controllers in the domain.
To create a Central Store for .admx and .adml files, create a folder that is named PolicyDefinitions in the following location:

\FQDNSYSVOLFQDNpolicies

Collapse this tableExpand this table

Note
FQDN is a fully qualified domain name.

For example, to create a Central Store for the Test.Microsoft.com domain, create a PolicyDefinitions folder in the following location:

\Test.Microsoft.ComSYSVOLTest.Microsoft.ComPolicies

Copy all files from the PolicyDefinitions folder on a Windows Vista-based client computer to the PolicyDefinitions folder on the domain controller. The PolicyDefinitions folder on a Windows Vista-based computer resides in the same folder as Windows Vista. The PolicyDefinitions folder on the Windows Vista-based computer stores all .admx files and .adml files for all languages that are enabled on the client computer.
The .adml files on the Windows Vista-based computer are stored in a language-specific folder. For example, English (United States) .adml files are stored in a folder that is named "en-US." Korean .adml files are stored in a folder that is named "ko_KR." If .adml files for additional languages are required, you must copy the folder that contains the .adml files for that language to the Central Store. When you have copied all .admx and .adml files, the PolicyDefinitions folder on the domain controller should contain the .admx files and one or more folders that contain language-specific .adml files.

Collapse this tableExpand this table

Note
When you copy the .admx and .adml files from a Windows Vista-based computer, verify that the most recent updates to these files and to Windows Vista are installed. Also, make sure that the most recent Administrative Template files are replicated. This advice also applies to service packs if applicable.

Back to the top

Group Policy administration

Windows Vista does not include Administrative Templates that have an .adm extension. Additionally, earlier versions of Windows cannot use the new administrative format. Therefore, client computers that are running earlier versions of Windows cannot administer new policies that are included with Windows Vista. We recommend that you use computers that are running Windows Vista or later versions of Windows to perform Group Policy administration.

Back to the top

Updating Administrative Template Files

In Group Policy for versions of Windows earlier than Windows Vista, if you change Administrative template policy settings on local computers, the Sysvol share on a domain controller within your domain is automatically updated with the new .ADM files. In turn, those changes are replicated to all other domain controllers in the domain. This might result in increased network load and storage requirements. In Group Policy for Windows Server 2008 and Windows Vista, if you change Administrative template policy settings on local computers, Sysvol will not be automatically updated with the new .ADMX or .ADML files. This change in behavior is implemented to reduce network load and disk storage requirements, and to prevent conflicts between .ADMX files and. ADML files when edits to Administrative template policy settings are made across different locales. To make sure that any local updates are reflected in Sysvol, you must manually copy the updated .ADMX or .ADML files from the PolicyDefinitions file on the local computer to the SysvolPolicyDefinitions folder on the appropriate domain controller.
To download the Administrative template files for Windows Server 2008, see Administrative Templates (ADMX) for Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=116434) .

Back to the top



APPLIES TO
  • Windows Vista Ultimate
  • Windows Vista Enterprise
  • Windows Vista Business
  • Windows Vista Home Premium
  • Windows Vista Home Basic
  • Windows Vista Starter

Source: How to create a Central Store for Group Policy Administrative Templates in Window Vista

Categories: Group Policy Tags:

Enabling “Desktop Experience” feature on Windows Server 2008 R2

December 13th, 2011 No comments

The Desktop Experience feature enables you to install a variety of Windows 7 features on your server running Windows Server 2008. If you use Windows Server 2008 as your primary operating system, you might want to have some of these Windows 7 features available for your daily use.

What does the Desktop Experience feature include?
Desktop Experience includes the following Windows 7 components and features:

Windows Media Player

Desktop themes

Video for Windows (AVI support)

Windows SideShow

Windows Defender

Disk Cleanup

Sync Center

Sound Recorder

Character Map

Snipping Tool

Note 
Installing Desktop Experience does not automatically turn on any of the features it installs. After installation, you must manually enable any features that require configuration changes. For example, to use a desktop theme, use the Services snap-in for Microsoft Management Console to enable and start the Themes service, and then select the theme.
 

Installing or uninstalling the Desktop Experience feature

 

You can install or uninstall Desktop Experience using the Initial Configuration Tasks Wizard or Server Manager.

To install Desktop Experience using the Initial Configuration Tasks Wizard

In the Customize This Server section, click Add features.

Select the Desktop Experience check box, and then click Next.

Complete the wizard by clicking Install.

To install Desktop Experience using Server Manager

Open Server Manager: click Start, point to Administrative Tools, and click Server Manager.

Notes 
You can also open Server Manager by typing the following at a command prompt:
servermanager.msc
 

In the Features Summary section, click Add features.

Select the Desktop Experience check box, and then click Next.

Complete the wizard by clicking Install.

You can uninstall Desktop Experience at any time by using either method above to start the Add Features Wizard. When the wizard opens, clear the Desktop Experience check box, click Next, and then click Remove to complete the wizard.

image

Categories: Server 2008 R2 Tags: