Testing Application Compatibility with RODCs
Applies To: Windows Server 2008
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 RODC.
Step 1: Set up the test environment
Set up your test environment according to the topology in the following figure.
Figure 3 The setup for testing whether an application is compatible with an RODC
Perform the following steps to set up the test environment:
Install a writable domain controller that runs Windows Server 2008.
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.
Use Active Directory Sites and Services to create a new site.
For example, create a new site named Branch site.
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.
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).
If necessary, configure rules for firewalls that exist between the sites.
Join client computers to the domain, and then move the client computer objects to the Branch site, if necessary.
Install the applications into 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.
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% 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, then you might consider the application to be a Read 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.
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:
Deploy the application on the application server.
Test the application using the test plan that you created for it. (Creating a test plan for each application is outside the scope of this guide.)
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
Disconnect the writable domain controller.
All directory operations should pass.
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.
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 be inefficient in an RODC environment. For information on fixing custom applications, see Developer Guidance for Resolving Compatibility Problems Between Your Applications and an RODC. For information on 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.