Developer Guidance for Resolving Compatibility Problems Between Your Applications and an RODC
Applies To: Windows Server 2008
Be sure that you have categorized your applications appropriately before you proceed with these resolution steps.
Fixing ADSI applications
By default, ADSI applications locate a writable domain controller by calling the DsGetDcName function implicitly with the DS_WRITABLE_REQUIRED flag set. This behavior causes ADSI to look only for writable domain controllers. If ADSI does not find a writable domain controller that is available, default ADSI calls fail, even if they attempted only to read Active Directory data.
This behavior can cause inefficient Read operations, as described in Problem 1. In a branch office scenario, the Read application that uses default ADSI behavior reads all data from the hub site domain controller and does not use the RODC. This is shown in Figure 1.
In a perimeter network or extranet scenario, as shown in Figure 2, The Read application that uses default ADSI behavior fails because no connection to a writable domain controller is available.
To fix this problem, you can override the default behavior of ADSI by setting the ADS_READONLY_SERVER flag when you call the ADSI ADsOpenObject function. Doing so causes ADSI to look for both writable and read-only domain controllers.
The following table summarizes resolutions for ADSI applications.
Note
Overwrite the default behavior of ADSI only for Read applications and Read-Write applications.
| Type of application | Resolution for ADSI application |
|---|---|
Read application These applications only read data from AD DS. |
Set the ADS_READONLY_SERVER flag when you call the ADSI ADsOpenObject function. This causes ADSI to look for both writable and read-only domain controllers. |
Read-Write application These applications write and read data from AD DS. The Read operations are independent of the Write operations. Be sure that your application performs independent Read and Write operations. If Read operations depend on data that the application writes during Write operations, categorize the application as a Write-Read-Back application. |
Set the ADS_READONLY_SERVER flag when you call the ADSI ADsOpenObject function. This causes ADSI to look for both writable and read-only domain controllers. |
Write-Read-Back application These applications write data to AD DS and expect to read back the updated data. |
Call the ADSI ADsOpenObject function without any criteria. This causes ADSI to look only for a writable domain controller. ADSI then uses the same domain controller for Read operations. Do not set the ADS_READONLY_SERVER flag, which can cause the application to read data that has not been updated from the RODC instead of updated data. For example, assume that an application writes data to DC1, and that the Write operation succeeds. Then, the application attempts to read back the same data using RODC2. In this case, the Read operation can return data that has not yet been updated. |
Fixing LDAP applications
LDAP applications do not locate a domain controller automatically. Instead, they explicitly call DC Locator to find the domain controller. LDAP applications use the DsGetDcName function to locate a domain controller that matches your criteria. You can use the information in the following table to help you resolve issues with LDAP applications.
| Type of Application | Resolution for LDAP application |
|---|---|
Read application These applications only read data from AD DS. |
Do not set the DS_WRITABLE_REQUIRED flag when you call the DsGetDcName function. |
Read-Write application These applications write and read data from AD DS. The Read operations are independent of the Write operations. Be sure that your application performs independent Read and Write operations. If Read operations depend on data that AD DS writes during Write operations, categorize the application as Write-Read-Back application. |
You may decide to locate a writable domain controller for writing data and an RODC for reading data. When you use Read-Write applications in a branch office site, if you do not set the DS_WRITABLE_REQUIRED flag when you locate a domain controller to write data, you first contact an RODC in the site. As a result, the Write attempt on the RODC generates a Write referral, and you then have to chase referrals to a writable domain controller to write the data. Explicitly search for a writable domain controller whenever you have to write to AD DS; do not rely on LDAP referrals. |
Write-Read-Back: Applications which write data to AD DS and expect to read-back the updated data |
Set the DS_WRITABLE_REQUIRED flag when you locate a domain controller to write data. Then, be sure that you stick to the same domain controller to read the data. Doing so ensures that all of your Write operations and dependent Read operations contact the writable domain controller. |
The following illustration shows the resolution process for each type of directory-enabled application.
Figure 4 Resolution process for each type of directory-enabled application
.gif)
Additional resources
The following topics in the MSDN Library have additional information that can help you prepare your applications to work with an RODC:
Binding to Active Directory Domain Services (https://go.microsoft.com/fwlink/?LinkId=67636)
DsRoleGetPrimaryDomainInformation Function (https://go.microsoft.com/fwlink/?LinkId=67639).
You can use the DsRoleGetPrimaryDomainInformation function to determine if the domain controller is an RODC.
DsGetDcName Function (https://go.microsoft.com/fwlink/?LinkId=67640)
DOMAIN_CONTROLLER_INFO Structure (https://go.microsoft.com/fwlink/?LinkId=67641)
DC Locator returns a DOMAIN_CONTROLLER_INFO structure with two new flags. You can check these flags to see if your application is bound to a writable domain controller or to an RODC that is running Windows Server 2008.