Establishing connectivity with a company's branch offices doesn't seem like a big deal at first glance. After all,...
an admin can easily configure the computers in the branch office to act as a separate domain within the corporate forest. The WAN link between the branch office in the corporate headquarters would provide the necessary connectivity.
Although this particular approach would work, it is grossly oversimplified. Branch office networking is tricky.
Same domain, same site
There are many ways to provide connectivity to users in a branch office. One type of deployment involves placing the computers at the branch office into the same domain and same site as the computers at the corporate headquarters.
The big advantage to this approach is that it's simple to configure. As long as TCP/IP connectivity exists between the branch office and the corporate headquarters, connecting PCs in the branch office to the domain is no more difficult than it would be if they were located in the corporate headquarters.
The downside is that if the WAN link should fail, the workstations in the branch office will be cut off from the corporate office. Users won't even be able to log in (unless they use cached credentials) because there will be no domain controller available to them.
Place the remote site in its wwn domain
You don't want a link failure to prevent users from logging into the network. So it might seem like the obvious solution to this problem is to place a domain controller in the branch office. Doing this would give you the options of making the branch office its own domain or of making it a part of one of the domains that already exist at headquarters. Let's talk about the pros and cons of setting up the branch office as its own domain.
The main advantage of this approach is that the office's network becomes almost a separate entity. Assuming you set the new domain up correctly, you won't have to worry about a link failure preventing users from logging into the network.
The disadvantage to this approach is increased administrative overhead. Instead of having to manage one domain, you have to manage two. Also, some of your day-to-day administrative tasks will become more time- consuming. For example, when you add a new folder to a file server, you may have to spend a little more time setting up the access control entries, since you'll have to set up separate access control entries for security groups from each domain.
Same domain, different site
Another approach is to place a domain controller in the branch office, but make that domain controller part of the domain at the corporate headquarters. If you were to use this type of topology, you'd want to place the domain controller at the branch office into a separate Active Directory site.
Creating multiple sites requires more work up front, but usually does not require any extra ongoing administrative work. Using multiple sites reduces the amount of Active Directory replication traffic flowing across your WAN link, thus allowing the link to function more efficiently.
Considerations for domain controller placement
If you don't have at least one domain controller in the branch office, a link failure can prevent users from logging into the network. So far I've shown you two ways to avoid this problem by placing a domain controller in a branch office. But even if there is a domain controller in the branch office, a link failure can still keep users from being able to log into the network.
This is because domain controllers have dependencies. For example, the Active Directory is dependent upon the existence of a DNS server. By default, the first domain controller in the forest is automatically configured to act as a DNS server (assuming a DNS server doesn't already exist). But this doesn't do the users in your branch offices much good if a link fails and they cannot access the DNS server.
But because DNS is hierarchical in nature, the easiest solution to this problem is to configure the domain controller in the branch office to act as a DNS server. Assuming your DNS server is integrated into Active Directory, you could configure the DNS server at the branch office to act as a secondary DNS. This means that the DNS server will receive records from the primary DNS server in the main office. Computers in the branch office would be configured to use the DNS server located in the branch office, rather than the primary DNS server.
This approach accomplishes two things.
- Configuring clients to use a local DNS server ensures that the DNS services will always be available, even if there is a link failure.
- This type of architecture reduces the number of name resolution requests that your primary DNS server has to process. It also reduces DNS-related traffic flowing across the WAN link.
Global catalog servers
Another Active Directory dependency is that workstations require access to a global catalog server. A global catalog server is a domain controller responsible for maintaining a master list of all of the objects (users, computers, etc.) in the Active Directory. If a workstation is unable to access a global catalog server, only Administrators are allowed to log in.
By default, the first domain controller brought online in the forest is configured to act as the domain's global catalog server. However, you can designate any other domain controller in the entire forest to act as a global catalog server. If you want to ensure that users in the branch office are always able to contact a global catalog server, simply designate the local domain controller to act as a global catalog server.
There's a reason why Microsoft only creates one global catalog server by default. When multiple global catalog servers exist on a network, keeping them synchronized creates a considerable amount of network traffic. If you have a fairly small network and do not frequently create or modify Active Directory objects, the additional traffic is usually negligible. But on larger networks, placing global catalog servers on both sides of a WAN link is a bad idea.
So how can users in the branch office contact a global catalog server in the event of a link failure if no global catalog server is located locally? By creating redundant connections. In most organizations, each branch office has its own Internet connection so that traffic related to Web browsing won't clog up the WAN link to the main office.
If your branch office has its own Internet connection, you might consider creating a VPN connection to the main office that can be used if the primary WAN link fails. Another option is to invest in a router that automatically establishes a dial-up connection should the primary link fail. Dial-up connections are painfully slow, but dial-up connectivity is better than no connectivity.
Depending on the speed of your WAN link, you may also want to place a file server in the branch office. You can use the Distributed File System Service to ensure that the local file server is kept synchronized with the file server at headquarters.
A replicated file server offers several advantages:
- If a link failure occurs, users can still get to their files.
- If users are accessing files locally, it prevents the files from being transferred across the WAN link every time they are open.
- The replicated file server can act as a backup to the primary file server. If something were to happen to the server in the main office, there would be an exact copy of the file system in the branch office.
The disadvantage to using a DFS replica in a branch office is bandwidth consumption. The initial synchronization is going to be extremely bandwidth-intensive. You'd probably want to physically move the replica DFS server to the main office to perform the initial synchronization, then move it to the branch office once the synchronization has completed.
The ongoing replication can also be a problem. Anytime someone in either office creates a file, the file is replicated across the WAN link. Normally this isn't a big deal, but the replication process can become disruptive if a user creates a large file and your WAN link doesn't have the bandwidth to handle the replication process efficiently.
About the author: Serdar Yegulalp is editor of the Windows Insight, (formerly the Windows Power Users Newsletter), a blog site devoted to hints, tips, tricks and news for users and administrators of Windows NT, Windows 2000, Windows XP, Windows Server 2003 and Vista. He has more than 12 years of Windows experience under his belt, and contributes regularly to SearchWinComputing.com and SearchSQLServer.com.