Administering RODCs in Branch Offices

Applies To: Windows Server 2008, Windows Server 2012

This topic provides guidelines for common administrative tasks for read-only domain controllers (RODCs) in branch offices:

• Using Remote Desktop to administer RODCs in branch offices

• Reestablishing replication for an RODC

• Checking the lastLogonTimeStamp attribute on an RODC to discover stale accounts in a branch office

• Resolving an account lockout problem in a branch office with an RODC

• Performing backups of an RODC

Using Remote Desktop to administer RODCs in branch offices

You have to enable Remote Desktop on an RODC to be able to log on to the RODC remotely. By default, Remote Desktop is disabled on servers that run Windows Server 2008.

Security Note
If you log on by using Remote Desktop to any computer that you do not trust, make sure that you do not log on as a Domain Admin or use other privileged credentials. As a best practice, you should never expose Domain Admin credentials to a computer that is not fully trusted.

If possible, enable Remote Desktop for an RODC as part of any automated Windows Server 2008 operating system installation. For example, if you use Sysprep.exe to install servers, update the Sysprep answer file to enable Remote Desktop.

If you do not enable Remote Desktop as part of the operating system installation and you administer only a few RODCs, you can enable it by using the graphical user interface (GUI) or by using Registry Editor.

To enable Remote Desktop by using the GUI

1. Click Start, right-click Computer, and then click Properties.

2. Click Remote settings.

3. Click the Remote tab.

4. If you will administer the RODC from a computer that runs Windows Vista or Windows 7, click Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure).

   If you will administer the RODC from a computer that runs an earlier version of Windows, click Allow connections only from computers running any version of Remote Desktop (less secure).

To open a firewall to enable Remote Desktop by using the command line, run the following netsh commands:

• To open the firewall to allow access to an RODC by using Remote Desktop, at an elevated command prompt, type the following command, and then press ENTER:

  netsh advfirewall set publicprofile settings remotemanagement enable
  

• To open the firewall to allow use of Microsoft Management Console (MMC) snap-ins, such as Event Viewer, remotely, at a command prompt, type the following command, and then press ENTER:

  netsh firewall set service remoteadmin enable
  

To enable Remote Desktop by using Registry Editor

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

2. Navigate to the following key

   HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server

3. In the details pane, double-click fDenyTSConnections, and change the DWORD value to 0.

4. If you will manage the RODC from a workstation that Windows Vista or Windows 7, navigate to the following key:

   HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\WinStations\RDP-Tcp

5. In the details pane, double-click UserAuthentication, and change the DWORD value to 1.

6. Close Registry Editor and restart the RODC to make the changes effective.

If you do not enable Remote Desktop as part of the operating system installation and you need to administer many RODCs, you can enable Remote Desktop by editing the Default Domain Controllers Policy. However, using this Group Policy object (GPO) enables Remote Desktop for all domain controllers in the domain.

To create a GPO that allows the use of Remote Desktop to administer RODCs in branch offices

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

2. In the console tree, right-click Default Domain Controllers Policy and click Edit.

   Where?

   Forest: Forest name\Domains\Domain name\Domain Controllers\Default Domain Controllers Policy

3. Navigate to the following folder:

   Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections

4. Double-click Allow users to connect remotely using Remote Desktop Services.

5. Click Enabled, and then click OK.

Reestablishing replication for an RODC

If the site where you add an RODC is not included in a site link or if the site link is accidentally deleted, complete the following steps to get the RODC replicating again.

1. On a writable domain controller, place the site with the RODC in a site link. Make sure that the site link contains a site with a writable domain controller.

2. Force replication of the configuration partition to the RODC by using either the Active Directory Sites and Services snap-in or Repadmin.exe, as described in the following procedures.

3. Run the repadmin /kcc command on the RODC to trigger the KCC. The KCC will then maintain replication to the RODC.

To use Active Directory Sites and Services to force replication of the configuration partition to an RODC

1. Open the Active Directory Sites and Services snap-in (Dssite.msc). To open Active Directory Sites and Services, click Start, click Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, enter the appropriate credentials (if requested), confirm that the action it displays is what you want, and then click Continue.

2. Double-click Sites, double-click the name of the site that has the RODC, double-click Servers, double-click the name of the RODC, right-click NTDS Settings, and then click Replicate configuration to the selected DC.

3. Click OK to close the message indicating that AD DS has replicated the connections.

To use Repadmin.exe to force replication of the configuration partition to an RODC

1. To create a replication link manually on an RODC from the command line, open an elevated command prompt, and then run the following commands:

   • repadmin /add <configuration partition> <name of the RODC> <FQDN of the source domain controller> /readonly /selsecrets

   • repadmin /replicate <RODC> <FQDN of the source domain controller> <configuration partition>

   Where:

   <configuration partition> is the distinguished name of the configuration partition. For example, cn=configuration,DC=contoso,DC=com.

   <name of the RODC> is the single-label computer name of the RODC.

   <FQDN of source domain controller> is the fully qualified domain name (FQDN) of the domain controller that the RODC will replicate from, for example, <GUID>._mscdcs.<domain>.

Checking the lastLogonTimeStamp attribute on an RODC to discover stale accounts in a branch office

Some organizations periodically check the lastLogonTimeStamp attribute of user and computer accounts to help discover accounts that have been inactive. The lastLogonTimeStamp attribute indicates the time that a user last logged on to the domain. This attribute is replicated to all domain controllers. Therefore, you can easily query accounts that are not being used. For more information about creating a script to retrieve lastLogonTimeStamp, see the Script Center (https://go.microsoft.com/fwlink/?LinkID=47965).

The domain functional level must be at least Windows Server 2003 before you can check lastLogonTimeStamp.

All domain controllers use the same algorithm to determine whether lastLogonTimeStamp for an account must be updated. However, because updates are not replicated from an RODC, any updates that an RODC makes to lastLogonTimeStamp are handled slightly differently than they are for a writable domain controller.

If an account has its credentials cached by an RODC and the RODC authenticates the logon, the RODC first writes a new value for lastLogonTimeStamp locally for the account and then forwards the new value to a writable domain controller. This write operation is one of a limited set of write operations that are performed locally on an RODC. During the next scheduled replication cycle, the value on the RODC is overwritten because the value that is replicated from the writable domain controller will have a slightly later time stamp.

If the RODC only forwards the logon attempt to a writable domain controller (because the account credentials are not cached), the writable domain controller evaluates whether a new value for lastLogonTimeStamp for the account should be written and performs the write operation, if applicable.

If you are using scripts to discover stale accounts in your environment, you might update the scripts in the following way to deal with accounts whose lastLogonTimeStamp might be updated on an RODC but not on any writable domain controller. This condition occurs in a situation in which the RODC does not have connectivity with a writable domain controller when the lastlogontimestamp of a user must be updated as identified during a logon. To determine whether an account is stale, do the following:

1. Check a writable domain controller in the hub site to determine whether the account is stale. If a writable domain controller in the hub site indicates that lastLogonTimeStamp has not been updated recently, continue with the next steps. You must define for your own organization how recently an account must have logged on before the account is considered to be stale.

2. Check the msDS-RevealedListBL attribute for the account to determine which domain controller was used to authenticate the account. This is the back-link that corresponds to the msDS-RevealedList attribute that is maintained on an RODC account to get an accurate list of the accounts that are cached on that RODC.

3. If msDS-RevealedListBL indicates the distinguished name of one or more RODCs, try to connect to those RODCs and check whether the lastLogonTimeStamp has been updated on any of them but not yet replicated to a writable domain controller in the hub site.

You have to check lastlogonTimeStamp only on the RODCs that cache the user’s password because other RODCs have to forward any authentication request for that user to a writable domain controller in a hub site, on which lastLogonTimeStamp will be updated.

Resolving an account lockout problem in a branch office with an RODC

If the wide area network (WAN) link between the RODC and its writable replication partner is not available, the RODC can lock out an account that it has cached and the lockoutTime attribute will not be updated on the primary domain controller (PDC) emulator operations master and replicated to any other domain controllers. For more information about how the PDC emulator is updated with account lockout information, see How Operations Masters Work (https://go.microsoft.com/fwlink/?LinkId=147799).

To manually unlock the account in this situation, unlock the account on the writable domain controller that is the replication partner of the RODC. (Do this despite the fact that the account does not appear to be locked out on that domain controller.) As an alternative, you can unlock the account on the PDC emulator for the domain. When the user tries to log on—even if the unlock has not yet replicated to the RODC, a retry will happen on the PDC emulator, which ensures that the user can successfully access his computer.

However, when an account is locked out on a branch RODC while the WAN is offline, the account can be unlocked only when either the WAN comes back online or the lockout duration expires.

Complete the following procedure when you need to manually unlock an account that is locked out in a branch office that has an RODC.

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

To manually unlock an account in a branch office

1. Determine which site the user is in.

2. Determine which domain controller is the PDC emulator. To do this, run the following command at an elevated command prompt:

   netdom query fsmo

3. In the Active Directory Users and Computers snap-in, right click the domain, and then click Change Domain Controller to target the operation on the PDC emulator. If the PDC emulator is not available, change domain controllers to target the operation on the writable Windows Server 2008 domain controller that is the replication partner of the RODC or on another writable Windows Server 2008 domain controller in the site that is nearest to the site that has the RODC.

4. Type a new password for the user account, and then select the Unlock the user’s account check box.

Performing backups of an RODC

Windows Server 2008 includes a new backup application named Windows Server Backup. Windows Server Backup is not installed by default. You must install it by using the Add Features option in Server Manager before you can use the Wbadmin.exe command-line tool or Windows Server Backup on the Administrative Tools menu.

You can back up system state data on a domain controller that runs Windows Server 2008 only by using the Wbadmin.exe command-line tool. To back up a domain controller, use the wbadmin startsystemstatebackup command to back up system state data. If you use the wbadmin startsystemstatebackup command, the backup contains only system state data, which minimizes the size of the backup. This method provides system state data backups that are similar to the system state backups that the Ntbackup tool provides in previous versions of Windows Server.

As a best practice, create a backup volume on a dedicated internal or external hard drive. You cannot store a system state backup on a network shared drive. In addition, the target volume for a system state backup cannot be a source volume by default. A source volume is any volume that has a file that is included in the backup. To change that behavior, you can add the AllowSSBToAnyVolume registry entry to the server. You must also verify that the following prerequisites are met before you perform a system state backup to a critical volume:

• The volume that you use to store the system state backup must have twice the amount of free space as the size of the system state backup, until the backup completes.

• Make sure that the target volume has no shadow copy before the backup starts.

• If a system state backup is stored on a source volume, backup settings should be configured for full backups. By default, these settings are configured for full backups.

• Periodically check that no other user or program maintains a shadow copy on the target volume.

• Do not keep volume-level backups and system state backups in the same location.

For more information about adding the AllowSSBToAnyVolume registry entry, see Known Issues for AD DS Backup and Recovery (https://go.microsoft.com/fwlink/?LinkId=153623).

As an alternative to performing a system state backup, you can use the wbadmin start backup command with the -allcritical parameter or use Windows Server Backup to perform a backup of all critical volumes, rather than only backing up system state data. However, this method backs up all the critical volumes entirely, which can require more disk space than a system state backup. A volume is considered critical if any system state file is reported on that particular volume, such as the volumes that host the Active Directory database or SYSVOL.

For more information about backing up and restoring domain controllers that run Windows Server 2008, including how to schedule a regular full server backup, see the AD DS Backup and Recovery Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkID=93077).