Application Compatibility with RODCs

Applies To: Windows Server 2008

Because most Active Directory–enabled applications are read-intensive, they continue to work regardless of whether the directory is writable. Therefore, they are not affected by the introduction of RODCs into the environment. Infrastructure applications and services, such as DNS and DHCP, also typically work well with read-only directory data.

However, introducing RODCs into enterprise environments can affect some applications that interact with AD DS. Organizations that deploy RODCs can test how their applications are affected in scenarios where the applications may interact with an RODC in the site rather than a conventional, writable domain controller. They can also test their application in scenarios where connectivity between the RODC and the writable domain controller might, or might not, be available.

The following illustrations depict these scenarios. The first scenario is a typical branch office deployment in which the branch site has routine communication with the hub site. The second scenario is a perimeter network (also known as demilitarized zone and screened subnet) or an extranet scenario where connectivity to a writable domain controller is restricted. You can refer to the following figures as you review guidelines later in this document for testing your applications and resolving problems that applications have when they interact with RODCs.

Figure 1   In a branch office scenario, applications have access to a writable domain controller over a wide area network (WAN) link

Figure 2   In an extranet or perimeter network scenario, or a scenario where the WAN is offline and applications do not have access to a writable domain controller

Directory-enabled applications

Directory-enabled applications that are built with Microsoft technologies primarily use the following types of technologies:

• Active Directory Service Interfaces (ADSI)

  These applications use unmanaged ADSI providers and a managed System.DirectoryServices namespace.

  For more information about unmanaged ADSI providers, see ADSI Service Providers (https://go.microsoft.com/fwlink/?LinkId=100501).

  For more information about the System.DirectoryServices namespace, see System.DirectoryServices Namespace (https://go.microsoft.com/fwlink/?LinkId=100502).

• Lightweight Directory Access Protocol (LDAP) application programming interfaces (APIs)

  These applications use unmanaged WLDAP32 and a managed System.DirectoryServices.Protocols namespace.

  For more information about unmanaged WLDAP32, see Lightweight Directory Access Protocol (https://go.microsoft.com/fwlink/?LinkId=99560).

  For more information about the managed System.DirectoryServices.Protocols namespace, see System.DirectoryServices.Protocols Namespace (https://go.microsoft.com/fwlink/?LinkId=100504).

Directory-enabled applications use the DsGetDcName function of DC Locator to search for and connect to a domain controller for reading or writing data.

In ADSI, the DsGetDcName function of DC Locator is called implicitly, a process which is known as serverless binding. For an LDAP application, the application developer calls DsGetDcName explicitly. Depending on the parameters that you set, DsGetDcName searches for a domain controller on the network that matches the criteria, such as a global catalog server or Primary Domain Controller (PDC) emulator. The application then connects to it to perform the desired operations.

For more information about DC Locator, see Directory Service Functions (https://go.microsoft.com/fwlink/?LinkId=100506).

For more information about DsGetDcName, see DsGetDcName Function (https://go.microsoft.com/fwlink/?LinkId=100509).

For more information about serverless binding, see Serverless Binding and RootDSE (https://go.microsoft.com/fwlink/?LinkId=67638)

Impact of RODC on directory-enabled applications

Although ADSI and LDAP applications both use the same DsGetDcName function, each type of application can connect to a different type of domain controller by default. In other words, an ADSI application searches for, and connects to, a writable domain controller by default. In contrast, an LDAP application searches for and connects to either a writable or read-only domain controller by default.

This default behavior can lead to the following problems for directory-enabled applications when they interact with an RODC:

• Problem 1: Inefficient or failed Read operations

• Problem 2: Failed Write operations

• Problem 3: Failed Write-Read-Back operations

Problem 1: Inefficient or failed Read operations

An inefficient or failed Read operation occurs when an application does not target an RODC because it is read-only, regardless of whether it is the closest domain controller.

For example, assume that an application that is shown in Figure 1 only reads data from AD DS, and that this data is present on the RODC in the site to be read. If the application is configured to always locate a writable domain controller for directory operations, as ADSI applications do by default, then the application reads data over the WAN link from the writable domain controller in the hub site. In this case, the application disregards the RODC and does not use it for Read operations. This results in inefficient Read operations when the WAN is online and failed Read operations when the WAN is offline.

Although LDAP applications, by default, use the closest domain controller, ADSI applications, by default, target only writable domain controllers. Therefore, you might have to resolve inefficient Read operations for ADSI applications that can interact with RODCs that you deploy. For more information, see Developer Guidance for Resolving Compatibility Problems Between Your Applications and an RODC later in this document.

Problem 2: Failed Write operations

In an extranet or perimeter network scenario, Write operations fail. However, in a branch office scenario, when an application contacts an RODC to attempt a Write operation, the RODC, by default, returns a referral to a writable domain controller. The application must respond to the referral and then use the information that it receives to locate a writable domain controller. Although an ADSI application chases the referral automatically, a developer must configure an LDAP application to chase the Write referral. This configuration is called an LDAP_Write_Referral.

In the branch office scenario, if connectivity to a writable domain controller is not available, then Write operations fail regardless of whether the application uses LDAP or ADSI, and no additional configuration helps.

Problem 3: Failed Write-Read-Back operations

A failed Write-Read-Back operation occurs when an application writes data to one domain controller, and then attempts to read the same data on a different domain controller. In this case, the application does not read the updated data because that data has not yet replicated to the domain controller that the application targeted for the Read operation. The introduction of RODCs makes this problem more prominent because you might not be able to determine which writable domain controller was returned in the referral.

For example, assume that an application that is shown in Figure 1 writes data to AD DS and then reads back the same data. If this application expects the updated data to be available for a Write-Read-Back operation, then it should target the writable domain controller for both Write and Read operations. If the application does not explicitly stick to the writable domain controller for both Write and Read operations, it might read data that has not been updated from the RODC because of the replication latency between the hub domain controller and the RODC.

If your applications write data to AD DS, and then expect to read back the updated data, be sure to explicitly locate a writable domain controller to write the data, and then stick to the same domain controller to read back the same data.