Using BranchCache and read-only domain controllers can help you ensure a smooth experience for your branch office users.
Branch offices always present a special set of challenges. Without an on-site IT staff, branch offices tend to be more difficult to manage and secure. Employees at branch offices often experience slow response times when they try to access resources stored on servers located at the main office. There are several features in Windows Server 2008 R2 that directly address the unique performance and security needs of branch office environments.
BranchCache helps alleviate some of the WAN congestion that occurs when users try to access data from the corporate network over a WAN connection. BranchCache does this by locally caching frequently used data so it doesn’t need to retrieve it across the WAN every time it’s requested.
To use BranchCache, all of the workstations in the branch office must be running Windows 7. All file servers and Web servers in the main office must be running Windows Server 2008 R2.
There are two different modes available when using BranchCache. The mode you should use depends largely on the size of your branch office. If your branch office has fewer than 50 users, you won’t need a BranchCache server. Instead, you can run BranchCache and Distributed Cache Mode. In this mode, each Windows 7 workstation is able to cache network contents and provide access to the cache to the branch office users.
The primary limitation to using Distributed Cache Mode is that it only supports a single subnet at the branch office. If your branch office uses multiple subnets, then each Windows 7 workstation will only be able to provide caching data to other workstations within the same subnet.
The other BranchCache mode is better suited for larger branch offices; it’s called Hosted Cache Mode. In this mode, BranchCache resides on a designated Windows Server 2008 R2 machine. Each Windows 7 workstation has a fully qualified domain name of the server to which it should look for the cached content.
BranchCache is disabled by default in Windows Server 2008 R2. To enable BranchCache, open Server Manager on your BranchCache server, click on the Features container, and then click on the Add Features link. Choose the BranchCache option from the list of available features (see Figure 1), click Next, followed by Install and Close.
Figure 1 You have to enable and configure BranchCache as a feature.
The exact method of BranchCache configuration you’ll need to do will vary depending on the types of content you want to cache. BranchCache can cache file server data, Intranet Server data or BITS application server data. Because caching file server data is the most common use for BranchCache, I’ll cover the file server configuration process.
The first step in configuring BranchCache to cache file server data is to enable the BranchCache for Network Files role service on your file servers. Do this on any Windows Server 2008 R2 file server containing data you need to cache. Do this by adding the BranchCache for Network Files role service to the File Server role (see Figure 2).
Figure 2 You’ll need to add the BranchCache for Network Files role service to your file servers.
The next step in the process is to use Group Policy to configure the BranchCache server. Assuming you have a single BranchCache server, you can do this in the BranchCache server’s local security policy.
Open the Group Policy Editor and navigate through the console tree to Computer Configuration | Policies | Administrative Templates | Network | Lanman Server. Double-click on Hash Publication for BranchCache setting and click Enabled. You’ll have to choose either Allow Hash Publications for All File Shares or the Allow Hash Publication for File Shares Tagged with Windows BranchCache Support option (see Figure 3). After making your selection, click OK.
Figure 3 You must allow hash publication for file shares.
While you’re at the BranchCache Server, you should also configure the amount of hard disk space available for cached content. By default, BranchCache uses up to five percent of available hard disk space. You may want to increase this amount, especially if you have a dedicated server. Setting the disk space limits involves registry editing, so make a full system backup prior to editing the registry. Making a mistake while editing the registry can destroy Windows.
Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters. Double-click on the HashStorageLimitPercent value. Specify how much of the server’s hard disk space you want to use for cached data (see Figure 4). Enter the value as a percentage. You’ll need to create a HashStorageLimitPercent value if one doesn’t already exist.
Figure 4 You can use the system registry to regulate the amount of disk space that’s used by BranchCache.
The last server-side configuration task is to set the BranchCache support tag on your file shares. To do so, right-click on a file share and select the Properties command from the shortcut menu. When the properties sheet for the file share is displayed, select the Sharing tab and click the Advanced Sharing button, followed by the Caching button. Select the Only the Files and Programs that Users Specify Are Available Offline option, as well as the Enable BranchCache option (see Figure 5), then click OK.
Figure 5 You must enable BranchCache on each individual file share for which you want to allow caching.
Once you’ve enabled BranchCache on your server, you’ll have to configure the clients in the branch office. The best way to do this is to modify the Group Policy for the computers in the branch office.
Use the Group Policy Editor to open the group policy that controls the security settings for your branch office. Navigate through the policy tree to Computer Configuration | Policies | Administrative Templates | Network | BranchCache. You’ll see several group policy settings related to BranchCache. Double click on the Turn on BranchCache setting, click Enabled, then OK. Next, double-click on Turn on BranchCache – Hosted Cache Mode and click Enabled, then OK.
You’ll also have to enable the BranchCache for Network Files setting. When you enable this setting, you have the option of specifying a latency value (in milliseconds) above which files should be cached. In other words, you have the option of only caching files that take a while to access. This is handy if you have a file server in the branch office and only want to cache content being pulled from a remote file server, or if you only want to cache very large files.
Depending on how your network is configured, you might also have to create a firewall rule to facilitate using BranchCache. In hosted cache mode, you must configure clients to accept HTTP traffic from the BranchCache server.
Read-only domain controllers (RODCs) can also help optimize the end-user experience in branch offices. Every version of Windows Server since Windows 2000 Server has used a multi-master domain model. This means you can write changes to the Active Directory of any DC and the DC will replicate the changes to the other DCs within the domain.
However, you can’t directly update the copy of the Active Directory database stored on an RODC. You’re only allowed to write updates to writable DCs. Those updates are then replicated to all other DCs in the domain, including RODCs.
There are two main reasons why RODCs are beneficial for branch office support. The first reason has to do with availability. DCs authenticate user logon requests. If a branch office doesn’t have a local DC, then those users are forced to authenticate against a DC in the main office. Not only is this slow, but if the WAN link fails, then users in the branch office won’t be able to access a DC.
Placing a DC in the branch office can help avoid this situation. If a WAN link fails, users can still authenticate onto the network. The problem with setting up a DC in a branch office is the lack of adequate physical security. Often times, the DC is simply set up in a closet with no real physical security and no on-site support.
RODCs are ideal for use in these types of situations. They’re hardened in a way that helps make up for the lack of physical security. The most obvious security feature RODCs offer is the read-only copy of the Active Directory database.
Because the database copy is read-only, you won't have to worry about someone gaining physical access to the DC, manipulating the Active Directory, and replicating unauthorized modifications across the network. The only changes to the database occur when authorized DCs replicate updates to the RODC.
Another way RODCs improve branch office security is by storing an incomplete copy of the Active Directory database. The Active Directory database normally contains the credentials for all of the domain’s user and computer accounts. However, RODCs don’t store any user or computer credentials by default. When a user authenticates, a password replication policy determines whether to cache the user’s password on the RODC.
Caching passwords ensures the RODC is able to process user logons. It prevents the DC from having a full set of cached credentials for that domain. Only branch office users where the RODC resides should have their credentials cached.
While you can improve the security of the RODC by leaving credential caching disabled, doing so may defeat the purpose of deploying an RODC. All authentication requests would then have to be processed by a writable DC.
Before you can deploy an RODC, make sure the forest functional level of the Active Directory is set to Windows Server 2003 or later. You’ll also need to use ADPREP to prepare the Active Directory forest (ADPREP/ForestPrep) and the domain that will contain the RODC (ADPREP/DomainPrep /gpprep).
If the domain is presently running on Windows Server 2003 DCs, then you’ll also need to run ADPREP with the /rodcprep switch. Incidentally, you’ll also need to deploy at least one writable Windows Server 2008 or 2008 R2 DC prior to deploying your first RODC.
Otherwise, the actual deployment process for RODCs is simple. When you run Dcpromo to promote the server to a DC, the wizard contains a check box you can use to make the server an RODC (see Figure 6).
Figure 6 Select the option to make the domain controller read-only.
The Password Replication Policy will control whether user credentials are stored on the RODC. This policy is essentially a list that controls the users and groups that are allowed to have their credentials replicated. As you build the list, you can either allow or deny the ability to replicate a user or group’s password.
You should avoid replicating administrative passwords. You should also create an Active Directory security group for users whose passwords you want to replicate. Then you can allow replication for that group instead of dealing with each user individually. Keep in mind that denials take precedence over approvals in the event of policy setting contradictions.
You can access the Password Replication Policy by opening the Active Directory Users and Computers console. Expand the DCs container, right-click on your RODC and choose the Properties command from the shortcut menu. Then you’ll see the properties sheet for the RODC. You can manage the Password Replication Policy through the Password Replication Policy tab (see Figure 7).
Figure 7 You have the option of authorizing the replication of user credentials.
WAN bandwidth congestion can be a major issue for branch offices. Using BranchCache and locally deployed RODCs can significantly reduce WAN bandwidth usage, while also improving security. Both of those factors can help you improve the branch office experience for your users.