Share via

Planning for Application Compatibility with RODCs

  • Article

Applies To: Windows Server 2008, Windows Server 2012

Because most Active Directory–enabled applications are read intensive, they continue to work regardless of whether the directory is writable. Therefore, these applications are not affected by the introduction of read-only domain controllers (RODCs) into the environment. Infrastructure applications and services, such as Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP), also typically work well with read-only directory data. For a list of applications and services that are known to work with RODCs, see Applications That Are Known to Work with RODCs (https://go.microsoft.com/fwlink/?LinkID=119953).

However, introducing RODCs into enterprise environments can affect some applications that interact with Active Directory Domain Services (AD DS). Organizations that deploy RODCs can test how their applications are affected in scenarios in which the applications may interact with an RODC in the site rather than with a conventional, writable domain controller. Organizations can also test their applications in scenarios in which connectivity between the RODC and the writable domain controller may, or may 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 DMZ and screened subnet) or an extranet scenario where connectivity to a writable domain controller is restricted. You can refer to the following illustrations as you review guidelines later in this document for testing your applications and resolving problems that applications may have when they interact with RODCs.

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 domain controller Locator (DC Locator) to search for and connect to a domain controller for reading or writing data.

Note

Certain applications can also target a specific domain controller, for example, by its name or IP address. If these applications continue to target a writable domain controller, they are not affected by an RODC. As a best practice, however, make sure that your applications use DC Locator.

In ADSI, the DsGetDcName function of DC Locator is called implicitly, a process that 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 that matches the criteria, such as a global catalog server or a domain controller that holds the primary domain controller (PDC) emulator master operations (also known as flexible single master operations or FSMO) role. The application then connects to that domain controller 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).

Note

WAN availability can also affect client computer operations in other complex deployments, such as scenarios in which an RODC is deployed in the same site as a writable domain controller. For more information, see Appendix A: RODC Technical Reference Topics.

Impact of RODC on directory-enabled applications

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

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

Note

If an application runs under the LocalSystem security context on a domain controller, it has reduced privileges when it runs on an RODC. This is because an application that runs under the LocalSystem security context on a computer uses the credentials of that computer's domain account. The domain account for an RODC has reduced privileges.

Problem 1: Inefficient or failed Read operations

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

For example, assume that an application 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—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.

Important

Be sure to configure your applications that only read data from AD DS to use the closest domain controller, regardless of whether that domain controller is a writable domain controller or an RODC.

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 (https://go.microsoft.com/fwlink/?LinkId=119960).

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 a branch office scenario, if connectivity to a writable domain controller is not available, 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, 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.

Testing application compatibility for RODCs

Before you deploy an RODC in a branch office, perimeter network, or extranet, perform the following steps to test all your directory-enabled applications in the site for compatibility with an RODC.

Step 1: Set up the test environment

Set up your test environment according to the topology in the following figure.

Perform the following steps to set up the test environment:

  1. Install a writable domain controller that runs Windows Server 2008.

  2. Install the DNS Server service on the domain controller.

    For more information, see Installing a New Windows Server 2008 Forest by Using the Windows Interface (https://go.microsoft.com/fwlink/?LinkId=100511). For this test, the domain controller can remain in the Default-First-Site-Name site, where it is installed by default.

  3. Use the Active Directory Sites and Services snap-in to create a new site.

    For example, create a new site named Branch.

  4. Add the Branch site to the DEFAULTIPSITELINK site link object.

    DEFAULTIPSITELINK is the name of the first site link, which is created in AD DS by default. You must add the Branch site to this site link to enable replication between the RODC and the writable domain controller that you installed in step 1 of this procedure.

  5. Install an RODC in the Branch site.

    For more information, see Installing an Additional Windows Server 2008 Domain Controller (https://go.microsoft.com/fwlink/?LinkId=93254).

  6. If necessary, configure rules for firewalls that exist between the sites.

  7. Join client computers to the domain, and then move the client computer objects to the Branch site, if necessary.

  8. Install the applications in the Branch site.

Step 2: Categorize the applications

Determine how your applications interact with AD DS, and then categorize them based on how your organization uses them and the types of operations that your applications perform. You can use the categories in the following table as a reference.

Application type Description

Read application

An application that only reads data from AD DS. In this category, you might also include an application that writes data to AD DS, if you do not care whether Write operations fail. For example, assume that you have an application that performs Read operations for 99.9 percent of its operations and Write operations for 0.1 percent of its operations. If you are not concerned that a few Write operations will fail when a writable domain controller is not available, you might consider the application to be a Read application.

Read-Write application

An application that writes and reads data from AD DS, where the Read operations are independent of the Write operations. For this application type, be sure that your application performs independent Read and Write operations. If Read operations depend on the data written during Write operations, categorize the application as a Write-Read-Back application.

Write-Read-Back application

An application that writes data to AD DS and expects to read back the updated data.

Step 3: Test your application

Perform the following steps as needed to help you determine how to categorize and test your applications:

  1. Deploy the application on the application server.

  2. Test the application using the test plan that you created for it.

    The following table shows the results of tests that you can run to help you categorize your applications by type.

    Type of application Test Expected result

    Read application

    Disconnect the writable domain controller.

    All directory operations should pass.

    Read-Write application

    Disconnect the writable domain controller, and then reconnect it.

    When you disconnect the writable domain controller, the Read operations should pass and the Write operations should fail.

    When you reconnect the controller, all directory operations should pass and all Read operations should be optimized. In other words, the Read operations should be targeted to the closest domain controller, regardless of whether it is writable or read-only.

    Write-Read-Back application

    Disconnect the writable domain controller.

    All directory operations should fail.

Step 4: Fix broken or inefficient applications

Identify applications that do not provide the expected result because these applications will either be broken or inefficient in an RODC environment. For information about fixing custom applications, see Developer guidance for resolving compatibility problems between your applications and an RODC (https://go.microsoft.com/fwlink/?LinkID=119960). For information about fixing other applications, contact the independent software vendor (ISV) or developers for those applications and provide them with details of the problem based on your tests. They can use the same resolution steps that are described in this guide.