Troubleshooting a DHCP Server

A look at the various reasons why a DHCP server might fail to lease IP addresses and the solutions to those problems.

If you use DHCP servers to automatically configure the TCP/IP settings for workstations in your organization, a DHCP failure can lead to a major disruption in service. After all, if a workstation is not able to acquire an IP address, then it will have no way of accessing any of the resources on your private network or on the Internet. In this article, I will discuss some techniques that you can use to troubleshoot DHCP server failures.

Inappropriate Address Assignment

One very common DHCP related issue is the assignment of an unexpected IP address. For example, suppose that your DHCP server was configured with an IP address scope of 192.168.0.1 to 192.1680.50. You would expect network hosts to be assigned IP addresses in this range. Now, suppose that a workstation on your network appeared to be having problems communicating with network servers. You issue an IPCONFIG /ALL command to view the workstation’s IP address configuration. Instead of the expected address range, the workstation has been assigned an address beginning with 169.254.

So what happened? If a host on your network is unexpectedly assigned an address beginning with 169.254, you can rest assured that the address was not assigned by your DHCP server. What actually has happened, is that the workstation has failed to contact a DHCP server. When this occurs, the workstation will assign itself an IP address using a Windows feature known as Automatic Private IP Addressing (APIPA).

Microsoft built Automatic Private IP Addressing into Windows as a way of helping those who have very small networks. For example, if you were to create a small Windows network, you would not have to manually configure IP addresses even if there were no DHCP server on the network. APIPA would automatically assign a unique class B IP address to each machine on the network. This is great for small home networks but completely inappropriate for larger networks.

If a workstation resorts to using an APIPA assigned address, it is because its requests for an IP address have gone unanswered. There are several possible causes for this problem. Assuming that the other computers on the network are able to acquire an IP address from your DHCP server, you can rule out the DHCP server as the cause of the problem.

More than likely, the issue is related to the networking hardware installed in the workstation that is having the problem. For example, the Network Interface Card might be assigned an incorrect driver. Another possible cause of the problem is that the patch cable is not plugged into the Network Interface Card, or is not connected to a switch on the other end.

Of course, just because only one computer on the network is having trouble obtaining an IP address doesn’t completely rule out the server as the cause of the problem. If other workstations are successfully obtaining IP addresses, then you can be sure that the server is working properly. However, it could be that the server has run out of IP addresses that it can assign to clients. You can easily tell if this is the problem by comparing the size of the DHCP address scope to the number of devices on your network that request IP addresses from the DHCP server.

Common DHCP Server Problems

If multiple workstations are experiencing problems with leasing IP addresses, then the problem is most likely related to the DHCP server itself. If you suspect that the DHCP server is the cause of the problem, then you might start off by doing some ping tests to verify that the DHCP server is able to communicate across the network.

If the DHCP server is able to communicate with other computers on the network, then I recommend verifying that the DHCP server has an IP address that is compatible with the scope that the server is configured to assign addresses from. For example, if the DHCP server’s scope consists of addresses from 192.168.0.1 to 192.168.0.50, then the server will not actually be able to assign those addresses unless the server itself has been assigned a static address in the same subnet range, such as 192.168.0.0 or 192.168.0.51.

 If this still doesn’t solve the problem, then I recommend checking the basics. For example, you should make sure that the DHCP server is still authorized by the Active Directory to lease IP addresses. You should also check to verify that the scope is active, and that the necessary services are running on the DHCP server.

IP Address Conflicts

Another problem that I have seen on occasions involves IP address conflicts among dynamically configured addresses. When you create a DHCP scope, it is the DHCP server’s responsibility to make sure that addresses within the scope are only leased to one client at a time. If that’s the case, then how is it possible to have an IP address conflict for dynamically assigned addresses?

There are two situations that I’ve run into that can cause this problem. The first time that I ever ran into this problem, I was able to determine which PCs had been assigned at the duplicate addresses. When I checked the TCP/IP configuration on those machines, I found that one of the machine’s IP addresses had been manually configured. It’s kind of a long story, but that machine’s user was running an unauthorized application that required a static IP address. The user got tired of having to reconfigure the application every time they used it, so they took the address that had been dynamically assigned to them, and entered it as a static address.

The likelihood of this happening today is fairly slim. When a particular situation occurred, Windows 98 was the current operating system. Windows 98 lacks many of the security features that we take for granted today. A properly secured workstation running Windows XP or Windows Vista should be resistant to end user reconfigurations. Even so, I wanted to at least mention this issue because it gives you something to look for if you have trouble solving the problem.

A much more common cause of this problem is that multiple DHCP servers are in use, and those DHCP servers have overlapping scopes. If you only have a single DHCP server on your network, do not make the mistake of immediately dismissing this idea as a possible cause of your problem. In all likelihood, there is probably a rogue DHCP server that is conflicting with your primary DHCP server.

Windows 2000 Server and Windows Server 2003 are both designed in such a way to prevent rogue DHCP servers from causing problems. A DHCP server can only issue IP addresses after it has been authorized by the Active Directory. The problem is that this only applies to Windows-based DHCP servers. DHCP servers running other operating systems are free to lease IP addresses to clients without having to be authorized by the Active Directory.

So has a user really gone through the trouble of installing a rogue, Linux based DHCP server? Probably not. A much more likely explanation is that a wireless access point, or a router intended for cable or DSL Internet connections is causing your problem. Such devices almost always have DHCP server’s built in. These devices typically use a scope range of 192.168.0.x or 192.168.1.x. If this happens to be the same IP address scope that your primary DHCP server uses, then you may run into a situation in which both DHCP servers are issuing addresses from the same address pool.

Conclusion

In this article, I’ve explained that there are a number of potential causes for DHCP failures. In most cases, these failures are related to simple communications problems between the DHCP server and the workstations that are trying to lease addresses.

Active Directory Migration From Windows Server 2003 To Server 2012

Create a Reverse Lookup DNS Zone in Windows Server 2003

Create reverse secondary lookup zone in Windows DNS

Windows Server 2012 Setting Up Active Directory Service and DNS

Step-By-Step: Adding a Windows Server 2012 Domain Controller to an Existing Windows Server 2003 network

1. Download Windows Server 2012 R2. If you plan on completing this Step-By-Step in a virtual lab, it is recommended to download the FREE Hyper-V Server 2012 R2 first.
2. Check to ensure the Domain Functional Level is currently setup to at least Windows 2003 mode. This is the lowest required Domain Functional Level that would allow a Windows Server 2012 Domain Controller installation. Windows NT / 2000 Domain Controllers are not supported via this process.

1. Via the Active Directory Users and Computers console, select the domain via the right mouse button on it. 
2. Select Raise Domain Functional Level and review the Current domain functional level reported
   
   
   The Domain Functional Level does not need to be raised if the Current domain functional level is reportingWindows Server 2003.
   
   NOTE: Should a lower domain be showcased (i.e., Windows Server 2000), please keep in mind that raising Domain Functional Level is a one time action and cannot be reverted. Remember Windows NT / 2000 Domain Controllers are not supported via this process.
3. Ensure your profile is a member of the Enterprise Admins group.

Getting Started

1. Setup and install your Windows Server 2012 machine
2. Configure the new server's IP address to correspond to the target domain and ensure the existing Domain Controllers, where DNS is installed and configured, are visible by your new Windows Server 2012 install.

Setting Up Domain Controller Fuctionality

1. Open the Server Manager console and click on Add roles and features
   
   
2. Select Role-based of featured-based installation and select Next.
   
   
3. Select the Active Directory Directory Services role.
   
   
4. Accept the default features required by clicking the Add Features button.
   
   
5. On the Features screen click the Next button.
6. On the Confirm installation selections screen click the Install button.
   
   NOTE: Check off the Restart the destination server automatically if required box to expedite the install should you be able to reset the target server automatically.
   
   
7. Click the Close button once the installation has been completed.
   
   
8. Once completed, notification is made available on the dashboard highlighted by an exclamation mark. Select it and amidst the drop down menu select Promote this server to a domain controller.
   
   
9. Select add a Domain Controller into existing domain
   
   
10. Ensure the target domain is specified.  If it is not, please either Select the proper domain or enter the proper domain in the field provided.
11. Click Change, provide the required Enterprise Administrator credentials and click the Next button.
12. Define if server should be a Domain Name System DNS server and Global Catalog (GC). Select the Site to which this DC belongs to and define Directory Services Restoration Mode (DSRM) password for this DC
    
    
13. Click the Next button on the DNS options screen.
14. In the Additional Options screen you are provided with the option to install the Domain Controller fromInstall From Media (IFM). Additionally you are provided the option to select the point from which DC replication should be completed. The server will choose the best location for AD database replication if not specified. Click the Next button once completed.
    
    
15. Specify location for AD database and SYSVOL and Click the Next button.
    
    
16. Next up is the Schema and Domain preparation.  Alternately, one could run Adprep prior to commencing these steps, Regardless, if Adprep is not detected, it will automatically be completed on your behalf.
    
    
17. Finally, the Review Options screen provides a summary of all of the selected options for server promotion. As an added bonus, when clicking View Script button you are provided with the PowerShell script to automate future installations. To click the Next button to continue.
    
    
18. Should all the prerequisites pass, click the Install button to start the installation.
    
    
19. After it completes the required tasks and the server restarts, the new Windows Server 2012 Domain Controller setup is completed.
20. Lastly, on each server/workstation within the target domain require a NIC properties configuration update to point to the new Domain Controller. Open the DHCP management console, select Option no. 006 and under server/scope options and add the IP address of your new Domain Controller as DNS server.
    
    

Should you see one of our #CANITPRO Step-By-Step posts in any social media venue, feel free to contribute thoughts and additional ideas.  Additionally, feel free to connect with us on any topic you would like to see covered. 

What workloads can you protect with Azure Site Recovery?

Azure Site Recovery enables customers to deploy application-aware availability solutions that contribute to your organization's business continuity and disaster recovery (BCDR) strategy. Whether it's Windows Server or Linux-based apps, Microsoft enterprise applications or offerings from other vendors, you can use Azure Site Recovery to enable disaster recovery, on-demand development and testing environments, and cloud migration.

Site Recovery integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server and Active Directory. Microsoft also works closely with leading vendors including Oracle, SAP, IBM and Red Hat to ensure their applications and services work well on Microsoft platforms such as Azure and Hyper-V. You can customize your disaster recovery solution for each specific application.

Key Features

Azure Site Recovery features that contribute to your application-level protection and recovery strategy include:

• Near-synchronous replication with RPOs as low as 30 seconds to meet the needs of most critical applications.
• App-consistent snapshots for single or N-tier applications.
• Integration with SQL Server AlwaysOn, and partnership with other application-level replication technologies, including AD replication, SQL AlwaysOn, Exchange Database Availability Groups (DAGs) and Oracle Data Guard.
• Flexible recovery plans that enable you to recover an entire application stack with a single click, and include external scripts or manual actions.
• Advanced network management in Site Recovery and Azure simplifies network requirements for an app, including reserving IP addresses, configuring load-balancers, or integration of Azure Traffic Manager for low RTO network switchovers.
• rich automation library that provides production-ready, application specific scripts that can be downloaded and integrated with Site Recovery.

Workload summary

Site Recovery replication technologies are compatible with any application running in a virtual machine. In addition we've done additional testing in partnership with application product teams to further support each app.

Workload	Replicate Hyper-V VMs (to a secondary site)	Replicate Hyper-V VMs (to Azure)	Replicate VMware VMs (to a secondary site)	Replicate VMware VMs (to Azure)
Active Directory, DNS	Y	Y	Y	Y
Web apps (IIS, SQL)	Y	Y	Y	Y
SCOM	Y	Y	Y	Y
Sharepoint	Y	Y	Y	Y
SAP Replicate SAP site to Azure for non cluster	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)
Exchange (non-DAG)	Y	Coming soon	Y	Y
Remote Desktop/VDI	Y	Y	Y	N/A
Linux (operating system and apps)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)
Dynamics AX	Y	Y	Y	Y
Dynamics CRM	Y	Coming soon	Y	Coming soon
Oracle	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)	Y (tested by Microsoft)
Windows File Server	Y	Y	Y	Y

Protect Active Directory and DNS

All enterprise applications such as SharePoint, Dynamics AX and SAP depend on an Active Directory and DNS infrastructure. As part of your BCDR solution you'll need to protect and recover these infrastructure components before recovering your workloads and apps.

Using Site Recovery you can create a complete automated disaster recovery plan for Active Directory and DNS. For example if you're using Active Directory for multiple applications such as SharePoint and SAP in your primary site and you want to fail over the complete site, you can fail Active Directory over first using a recovery plan, and then fail over the applications that rely on Active Directory using application-specific recovery plans.

Learn more

Protect SQL Server

SQL Server provides a foundation for data services for many business applications in an on-premises datacenter. Site Recovery and SQL Server HA/DR technologies are complementary and can be used together to provide end-to-end protection for multi-tiered enterprise applications. Site Recovery offers the following benefits for SQL Server environments:

• Easy protection and replication of standalone or clustered SQL servers to Azure or a secondary site. Provides a simple and cost-effective disaster recovery solution for many SQL Server versions and editions.
• Integration with SQL AlwaysOn Availability Groups, managing failover and failback processes with recovery plans in Azure Site Recovery.
• End-to-end recovery plans for the entire application stack, including the SQL Server databases.
• Scaling up of SQL Server for peak loads using Azure Site Recovery by “bursting” them into larger IaaS virtual machine sizes in Azure.
• Testing of SQL Server in Azure or a secondary site using Azure Site Recovery. Test failovers can be used for analytics data compliance checks without impacting your production environment.

Learn more

Protect SharePoint

Azure Site Recovery helps you to protect your SharePoint deployment. With Site Recovery you can:

• Eliminate the need and associated infrastructure cost for a stand-by farm for disaster recovery. With Site Recovery, you can enable protection of the entire farm (Web, app and database tiers) to Azure or to a secondary site.
• Simplify application deployment and manageability. Updates deployed to the primary site are automatically replicated, and will be available when the farm is recovered on the secondary site. This eliminates the management complexity of keeping a stand-by farm up-to-date, lowering costs.
• Simplify SharePoint application development and testing by creating a production-like copy on-demand replica environment for testing and debugging.
• Simplify transition to the cloud by using Site Recovery to migrate SharePoint deployments to Azure.

Learn more

Protect Dynamics AX

Azure Site Recovery helps you protect your Dynamics AX ERP solution:

• Enable protection of your entire Dynamics AX environment (Web and AOS tiers, database tiers, SharePoint) to Azure or to a secondary site using Site Recovery.
• Simplify migration to the cloud by using Site Recovery to migrate Dynamics AX deployments to Azure.
• Simplify Dynamics AX application development and testing by creating a production-like copy on-demand for testing and debugging.

Read more

Protect RDS

Remote Desktop Services enables virtual desktop infrastructure (VDI), session-based desktops, and applications, allowing users to work anywhere. With Site Recovery you can enable protection of managed or unmanaged pooled virtual desktops to a secondary site, and remote applications and sessions to a secondary site or Azure.

Learn more

Protect Exchange

Microsoft Exchange includes in-built support for high availability and disaster recovery. Exchange DAGs and Azure Site Recovery can work together.

• Exchange DAGs are the recommended solution for Exchange disaster recovery in an enterprise. Recovery plans in Site Recovery can include DAGs to orchestrate DAG failover across sites.
• For small deployments, such as a single or non-clustered servers, Site Recovery can protect and fail over to Azure or to a secondary site.

earn more

Protect SAP

Use Site Recovery to protect your SAP deployment:

• Enable protection of the entire SAP deployment with different layers to Azure or to a secondary site.
• Simplify cloud migration by using Site Recovery to migrate your SAP deployment to Azure.
• Simply SAP development and testing by creating a production-like copy on-demand for testing and debugging applications.

Protect Active Directory and DNS with Azure Site Recovery

Enterprise applications such as SharePoint, Dynamics AX and SAP depend on Active Directory and a DNS infrastructure to function correctly. When you create a disaster recovery solution for applications, it's important to remember that you need to protect and recover Active Directory and DNS before the other application components, to ensure that things function correctly when disaster occurs.

Site Recovery is an Azure service that provides disaster recovery by orchestrating replication, failover and recovery of virtual machines. Site Recovery supports a number of replication scenarios to consistently protect, and seamlessly failover virtual machines and applications to private, public or hoster clouds.

Using Site Recovery, you can create a complete automated disaster recovery plan for Active Directory. When disruptions occur, you can initiate a failover within seconds from anywhere in get Active Directory up and running in a few minutes. If you've deployed Active Directory for multiple applications such as SharePoint and SAP in your primary site, and you want to fail over the complete site, you can fail over Active Directory first using Site Recovery, and then fail over the other applications using application-specific recovery plans.

This article explains how to create a disaster recovery solution for Active Directory, how to perform planned, unplanned, and test failovers using a one-click recovery plan, the supported configurations, and prerequisites. You should be familiar with Active Directory and Azure Site Recovery before you start.

There are two recommended options based on the complexity of your environment.

Option 1

If you have a small number of applications and a single domain controller, and you want to fail over the entire site, then we recommend using Site Recovery to replicate the domain controller to the secondary site (whether you're failing over to Azure or to a secondary site). The same replicated virtual machine can be used for test failover too.

Option 2

If you have a large number of applications and there's more than one domain controller in the environment, or if you plan to fail over a few applications at a time, we recommend that in addition to replicating the domain controller virtual machine with Site Recovery you'll also set up an additional domain controller on the target site ( Azure or a secondary on-premises datacenter).

NOTE:

Even if you're implementing Option-2, for doing a test failover you'll still need to replicate the domain controller using Site Recovery. Read test failover considerations for more information.

The following sections explain how to enable protection for a domain controller in Site Recovery, and how to set up a domain controller in Azure.

Prerequisites

• An on-premises deployment of Active Directory and DNS server.
• An Azure Site Recovery Services vault in a Microsoft Azure subscription.
• If you're replicating to Azure run the Azure Virtual Machine Readiness Assessment tool on VMs to ensure they're compatible with Azure VMs and Azure Site Recovery Services.

Enable protection using Site Recovery

Protect the virtual machine

Enable protection of the domain controller/DNS virtual machine in Site Recovery. Configure Site Recovery settings based on the virtual machine type (Hyper-V or VMware). We recommend a crash consistent replication frequency of 15 minutes.

Configure virtual machine network settings

For the domain controller/DNS virtual machine, configure network settings in Site Recovery so that the VM will be attached to the right network after failover. For example if you're replicating Hyper-V VMs to Azure you can select the the VM in the VMM cloud or in the protect group to configure the network settings as shown below

Protect Active Directory with Active Directory replication

Site-to-site protection

Create a domain controller on the secondary site and specify the name of the same domain that is being used on the primary site when you premote the server to a domain controller role. You can use the Active Directory Sites and Services snap-in to configure settings on the site link object to which the sites are added. By configuring settings on a site link, you can control when replication occurs between two or more sites, and how often. See Scheduling Replication Between Sites for more details.

Site-to-Azure protection

Follow the instructions to create a domain controller in an Azure virtual network. When you promote the server to a domain controller role specify the same domain name that's used on the primary site.

Then reconfigure the DNS server for the virtual network, to use the DNS server in Azure.

Test failover considerations

Test failover occurs in a network that's isolated from production network so that there's no impact to production workloads.

Most applications also require the presence of a domain controller and a DNS server to function, so before the application's failed over, a domain controller needs be created in the isolated network to be used for test failover. The easiest way to do this is to enable protection on the domain controller/DNS virtual machine with Site Recovery, and run a test failover of that virtual machine, before running a test failover of the recovery plan for the application. Here's how you do that:

1. Enable protection in Site Recovery for the domain controller/DNS virtual machine.
2. Create an isolated network. Any virtual network created in Azure by default is isolated from other network. We recommend that the IP address range for this network is same as that of your production network. Don't enable site-to-site connectivity on this network.
3. Provide a DNS IP address in the network created, as the IP address that you expect the DNS virtual machine to get. If you're replicating to Azure then provide the IP address for the VM that will be used on failover in Target IP setting in VM properties. If you're replicating to another on-premises site and you're using DHCP follow the instructions to setup DNS and DHCP for test failover

NOTE:

The IP address allocated to a virtual machine during a test failover is same as the IP address it would get on during an planned or unplanned failover, if the IP address is available in the test failover network. If it isn't then the virtual machine receive a different IP address that is available in the test failover network.

1. On the domain controller virtual machine run a test failover of it in the isolated network.
2. Run a test failover for the application recovery plan.
3. After testing is complete, mark the test failover of job of domain controller virtual machine and the recovery plan 'Complete'on the Jobs tab in the Site Recovery portal.

DNS and domain controller on different machines

If DNS isn't on the same virtual machine as the domain controller you’ll need to create a DNS VM for the test failover. If they're on the same VM you can skip this section.

You can use a fresh DNS server and create all the required zones. For example, if your Active Directory domain is contoso.com, you can create a DNS zone with the name contoso.com. The entries corresponding to Active Directory must be updated in DNS, as follows:

1. Ensure these settings are in place before any other virtual machine in the recovery plan comes up:
   • The zone must be named after the forest root name.
   • The zone must be file backed.
   • The zone must be enabled for secure and non-secure updates.
   • The resolver of the domain controller virtual machine should point to the IP address of the DNS virtual machine.
2. Run the following command on domain controller virtual machine directory:
   nltest /dsregdns
3. Add a zone on the DNS server, allow non-secure updates, and add an entry for it to DNS:
   Copy to clipboardCopy

   dnscmd /zoneadd contoso.com  /Primary 
   dnscmd /recordadd contoso.com  contoso.com. SOA %computername%.contoso.com. hostmaster. 1 15 10 1 1 
   dnscmd /recordadd contoso.com %computername%  A <IP_OF_DNS_VM> 
   dnscmd /config contoso.com /allowupdate 1

How to completely design and setup an Active Directory Domain Infrastructure

In this guide I show you how to Completely design, and configure Active Directory for your business domain, in a Windows Server 2008 R2 environment. I cover everything from how to setup your LAN for static IP addressing and how to Implement a DHCP server to assign specific IP addresses to users and computer, how to enable Remote Desktop of each server, and the concepts of logging in with and using RDP.

Active Directory (ADDS) Installation & Configuration - Windows Server 2012

This video is a step by step guide demonstrating how to install and configure Active Directory Domain Services (ADDS) on a Windows 2012 Server to create a Domain Controller. A Domain Controller allows a network to be managed centrally from a single secure location.

Active Directory Replication Considerations

Applies To: Windows Server 2008

Domain controllers running Windows Server 2008 can replicate Active Directory database partitions as listed in the following table. Although an RODC can replicate data from domain controllers running Windows Server 2003, it can replicate updates of the domain partition only from a domain controller running Windows Server 2008 from the same domain. RODCs cannot be a source domain controller for any other domain controller because they cannot perform outbound replication. Application directory partitions include ForestDNSZones and DomainDNSZones.

 

Destination domain controller	Windows Server 2003 source domain controller	Writable Windows Server 2008 source domain controller
Windows Server 2003	Schema Configuration Domain Application directory partitions Partial attribute set of the other domain partitions in the forest (global catalog)	Schema Configuration Domain Application directory partitions Partial attribute set of the other domain partitions in the forest (global catalog)
Writable Windows Server 2008	Schema Configuration Domain Application directory partitions Partial attribute set of the other domain partitions in the forest (global catalog)	Schema Configuration Domain Application directory partitions Partial attribute set of the other domain partitions in the forest (global catalog)
RODC	Schema Configuration Application directory partitions Partial attribute set of the other domain partitions in the forest (global catalog)	Schema Configuration Domain Application directory partitions Partial attribute set of the other domain partitions in the forest (global catalog)

Writable domain controllers running Windows Server 2008 and domain controllers running Windows Server 2003 can perform inbound and outbound replication of all available partitions. Therefore, they do not require the same placement considerations that RODCs require.

Because an RODC can replicate the domain partition only from a writable domain controller running Windows Server 2008, the placement of each becomes important and requires careful planning. The placement of an RODC and writable domain controllers running Windows Server 2008 might be affected by the site topology and network constraints.

Each RODC requires a writable domain controller running Windows Server 2008 for the same domain from which the RODC can directly replicate. Typically, this requires that a writable domain controller running Windows Server 2008 be placed in the nearest site in the topology. The nearest site in this sense is defined as the site that has the lowest-cost site link for the site that includes the RODC.

For example, suppose you have Sites A, B, and C with site links A – B and B – C and the Bridge all site links option is disabled, as shown in the following figure. In order to put an RODC in Site C, a domain controller running Windows Server 2008 for the same domain should be placed in Site B to replicate the domain partition to the RODC. Placing only a domain controller running Windows Server 2003 in Site B would permit the RODC in Site C to replicate the schema, configuration, and application directory partitions, but not the domain partition.

If the Bridge all site links option is enabled, as shown in the next figure, a domain controller running Windows Server 2008 could be placed in Site A rather than Site B. This is because physical connectivity between Site A and Site C is now implicitly available.

Generally, the introduction of an RODC should require minimal, if any, replication topology changes. For example, consider a multitier replication topology where:

• The Bridge all site links option is disabled.
  
• RODCs are placed in tail sites.
  
• Writable domain controllers running Windows Server 2008 are placed in the hub site.
  

This is shown in the following figure. In this case, you might create additional site links between the hub site and the tail sites to accommodate the need for direct replication between the RODC and the writable domain controller running Windows Server 2008.

For more information about the Active Directory replication topology and Bridge all site links option, see How Active Directory Replication