Share via

RODC Installation

  • Article

Applies To: Windows Server 2008, Windows Server 2012

This topic describes tasks that you typically must complete to install a read-only domain controller (RODC), including:

Choosing whether to upgrade an existing domain controller or install a new domain controller

Choosing whether to install the Server Core or the Full installation options and using BitLocker

Using virtualization

Installing writable domain controllers

Installing RODCs

Depending on the scenario in which you plan to use an RODC, you may need to perform some additional tasks.

Choosing whether to upgrade an existing domain controller or install a new domain controller

To install a domain controller running Windows Server 2008, you can either upgrade an existing domain controller that runs Windows Server 2003 or you can install a new server that runs Windows Server 2008. This section explains the advantages and disadvantages of each approach.

Upgrading an existing domain controller

Although you cannot upgrade domain controllers that run Windows 2000 Server to Windows Server 2008, you can upgrade domain controllers running Windows Server 2003. When you upgrade a Windows Server 2003 domain controller, it always remains a writable domain controller. You cannot make a Windows Server 2003 domain controller an RODC during the upgrade.

If you want to upgrade a Windows Server 2003 domain controller and make it an RODC, you must remove Active Directory Domain Services (AD DS). You can remove AD DS either just before or just after you upgrade the operating system. After you upgrade the server and it is no longer a domain controller, reinstall AD DS and choose the RODC option during the AD DS installation.

If the existing domain controller is in a remote location, you can reinstall AD DS more efficiently by using the install from media (IFM) feature. The recommended steps for using IFM to reinstall AD DS are as follows:

  1. Upgrade the operating system of the Windows Server 2003 domain controller to Windows Server 2008. For more information, see Upgrade Existing Domain Controllers to Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=120008).

  2. Run the ntdsutil ifm command to create installation media for an RODC, which removes any cached secrets, such as passwords. For more information, see Installing AD DS from Media (https://go.microsoft.com/fwlink/?LinkId=120013).

  3. Remove AD DS. For more information, see Removing a Windows Server 2008 Domain Controller from a Domain (https://go.microsoft.com/fwlink/?LinkId=120012).

  4. Reinstall AD DS using the IFM feature. For more information, see Installing AD DS from Media (https://go.microsoft.com/fwlink/?LinkId=120013).

The following table lists some advantages and disadvantages of upgrading an existing domain controller.

Advantages Disadvantages
  • The server retains information about its state after the upgrade is complete. For example, the domain controller retains the same name, IP address, and other network connection settings.

  • There are no additional costs for shipping a new server to the location.
  • An increased amount of verification is required after the upgrade is complete to ensure that all existing data, services, and settings are retained and functioning after the upgrade is complete.

  • It is not possible to upgrade to the Server Core installation option of the Windows Server 2008 operating system.

  • It is not possible to upgrade directly to an RODC. To make any writable domain controller be an RODC, you need to remove and then re-install AD DS.

  • Upgrading any application to run on a server that runs Windows Server 2008 is supported only if the application is certified for Windows Server 2008. For more information about applications that are certified for Windows Server 2008, see Windows Server Catalog (https://go.microsoft.com/fwlink/?LinkId=120525). If an application is not certified for Windows Server 2008, you must uninstall it before the upgrade and re-install it after the upgrade.

Known issues for upgrading domain controllers

A branch office might have a single server that performs other server roles, in addition to AD DS and DNS. For this type of server, you must perform additional testing to ensure that the other server roles function correctly after the upgrade. In some cases, you may be able to perform workarounds to avoid problems. Check the issues in the following list, and plan to resolve any issues that can arise if you are upgrading a server that hosts a particular server role or application.

  • An additional domain controller that is running Windows Server 2008 and that has the Japanese language locale installed does not receive updates to some attributes on an object during inbound replication. There are steps that you can take to prevent this issue from occurring, and there are steps that you can take to resolve the issue if the issue has already occurred. For more information, see article 949189 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=114418).

  • The Windows SharePoint® Services 3.0 Search index may be corrupted when you upgrade Windows Server 2003 to Windows Server 2008. If you are upgrading a server that hosts Windows SharePoint Services 3.0, see article 943605 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=111882). This article provides steps for avoiding corruption problems, and it provides steps for resolving corruption problems if they occur.

  • After you upgrade from Windows Server 2003 to Windows Server 2008, you cannot locally configure or locally delete the application partitions that are created for IP telephony because the Tapicfg.exe tool is not included in Windows Server 2008. You must complete any deletion and configuration changes before you upgrade to Windows Server 2008. For more information, see article 947039 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=113173).

Installing a new domain controller

Many organizations choose to install new servers rather than upgrade existing servers. In many cases, the decision to begin using a new operating system coincides with a scheduled hardware refresh, in which an organization replaces all of its existing servers with new servers that run the new operating system.

Installing new servers is especially advantageous when you are performing a platform upgrade, such as replacing x86-based servers with 64-bit servers. In this case, there is no option to upgrade the existing servers.

The following table lists additional advantages and disadvantages of installing a new domain controller.

Advantages Disadvantages
  • Newer servers typically have better resources and significant performance advantages.

  • There are often fewer compatibility issues with other devices such as network adapters and storage controllers.
  • There are significant costs associated with purchasing new hardware.

  • When you install a new domain controller, you must configure all settings and other state information, such as network settings and user profile information.

Choosing whether to install the Server Core or the Full installation options and using BitLocker

Windows Server 2008 provides two different installation options, a full installation option and a Server Core installation option.

The full installation provides all the server roles and features that are available in Windows Server 2008. The full installation includes a graphical user interface (GUI).

A Server Core installation is a minimal installation for running a limited set of server roles. A server running a Server Core installation does not have a GUI or provide the ability to run most applications, which helps to reduce the attack surface of the server. To improve the security of branch office domain controllers, we recommend deploying RODCs that run on the Server Core installation.

The following sections provide more details about the Server Core installation and Windows BitLocker™ Drive Encryption, which you can also use to provide additional security for branch office servers such as RODCs.

Using the Server Core installation for RODCs

A server running a Server Core installation can run the following server roles:

  • AD DS

  • Active Directory Lightweight Directory Services (AD LDS)

  • DNS

  • Dynamic Host Configuration Protocol (DHCP)

  • File Server

  • Print Server

  • Streaming media services

  • Web Services (without ASP.NET)

  • Hyper-V

In addition to being able to run these server roles, you can install other Windows Server 2008 features on a Server Core installation, such as BitLocker Drive Encryption and Windows Server Backup. For a complete list of the features that you can install with a Server Core installation, see Server Core Installation Option (https://go.microsoft.com/fwlink/?LinkId=120025).

A Server Core installation provides the following benefits:

  • Reduced maintenance. Because a Server Core installation installs only what is required for the specified server roles, less servicing is required than is required for a full installation of Windows Server 2008.

  • Reduced attack surface. Because a Server Core installation is minimal, there are fewer applications running on the server, which decreases the attack surface.

  • Reduced management. Because fewer applications and services are installed on a server running a Server Core installation, there are less applications and services to manage.

  • Less required disk space. A Server Core installation requires only about 1 gigabyte (GB) of disk space to install and approximately 2 GB for operations after the installation. However, the system state backups for a domain controller that runs on a Server Core installation will not use significantly less space than the system state backups for a full installation. This is because the system state components for a domain controller, which include the Active Directory database, SYSVOL, the registry, and some operating system files, are the same for each installation option. Backups generally require similar resources for each installation option.

A Server Core installation is not an application development platform, and it is not designed to run roles and features other than the roles and features that are supported by default. But you can run many types of applications on a Server Core installation. Be sure to test all applications that you intend to run on a Server Core installation. As a general rule, the applications should meet the following criteria:

  • The application installs silently, meaning it does not require interactive attention from an administrator.

  • The application does not depend on a GUI.

  • The application does not depend on server roles or Windows features that might not be installed on the Server Core installation.

Applications that depend on the .Net Framework, Windows Explorer, Windows PowerShell, or Microsoft Management Console (MMC) will not run on a Server Core installation. However, many monitoring and management applications, including many non-Microsoft backup and antivirus programs, can run on a Server Core installation without any problems. Microsoft Operations Manager (MOM) 2005, Systems Management Server (SMS) 2003, and Microsoft System Center Operations Manager 2007 are examples of management applications that run on Server Core.

Considerations for installing Server Core and upgrading domain controllers

Keep in mind the following considerations as you plan whether to use the Server Core installation option:

  • A Server Core installation is not a separate version or edition of Windows Server 2008. It is an installation option that you can choose to run on any edition of Windows Server 2008.

  • You cannot upgrade a domain controller that runs Windows 2000 Server or Windows Server 2003 to a Server Core installation of Windows Server 2008.

  • You cannot convert from a full installation to a Server Core installation, or the reverse.

  • From an administrative workstation that runs Windows Vista with Service Pack 1 (SP1) or Windows Server 2008, you can use the MMC snap-ins in Remote Server Administration Tools (RSAT) to remotely administer a Server Core installation. For more information, see Using RSAT.

Using BitLocker on RODCs

RODCs do not require you to install BitLocker™ Drive Encryption. RODCs do not contain passwords. Therefore, by default they can be deployed more securely than a writable domain controller. But if your organization is planning on deploying an RODC in a location where it might be stolen, you may want to install BitLocker as an additional precaution to help safeguard data on the server.

Whereas RODCs prevent some sensitive data, including secrets and attributes in the RODC filtered attribute set (FAS), from ever being present on the server, BitLocker encrypts the data that is present on the server to protect it from being retrieved by an attacker, including, in particular, all remaining Active Directory data, Group Policy data, file shares, and data on local volumes.

One possible administrative disadvantage to using BitLocker on an RODC is that you have to provide a password and restart the RODC each time that you apply an operating system update to it. Weigh the potential security benefits that BitLocker provides against this additional administrative requirement to determine whether to use BitLocker on a specific RODC.

BitLocker is integrated with AD DS on domain controllers running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 R2, or Windows Server 2008. You have to configure AD DS to back up recovery information for BitLocker and the Trusted Platform Module (TPM). For more information, see Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information (https://go.microsoft.com/fwlink/?LinkId=120069).

Using virtualization

Server virtualization is a significant trend in all types of enterprises. Virtualization offers many benefits, including better use of hardware capacity, improved disaster recovery scenarios, and more manageable hardware upgrades.

You can run any type of domain controller as a virtual server. However, there are a number of considerations that you should take into account. For more information about considerations for hosting a domain controller as a virtual server, see article 888794 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=113458) and Running Domain Controllers in Virtual Server 2005 (https://go.microsoft.com/fwlink/?LinkID=38330). The guidelines in these documents are applicable for Windows Server 2008, in addition to Windows Server 2003.

You can use virtualization to reduce the number of servers that you deploy in hub sites and branch offices. However, for any writable domain controller, there is a risk of encountering a condition called an update sequence number (USN) rollback. A USN rollback occurs when you perform an improper restore operation. This is particularly easy to do when you use virtualization, because it becomes possible to take a backup of a domain controller, for example, by using the snapshot feature of Microsoft Hyper-V™ Server and then reusing this backup later to effectively “go back in time.”

What happens is the following:

  1. At time T0, you take a snapshot (backup) of the virtual computer (which is a writable domain controller).

  2. The domain controller processes any changes, and the changes are replicated to other domain controllers in the forest. The USN, which acts as a logical clock for the domain controller, increases. The other domain controllers that have replicated these changes then modify their up-to-dateness (UTD) vector based on the new value of the USN for the domain controller from which the changes originate.

  3. You restore the domain controller by using the snapshot in step 1. The USN for the domain controller is then restored to the previous value that it had at time T0. The domain controller processes additional changes, and the USN increases. In this situation, one of following two things can happen:

    1. If the value of the USN on the restored domain controller has not reached the value that it had before the restore operation by the next replication cycle, the domain controller that replicates the updates detects that its partner was improperly restored (because the USN that is stored in its UTD vector is higher than the USN that is advertised by the restored domain controller). The improperly restored domain controller is then automatically quarantined to avoid divergence in the forest.

    2. If the value of the USN on the restored domain controller has surpassed the value that it had before the restore operation by the next replication cycle, the domain controller that replicates from it requests only the changes that correspond to the USN values between the value it has stored in its UTD vector (which is based on the USN from just before the improper restore) and the new value. This means that the data that is stored on both domain controllers is different. The improperly restored domain controller does not have the changes that occurred before the restore, but it does have all the new changes. The replication partner of this domain controller has all the changes that occurred before the restore and only the new changes that correspond to the higher USN than the USN that is stored in its UTD vector. It is important to note that the domain controllers in this case cannot detect the USN rollback. The set of changes that are divergent between the two domain controllers is referred to as a “USN bubble,” and they cannot be corrected.

For more information about USN rollback, see article 875495 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=113459).

It is important to note that RODCs do not have the same risk for USN rollback because they do not perform outbound replication. This helps make RODCs less susceptible to problems in a virtual environment than writable domain controllers. An RODC that is restored with a Hyper-V snapshot replicates all changes that it needs, but no divergence will happen in the forest because of such a restore.

There are two other issues to keep in mind because they apply to RODCs:

  • You should not copy .vhd files, which are virtual hard disk files, because cloning of domain controllers is not supported. It can result in divergences in the forest. To add more domain controllers to a domain, install the operating system on the new virtual server and use Dcpromo.exe to make that server an additional domain controller in an existing domain.

  • You should not pause and restart virtual machines because doing so can lead to the Windows Time service (W32time) not working correctly. However, this type of issue occurs less frequently when you use Hyper-V to virtualize servers.

In general, it is preferable to separate the AD DS domain controller role from other server roles, both on physical servers and virtualized servers. The administrators who manage AD DS are not typically the same administrators as for other server roles, such as IIS or Microsoft Internet Security and Acceleration (ISA) Server. Virtualization makes it possible to isolate the server roles by providing a way for you to deploy multiple virtual servers that are each dedicated to specific functions on a single physical computer.

We recommend that you install one virtual server that is dedicated to AD DS and DNS. Note that the File Replication Service (FRS) or Distributed File System (DFS) Replication are also installed on the same server for SYSVOL replication. Dedicate one virtual server or multiple other virtual servers to other functions. This recommendation applies to both writable domain controllers and RODCs.

The best practice for Hyper-V is to deploy the Hyper-V role on a Server Core installation of Windows Server 2008 and then run any other roles, including AD DS, as virtual machines.

The Branch Infrastructure Implementation Solution for Windows Server 2008 provides automated tools and technical guidance for assessment, planning, design, and security for Hyper-V and Virtual Server 2005 R2. For more information about the Branch Infrastructure Implementation Solution for Windows Server 2008, see the Branch Infrastructure Implementation Solution for Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=120084).

Installing writable domain controllers

The main issue with regard to deploying writable domain controllers in hub sites and data centers is making sure that you have enough domain controllers up and running to support the branch office domain controllers during the switchover to Windows Server 2008. If you are upgrading all your current Windows Server 2003 domain controllers to Windows Server 2008 and you are not adding any new servers, you might have to upgrade the domain controllers one at a time to ensure that remaining domain controllers in the hub site do not become overloaded as they handle the replication workload.

The steps that you have to perform to install writable domain controllers by using the GUI, command line, or an answer file are documented in Installing an Additional Windows Server 2008 Domain Controller (https://go.microsoft.com/fwlink/?LinkID=93254).

Installing RODCs

There are two different methods for installing an RODC. Each method provides advantages for specific installation scenarios.

Staged installation. This is a new installation method that is specifically designed to make it easier to deploy RODCs in remote locations. This new method does not require a member of the Domain Admins group to complete the installation in the remote location. You can delegate the installation to any domain user.

This installation method is advantageous when you are installing an RODC as the first domain controller in a remote site or you are replacing an RODC with another RODC. If you are replacing a writable domain controller in a branch office with an RODC, a staged installation does not provide any advantage over a direct installation. This is because the same person who is currently managing the domain controller that is being replaced in that site can perform a full promotion of the RODC, and there is no need to delegate the installation to a domain user.

Direct installation. This is the same installation as for any additional domain controller. To make the additional domain controller an RODC, you only have to select the RODC domain controller option during the installation. To complete a full promotion of an RODC, you must be a member of the Domain Admins group or you must be delegated the appropriate permissions.

Note

You cannot transform an RODC into a writable domain controller or a writable domain controller into an RODC. To change a writable domain controller to an RODC, you have to demote the writable domain controller and then promote it again as an RODC. Because you need to use Domain Admin credentials to demote the writable domain controller, you most often perform a direct installation in this situation.

Staged installation

Windows Server 2008 includes a new, staged installation process that you can use to install an RODC in two stages. A Domain Admin can delegate the final stage of an RODC installation to any domain user or group. The delegated user can complete the RODC installation in the branch office where the RODC will ultimately be located and perform administration tasks on the RODC after installation. This section describes the steps for installation. For steps for administering an RODC, see RODC Administration.

Staged installation is designed specifically to help you deploy RODCs to remote branch offices by separating the RODC installation process into two stages.

  1. A Domain Admin creates a computer account for the RODC and (as an option) delegates a user or group the ability perform the second stage of the installation and be the server administrator for the RODC after the installation is complete. A Domain Admin will typically complete this stage in a central location, such as a datacenter or hub site.

  2. The delegated RODC server administrator joins the server to the RODC account that the Domain Admin created for it. A staged AD DS installation makes it unnecessary to use a highly privileged Domain Admin account in the branch office to complete the installation of AD DS. The delegated RODC server administrator will typically complete this stage in branch office where the organization plans to deploy the RODC.

You can also use the IFM installation option in conjunction with a staged installation. The IFM option significantly reduces the amount of data that has to be replicated to a new domain controller over the network during the installation of AD DS.

When you use the IFM option for an RODC installation, you can secure the installation media before transporting it to the branch office by removing secrets, such as user account passwords, from it. This way, if the installation media is lost or stolen while it is being transported, it cannot be compromised to reveal passwords. Because the RODC does not cache any passwords by default, they do not need to be present in the RODC installation media.

You can use the ntdsutil ifm command to create the media that you use for the IFM installation option. For a procedure that uses this command, see Installing AD DS from Media (https://go.microsoft.com/fwlink/?LinkID=120013).

The staged installation process works as follows:

  1. In the datacenter, an administrator uses the Active Directory Users and Computers snap-in to create an account in the Domain Controllers container for the RODC. This account creation process uses Dcpromo.exe, and it can be scripted if you need to create many accounts. While creating the account, the administrator can also specify who will administer the RODC and whose passwords can be cached on it.

  2. The administrator obtains the server running Windows Server 2008 and has it shipped directly to the branch office where it will be used as an RODC.

  3. In the branch office, a local user (delegated by the administrator in step 1) starts the server and runs Dcpromo, installing AD DS and completing the RODC installation. No highly privileged credentials have to be used in the branch office, either by the local user or remotely by a datacenter administrator.

Although performing a staged installation can help streamline the process for deploying RODCs in branch offices, some organizations might continue to use procedures in which servers are built in a central location and then transported to a branch office. Some reasons for retaining these procedures include:

  • Security classification tagging or certification

  • Asset tagging

  • Installing new hardware or custom hardware

  • Ensuring that the computer has all of its hardware and software updates before it is connected in the field

  • Burn-in testing (ensuring that all the hardware does not fail in the first 72 hours)

Note

If you continue to build servers in a central (hub) location, be aware that if a domain controller that you build in the central location is disconnected from the network for more than 30 days while it is transported to the branch office, you might have to reset the machine account passwords so that the domain controller can perform replication. For more information, see article 260575 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=26093).

For more information about performing a staged installation, see Performing a Staged RODC Installation (https://go.microsoft.com/fwlink/?LinkID=103323).

Direct installation

If you intend to perform a direct installation for an RODC, you can follow the same steps that you used to install the writable domain controller in the hub site. A direct installation combines both stages of a staged installation into a single step.

On the Additional Domain Controller Options page of the Active Directory Domain Services Installation Wizard, select the Read-only domain controller check box. Be sure to delegate a security group to administer the RODC. You can also specify the Password Replication Policy (PRP) for the RODC during the installation.

Whether you specify the PRP during or after installation, cache the password of at least one user from the security group that you delegated to administer the RODC. This ensures that some user always has the ability to log on to the RODC by using the delegated account instead of privileged credentials. Refresh the cache after each time that the password is changed.

For more information, see Direct Installation Method.