Known Issues for Deploying RODCs

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

This topic explains which client operating systems are compatible with read-only domain controllers (RODCs) and known issues for RODCs. Many of the issues in this topic are resolved if you apply the RODC compatibility pack for Windows Server 2003 clients and for Windows XP clients. This compatibility pack is a cumulative hotfix that you can apply to client computers that interact with RODCs that run Windows Server 2008 or Windows Server 2008 R2. To obtain the RODC compatibility pack, see article 944043 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=120375). If you cannot apply the hotfix in a particular situation, you can try an alternative workaround.

The following sections are included in this topic:

• Client operating systems that are compatible with RODCs

• Apply the RODC compatibility pack or plan a workaround for any known issue

• Adprep /rodcprep will log an error if the infrastructure master for an application directory partition is not available

• Use NETDOM Computername /add to rename an RODC

• Repadmin /PRP might return only a subset of accounts

• Event ID 2916 appears when a Windows Server 2008 R2 RODC is installed in a domain that has no writable domain controllers that run Windows Server 2008 R2

• Event ID 1699 is logged many times on a writeable domain controller that runs Windows Server 2008 when a security principal that cannot be cached tries to authenticate to an RODC

Client operating systems that are compatible with RODCs

Client computers running any of the following operating systems are supported for use with RODCs.

Apply the RODC compatibility pack or plan a workaround for any known issue

For client computers that interact with an RODC, you can apply a cumulative hotfix that addresses all the issues in the following table. The hotfix is available in article 944043 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=120375). However, you do not necessarily have to apply the hotfix before you can deploy an RODC. In many cases, you might find that an issue does not affect your deployment, or you might be able to implement a workaround rather than apply the hotfix.

The following table explains each issue, the types of clients and the RODC deployment scenario that are affected by the issue, the potential impact of the issue, and a workaround if you cannot apply a hotfix to address the issue. Consider each issue with regard to the specific rules and policies that your organization has for its network. For some networks, a suggested workaround might not be acceptable.

In general, you do not have to apply updates to any other domain controllers to get them to work with RODCs. The one exception is for domain controllers that run Windows Server 2003 and perform automatic site coverage for sites with RODCs. When domain controllers perform automatic site coverage, they register records in DNS in order to cover authentication requests in other sites that do not have a domain controller. Because Windows Server 2003 domain controllers do not recognize RODCs, they can perform automatic site coverage for sites that have RODCs. In this case, you have to apply the hotfix to any Windows Server 2003 domain controller that performs the automatic site coverage if you cannot implement one of the workarounds that is suggested in the table.

If an issue is about an RODC deployment scenario that does not pertain to your environment, you can disregard it. For example, the issue about domain join failures that target an RODC only affects scenarios in which a firewall is configured tightly between the RODC site and the site that contains the writable domain controller. If you are not deploying an RODC in a similar configuration, you can disregard that issue.

If you do face one of the following issues and you cannot implement the workaround, you must apply the hotfix.

Issue	Affects …	Impact	Workaround
Group Policy fails to access Windows Management Instrumentation (WMI) filters on an RODC.	Client computers in the RODC site	If an RODC is available but a writable domain controller is not available, Group Policy fails to access any WMI filters and does not apply any Group Policy object (GPO) to which the WMI filters are linked. Failure to access WMI filters may prevent affected clients from applying intended Group Policy or cause those clients to improperly apply Group Policy that an administrator might have intended the WMI filter to exclude.	There is no workaround for this issue.
Internet Protocol security (IPsec) policies fail to apply from an RODC.	Client computers in the RODC site (branch office scenario)	Attempts by Windows Server 2003 and Windows XP member computers to apply IPsec policies from RODCs fail with Win32 error 8219 (ERROR_POLICY_OBJECT_NOT_FOUND). The same member computers can successfully apply policy from writable domain controllers. You may encounter this scenario when network connectivity for IPsec clients has been limited to Active Directory sites that contain RODCs but no writable domain controllers.	There is no workaround for this issue.
The Windows Time service (W32time) in Windows XP and Windows Server 2003 does not recognize an RODC.	Client computers in the RODC site (branch office and perimeter network (also known as DMZ) scenarios)	The affected client computers will not synchronize time with the RODC during authentication. When the time service gets out of sync, users can receive errors when they attempt to access resources on the network.	You can configure the client computers to synchronize time from another domain controller on the network if one is available.
Unsecure domain join fails	Client computers in the RODC site (perimeter network scenario)	In a perimeter network scenario where an RODC is available but a writable domain controller is not available, unsecure domain joins will fail. Unsecure domain joins are performed by Active Directory Migration Tool (ADMT) and Windows Deployments Service (WDS).	There is no workaround for this issue
Domain join using RODC in the perimeter network fails.	Client computers in the RODC site (perimeter network scenario)	In a perimeter network scenario where an RODC is available but a writable domain controller is not available, domain joins will fail even if the computer account and password are prepopulated on the RODC.	You can create firewall rules to allow a writable domain controller to be contacted for the domain join operation, or you can bridge the perimeter and intranet networks. However, most firewall administrators do not allow these options. In that case, you must apply the hotfix or determine a more suitable workaround for your network.
Password changes fail in the perimeter network when only an RODC is available.	Client computers in the RODC site (perimeter network scenario)	In a perimeter network scenario in which an RODC is available but a writable domain controller is not available, password changes that are initiated from a computer that runs Windows XP, Windows Server 2003, or Windows 2000 will fail. This is true if the user initiates the password change by pressing Ctrl+Alt+Del or if an administrator selects the option that the user must change the password during the next logon, for example, when the administrator creates a new user account.	You can create firewall rules that allow a writable domain controller to be contacted for the password change request, you can change the password from within the intranet, or you can perform the password change from a client computer that runs Windows Vista or Windows Server 2008.
The RODC fails to retrieve or create a public key certificate.	Client computers in the RODC site (branch office and perimeter network scenarios)	The Data Protection Application Programming Interface (DPAPI) on client computers that only have access to an RODC cannot decrypt master keys unless they have previously contacted a writable domain controller and retrieved a public key certificate. Clients that only have access to an RODC cannot decrypt master keys. Without this fix, even if a writable controller is available, DPAPI on clients may fail to decrypt master keys if the closest domain controller is an RODC.	When DPAPI attempts to decrypt master keys, ensure that the client has access only to a writable domain controller. DPAPI attempts to decrypt master keys during password changes.
Spooler does not reflect the correct printer publish state.	Client computers in the RODC site (branch office scenario)	If an RODC services a client request to publish a printer, it forwards the request to a writable domain controller. The spooler attempts to read from the RODC immediately after the write. The information has not yet been replicated to the RODC, and spooler fails the publish operation. All spooler internal structures are updated, and the printer is marked as unpublished.	There is no workaround for this issue.
The Find Printer user interface (UI) hangs when a computer that runs Windows XP or Windows Server 2003 can contact an RODC but not a writable domain controller.	Client computers in the RODC site (branch office scenario)	Users will not be able to find printers that are published in AD DS.	There is no workaround for this issue.
Active Directory Service Interfaces (ADSI) in Windows XP and Windows Server 2003 requests a remote writable domain controller instead of a local RODC.	Client computers in the RODC site (branch office scenario)	ADSI calls from Windows XP and Windows Server 2003 client computers are directed to a writable domain controller even if an RODC is in the same site as the client. This can cause unnecessary wide area network (WAN) traffic to a writable domain controller in a remote site.	Ensure that these client computers have connectivity to a writable domain controller when they make ADSI calls, even for read-only operations. ADSI calls to the writable domain controller will create additional WAN traffic.
Domain controllers running Windows Server 2003 perform automatic site coverage for sites with RODCs.	Windows Server 2003 domain controllers that provide automatic site coverage for other branch office sites (branch office scenario)	A domain controller running Windows Server 2003 may register its Domain Name System (DNS) service (SRV) resource records for a site that contains an RODC. Consequently, client computers that attempt to discover a domain controller in the RODC site can also find the domain controller that is running Windows Server 2003. As a result, they might not authenticate with the RODC as desired.	Note This issue is unlike other issues listed in this table. For other issues, if you do not implement a suggested workaround, you apply the hotfix from article 944043 to clients that interact with an RODC. For this issue, if you do not implement a suggested workaround, you apply the hotfix to Windows Server 2003 domain controllers that are performing automatic site coverage for sites that contain an RODC. You can implement these workarounds if you do not want to apply the hotfix: Ensure that only domain controllers running Windows Server 2008 are present in the site that is closest to the RODC site. Disable automatic site coverage on domain controllers running Windows Server 2003. For more information about how to disable automatic site coverage, see Domain Controllers Running Windows Server 2003 Perform Automatic Site Coverage for Sites with RODCs (https://go.microsoft.com/fwlink/?LinkId=191990).

Adprep /rodcprep will log an error if the infrastructure master for an application directory partition is not available

If the domain controller that holds the infrastructure operations master (also known as flexible single master operations or FSMO) role for an application directory partition is not available when you run the adprep /rodcprep command to prepare a forest for an RODC, the command can return an error. The error is logged in the Adprep.log file, and it indicates that Adprep failed an operation on the application directory partition that is named in the error. By default, domain controllers have application directory partitions for DNS.

The infrastructure operations master role holder for each application directory partition must be online when you run adprep /rodcprep. If the role holder is not online, which could happen if the domain controller that hosted the role was forcefully demoted without performing metadata cleanup, then adprep /rodcprep can log the error.

For more information about fixing this issue, see article 949257 in the Microsoft Knowledge base (https://go.microsoft.com/fwlink/?LinkID=114419).

Use NETDOM Computername /add to rename an RODC

There are two ways to use Netdom.exe in order to rename a domain controller:

1. Use Netdom computername OldName /add: NewName

   This is the preferred method to rename a writeable or read-only domain controller because the addition can replicate throughout the forest before the original name is deleted.

2. Use netdom renamecomputer OldName /newname:NewName

   This method works only for a writable domain controller. On a read-only domain controller, the operation fails with an error that says “the requested operation is not supported.”

Repadmin /PRP might return only a subset of accounts

If you have a large number of accounts cached for an RODC that runs Windows Server 2008, such as thousands of accounts, you might see that only a subset of the cached accounts are returned when you run the repadmin /prp view <RODC> reveal command. When a server retrieves an attribute from AD DS that has many entries, the server requests as many entries as AD DS can return at one time. If the initial request returns only a partial list of the entries for the attribute, the server is supposed to trigger additional requests for the remaining entries. When you run the repadmin /prp view <RODC> reveal command for an RODC that runs Windows Server 2008, it does not make the additional requests for remaining entries.

This issue does not affect RODCs that run Windows Server 2008 R2.

Event ID 2916 appears when a Windows Server 2008 R2 RODC is installed in a domain that has no writable domain controllers that run Windows Server 2008 R2

When an RODC that runs Windows Server 2008 R2 is installed in a domain that does not have a writable domain controller that runs Windows Server 2008 R2, the RODC logs Event ID 2916 in the Directory Services log in Event Viewer. You can safely disregard this event, but it will continue to appear until you add a writable domain controller that runs Windows Server 2008 R2 to the domain.

The error appears because the RODC is attempting to write the value of the msDSBehaviorVersion attribute for its own NTDS Settings object on a writable domain controller. Only writable domain controllers that run Windows Server 2008 R2 allow the write operation.

You can safely disregard the event because the value of 4 for the msDSBehaviorVersion of the NTDS Settings object of the RODC is used only when the functional level of the domain or forest is being raised to Windows Server 2008 R2. Because the domain has no writable domain controllers that run Windows Server 2008 R2, the functional level cannot be raised to Windows Server 2008 R2.

Event ID 1699 is logged many times on a writeable domain controller that runs Windows Server 2008 when a security principal that cannot be cached tries to authenticate to an RODC

When a security principal that cannot be cached tries to log on and the authentication request is performed by an RODC, the RODC forwards the request to a writeable domain controller and then tries to cache the secrets for the security principal. If the writable domain controller is running Windows Server 2008 and has not yet installed Service Pack 2, it logs Event ID 1699 in the Directory Services log to indicate that it was unable to send change request to the RODC. The behavior is by design but the Event ID 1699 can fill up the Directory Services log on the writable domain controller if there are many such authentication attempts.

To prevent the event from appearing, you can install the hotfix in article 953392 (https://go.microsoft.com/fwlink/?LinkId=198008). This issue is fixed in Windows Server 2008 with Service Pack 2 and later and in Windows Server 2008 R2.