Share via

Windows 7 and Windows Server 2008 R2

  • Article

BranchCache and DirectAccess: Improving the Branch Office Experience

Gary Olsen

While the unwashed masses finally have their first peek at Windows Server 2008 R2 and Windows 7, the chosen ones have been working with the release candidate (RC) code since May and the release to manufacturing (RTM) version since August. Whichever group you’re in, you probably have been inundated with hype. Maybe you were invited to a Windows 7 preview “house party,” like me, for example. (My son-in-law hosted one, but only because he wanted the software free from Microsoft.) Even if you were spared that major hype, you couldn’t have avoided each of the many media reports extolling or questioning the new features of these products, both of which are from a new code tree and constitute new ISATAPISATOSes.

BranchCache and DirectAccess, arguably the crown jewels of these releases, are worth your attention. With BranchCache, Microsoft aims to give branch employees the same experiences working with files as their peers at the corporate office. With DirectAccess, Microsoft targets remote users connecting to corporate networks via virtual private networks (VPNs).

As is typical with Microsoft, you only get the good stuff on the new products. In this case, you can only implement BranchCache DirectAccess to Windows 7 clients and 2008 R2 servers. Let’s take a deeper look at each of these new features.

BranchCache

BranchCache improves the branch office experience by caching commonly used files locally, either on a Windows Server 2008 R2 server or user workstations, rather than forcing users to access files via centrally located network shares. BranchCache is cool, but there are caveats.

IT can deploy BranchCache in Distributed Cache Mode or Hosted Cache Mode (see Figure 1). IT configures the mode via Group Policy, so using hosted mode at one office and distributed mode at another requires implementing two policies and planning organizational unit (OU) structures accordingly. Microsoft recommends deploying Distributed Cache Mode in sites of 50 or fewer clients, but it will depend on speed and bandwidth of the WAN link, as well as other factors. Distributed Cache Mode will require larger hard disks and perhaps memory and other resources, so at some point it will be more advantageous to use Hosted Cache Mode, especially if there’s an existing 2008 R2 server at the site. In addition, Distributed Cache Mode can only work on a local subnet. So if there are multiple subnets at a site, then a client on each subnet will have to cache the file for others on that subnet to download it. However, Hosted Cache Mode can serve multiple subnets at the site, so that would be another reason to choose Hosted Cache Mode.

Figure 1 A branch office can use BranchCache in either distributed or hosted modes.

In Distributed Cache Mode, no file server resides at the branch office. Instead, through policy, all user machines are BranchCache clients, that is, they all have the ability to cache documents that others in the branch site can download—if they’re the current version.

For example, let’s say that Caroline requests a document, Reports.docx from a BranchCache-enabled file server in the central site. BranchCache sends metadata describing the content of the file. Hashes in the metadata are then used to search for the content in the local subnet. If not found, a copy is cached on her computer’s local drive. Later in the day, Tyler needs to modify Reports.docx so he contacts the share on the main office file server to get a copy to edit. The file server returns the metadata, then the client searches for the content, which it finds on and downloads from Caroline’s computer. This is done securely using an encryption key derived from the hashes in the metadata. The next day, Abigail needs to modify that same document. The process is the same, but she’ll be opening the copy cached on Tyler’s computer. Again, the version information is kept at the server. Clients contact the server to determine if there is a copy of the latest version at their site.

This is one of three BranchCache scenarios that will come into play as users work with various documents. The other two are:

  • A branch office worker asks the main office file server for a document that is not cached on a local computer. The user receives a copy, which is then cached locally.
  • A branch office worker asks the file server for a document that’s cached in the local site, but the computer is turned off. The client obtains a new copy from the file server and caches it on his PC. Future requests lead to this the newest cached copy.

In each case, the documents also save to the main office file server. That way, if Caroline comes back and wants to access the document but Abigail’s computer, which now houses the latest version, is turned off, she will receive the document from the main office server.

With Hosted Cache Mode, IT configures a Windows 2008 R2 file server in the branch office with BranchCache by installing the BranchCache feature, and configuring a Group Policy to tell the clients to use Hosted Cache Mode. The procedure described for Distributed Cache Mode works the same here, but the files are cached on a locally configured BranchCache server rather than the users’ computers.

Note: the content metadata maintained by the file server in the central office site is sent to each client when a file is requested from a BranchCache-enabled server. This is used to determine if any local client or server (depending on which cache mode is used) has the most recent copy.

The BranchCache-enabled server at the branch site can be used for other purposes, such as a Web or Windows Server Update Services (WSUS) server. Special considerations must be made in these cases, and is described in the Microsoft BranchCache Deployment Guide and Microsoft BranchCache Early Adopter’s Guide.

BranchCache Configuration

To configure BranchCache, you’ll need to understand how Group Policy Objects (GPOs) work and how to configure them in your OU structure to affect the computers at each site. Remember that all servers involved in the BranchCache scenario must be Windows Server 2008 R2 and all clients Windows 7. Here’s the process:

Step 1. Install the BranchCache feature via Server Manager.

 

Step 2. If you’re using BranchCache on a file server you’ll need to install the File Services Role as well as BranchCache for remote files (see Figure 2).

Figure 2 A BranchCache installation requires enabling the File Services and BranchCache for remote files roles.

Step 3. Configure a BranchCache GPO. Go to Computer Configuration | Policies | Administrative Templates | Network | BranchCache. You will see five possible settings:

  • Turn on BranchCache. This has to be enabled for all BranchCaching (see Figure 3). Note that enabling BranchCache without enabling Distributes or Hosted Cache mode policy settings causes the local Windows 7 client to cache files locally. This is useful if multiple users use one computer.

     

Figure 3 In the Group Policy Management Console, enable the BranchCache for branch office caching.

  • Set BranchCache Distributed Cache Mode. This applies to all clients in the GPO.
  • Set BranchCache Hosted Cache Mode. Specify a server to host the cache. These roles are mutually exclusive. Only one can be configured for the site.
  • Configure BranchCache for network files. If not configured or disabled, this defines a latency threshold of 80ms. If the file request takes more than 80ms, then the file will go into cache. Enable this setting and change the latency value as desired.
  • Set percentage of disk space used for client computer cache. This is set by default at 5 percent of the user’s disk. You’ll have to play with this to get the right amount for servicing the cache versus giving the user required space. This can be a problem if you have disk configurations that vary widely on size, as some will have greater cache capacity than others.

Set Disk Space

 

Step 4. Configure GPO setting “LanMan Server” in the BranchCache Policy. In the same area of the GPO in Step 3, go to the LanMan Server setting and look at the properties for “Hash Publication for BranchCache.” The three options are:

  • Disallow hash publication on all shared folders.
  • Allow hash publication for all shared folders.
  • Allow hash publication only for shared folders on which BranchCache is enabled.

Servers that are running the File Services server role on 2008 R2 servers, which are desired to be BranchCache content servers, must also run the BranchCache for Network File Services role and hash publication must be enabled. BranchCache is also enabled individually on file shares. The hash publication can be enabled individually on a server (such as for a non-domain server configuration), or on groups of servers via Group Policy. Thus, BranchCache can be enabled on all shared folders, some shared folders or disabled entirely.

 

Step 5. Configure the GPO setting in Windows Firewall to allow inbound TCP port 80 (applied to the client computer).

Step 6. Once you’ve configured everything, and if the file share exists with the users’ files, go to Server Manager | File Services | Share and Storage Management. The center pane lists the shares. Right-click on the share and select Properties, then click Advanced. On the Caching tab, enable BranchCache (see Figure 4). Note: If the BranchCache option is unavailable, then the BranchCache feature wasn’t installed properly or the policy is set to disable, as noted previously.

Figure 4 Enable file sharing with BranchCache using Share and Storage Management controls.

BranchCache Client Configuration

By default all Windows 7 clients are enabled for BranchCache, meaning there is nothing to enable on the client itself. However, there are client-related steps that are required:

  • Configure Firewall settings. While this was noted earlier, there are other requirements for Hosted Cache Mode. Refer to the BranchCache documents from Microsoft noted at the end of this article.
  • Clients must be in an OU that contains a policy that enables BranchCache and defines which cache mode to be used. Again, refer to the documents at the end of this article for more detail.

BranchCache: The Good

Here’s what I like about BranchCache:

  • It can use the Background Intelligent Transfer System (BITS) to enable file transfers in the background if the user is logged in, even if the application exits. This is a great feature for branch offices connected over slow links. Should a system restart be necessary, file transfer continues once that completes. For this to work, of course, applications must be written to take advantage of BITS.
  • BranchCache is configurable via the Netsh command-line utility and is well-documented on TechNet’s BranchCache for Windows Server R2 site.
  • You can monitor BranchCache performance through counters for the client, file server and cache host. Not only are these helpful for performance diagnosis, as far as I can tell, watching these counters is the only way to see if the client is really getting a cached copy.
  • The BranchCache environment is controllable via Group Policy.

BranchCache: The Bad

BranchCache will certainly have its place, but beware these drawbacks:

  • Because Distributed Cache Mode essentially turns every workstation into a file server, client machines hosting a lot of frequently accessed files could suffer performance hits. This will need some testing to determine actual impact.
  • In some cases, clients may require additional disk space to allow for sufficient cache sizes.
  • Caching clients will now be competing with peers for network resources.
  • Delays may crop up during the initial caching process or when a file is not available in cache. Only Windows 7 clients and Windows Server 2008 R2 servers can participate, so a full rollout of this feature may take some time.

If you can justify putting a file server in the branch office, why not use Distributed File Shares (DFS)? Rather than messing around with cached files, you can use Distributed File System-Replication (DFS-R) to replicate the files and maintain a namespace with DFS. You may find advantages to caching the network files, and perhaps BranchCache will work on DFS shares. Or, perhaps you’ll find some performance boundary where the cache is more efficient than DFS-R. On the other hand, the impact on the server for BranchCache would be lower than a full-blown DFS configuration. The point is, you’ll have to study your needs, and examine the options available with BranchCache. Of course, each environment is different and what may cause problems in some branch offices won’t in others. There is no one right answer for all situations.

DirectAccess

With DirectAccess, Microsoft addresses the poor VPN experience users have had since Windows 2000, even with many improvements since the initial implementation. A DirectAccess-configured client can access an intranet site from a remote location without having to establish a VPN link manually. In addition, much to their delight, IT staffs can manage remote machines over an Internet connection rather than through the VPN. So if I’m working at home, connected to my company’s intranet, and the Internet link drops, the VPN will re-establish the connection when the Internet becomes available—without pestering me to reconnect and re-enter my credentials as I would have to do—often repeatedly—without DirectAccess.

In fact, from a user’s viewpoint, DirectAccess is invisible. When a user on an enabled client clicks on the intranet link, DirectAccess handles the connection and disconnection. Users do not have to open Connection Manager, enter their credentials, wait for the connection and so on.

While the remote connection is live, the user has a “split tunnel” configuration by default (see Figure 5). This enables simultaneous access to the intranet, the local network (for use of devices such as printers) and the Internet. In a typical VPN scenario without the split tunnel, connecting to the Internet means first hopping on the intranet and then passing through the corporate network gateway for connectivity. In addition, I have no access to my local network, although workarounds are possible. So again, DirectAccess is designed to give the remote user a more “in the office” experience than traditional VPN affords.

 

Figure 5 DirectAccess enables a split-tunnel configuration for simultaneous connectivity to the corporate network and Internet.

From IT’s perspective, once the computer is on the Internet (remember that DirectAccess is always enabled if it’s installed), patches, policies and other updates are easy—and secure via IPsec connections—to apply.

DirectAccess Requirements

In a basic DirectAccess configuration, the DirectAccess server is on the edge network, providing remote user connectivity to internal resources including the application servers, certificate authorities (CAs), the DNS and domain controllers (DCs). CAs and application servers must be configured to accept IPv6 traffic. Here are the essential components of a DirectAccess configuration:

  • In the Active Directory Domain, DirectAccess clients will only be able to access Windows 2008 or 2008 R2 DCs.
  • Group Policy definitions must enforce DirectAccess settings to:
 
  • Identify DirectAccess clients.
  • Configure the Name Resolution Policy Table (NRPT).
  • Remove the Intra-Site Automatic Tunneling Address Protocol (ISATAP) from the DNS global restriction list.
  • The DirectAccess server must:
 
  • Be a member of the Active Directory Domain.
  • Run on Windows Server 2008 R2.
  • Have two network adapters configured (one for intranet and the other for Internet connectivity).
  • Have two consecutive static IPv4 addresses externally resolvable.
  • Be installed with DirectAccess management “feature” (via Server Manager), and setup wizard run for configuration.

 

  • The IIS/Web server enables functionality that determines if intranet resources are reachable. Application servers must be configured to allow access by DirectAccess-enabled clients.
  • For use with the required CA, install Active Directory Certificate Services and issue certificates for authentication.
  • Either a native IPv6 network or transition technologies must be available throughout the intranet.
  • Using IPsec policies for secure authentication and DirectAccess connection encryption, the client authenticates before the user logs on.
  • You can find necessary firewall exceptions in the Microsoft DirectAccess Early Adopter’s Guide.

As you can see, DirectAccess is not for the faint of heart. The IPv6 requirement alone will undoubtedly raise concern—and require most organizations to implement transition technologies—but 2008 R2 does have the components. In addition, you have to enable security via a public key infrastructure (PKI), provide authentication services and set up IPv6 identification to application servers. Before running the DirectAccess setup wizard, you also have to configure the security groups, establish firewall policies, setup the DNS and complete a number of other prerequisites.

DirectAccess Server

The DirectAccess server performs a number of functions, defined through Server Manager’s DirectAccess setup wizard (see Figure 6).

Figure 6 Initiate DirectAccess setup through Server Manager.

The DirectAccess wizard performs four essential tasks. Through the wizard you will:

  1. Identify clients to be DirectAccess-enabled. You can list security groups from other domains or forests here, if trusts are configured. You must define appropriate security groups prior to running the wizard.
  2. Define connectivity and security (certificates) for the DirectAccess server. You will identify which network interface is on the Internet side and which connects to the intranet. Install the CA and create the certificates prior to running the DirectAccess setup wizard. In addition, define smartcard policy.
  3. Identify the DNS, DC and, optionally, management and other infrastructure servers for use in the DirectAccess environment. You also must identify a highly available server as the network location server. The DirectAccess server can fill this role.
  4. Identify the application servers configured to accept connections from DirectAccess clients. The default is no additional end-to-end authorization, but you can select IPsec policy-based security options.

DNS and the NRTP

As noted previously, DirectAccess clients can access the intranet directly. To enable this, you must implement the NRPT, which defines DNS servers per DNS namespace rather than per network interface. I think of this as the way conditional forwarding works on Windows 2003 and 2008 DNS servers, where you can define DNS namespaces with the appropriate IP address to connect to the server. NRPT allows a client to avoid normal DNS iteration and go directly to the DirectAccess server.

Here’s how the NRPT works (see Figure 7):

  1. A name query request matches a configured namespace for the corporate intranet, pointing to the DirectAccess server.
  2. The NRPT contains the IP address and the DirectAccess server’s Fully Qualified Domain Name (FQDN). When the IP address is used, the connection to the DNS server is encrypted for a secure connection.
  3. When the FQDN is used, it must be resolved through the Internet and find the corporate DNS server.
  4. If the client sends a name resolution request for a namespace not defined in the NRPT (such as www.microsoft.com), then it follows normal name resolution through the Internet

Figure 7 The NRPT enables definition of DNS servers per DNS namespace rather than per interface.

 

NRPT is configured during DirectAccess setup in the Infrastructure Server Setup page and the wizard fills in the IPv6 address of the DNS server. Name Resolution Policy, a new Group Policy setting for 2008 R2, defines specific policy settings such as IPsec, DNS server and how the name resolution fallback occurs when the namespace isn’t in the queried network. You’ll find this in Computer Configuration | Windows Settings | Name Resolution Policy (note, you must enter domain namespaces with a leading dot “.”—for example, .emea.corp.net).

You can expose NRPT contents using the Netsh command: Netsh name show policy.

This will show the namespaces defined.

Firewall Exclusions

Firewall exclusions will depend on how you implement the IPv6 network and if you use the transition technologies. In addition, any file or application servers the remote clients must connect to will need Windows Firewall configured appropriately. Figure 8 and Figure 9, below, show firewall exclusions for the firewall on the Internet and intranet sides of the DirectAccess server, respectively. Obviously you only need to set exclusions for technologies you are using. (Note that even though Figure 9 lists IPv4+NAT-PT, it’s not implemented by Windows 2008 R2.)

 

Figure 8 Firewall Settings for the Internet Firewall

Transition Technology Protocol to Allow
Teredo UDP 3544
6to4 IP Protocol 41
IP-HTTPS TCP 443
Native IPv6 ICMPv6, Protocol 50

 

 

Figure 9 Firewall Settings for the Intranet Firewall

 

Protocol IPv6 Technology
ISATAP Native IPv6 IPv4 + NAT-PT
Protocol 41 X    
TCP   X X
UDP   X X
ICMPV6   X  
All IPv6 connectivity   X  
UDP 500 IKE/AuthIP   X X

 

Connectivity - IPv6

Because IPv6 permits DirectAccess clients to maintain continuous connectivity to resources on the corporate network, they must all run the protocol. Even if you have a fully implemented IPv6 network, allowing remote connectivity may require use of a transition technology that would allow the DirectAccess client to connect to IPv4 resources by encapsulating IPv6 inside of IPv4 packets. These technologies include 6to4, IP-HTTPS and Teredo.  ISATAP also is an encapsulation technology but is only used internally. I won’t go into detailed descriptions here, but Figure 10 shows basic connectivity options.

 

Figure 10  Preferred Connection Options for DirectAccess Clients

 

If the client is assigned a: Preferred connectivity method:
Globally routable IPv6 address Globally routable IPv6 address
Public IPv4 address 6to4
Private (NAT) IPv4 address Teredo
If the client cannot connect using the above IP-HTTPS

* Source: Microsoft*

On the intranet side, without native IPv6, DirectAccess permits use of ISATAP, which generates an IPv6 address from an IPv4 address and implements its own neighbor discovery. ISATAP allows DirectAccess clients to access resources on an IPv4 network. For example, when an ISATAP client boots, it must find an ISATAP router. It does this by issuing a DNS query for ISATAP.<domain name>. So for Corp.net it would look for ISATAP.corp.net. Windows 2008 DNS implements GlobalQueryBlockList, an additional security feature that includes ISATAP by default. This causes it to ignore any ISATAP.<domain name> request. Therefore, you must clear ISATAP from the list. Do this via the DNSCMD command or by making a registry entry.

At a command prompt, enter dnscmd /config /globalqueryblocklist wpad and press Enter. This will define the GlobalQueryBlockList as only having WPAD in it (thus removing ISATAP). You also may accomplish this by going to the registry key at

HKLM:\System\Current Control Set\Services\DNS\Parameters. Edit GlobalQueryBlockList and remove ISATAP.

You also can implement 6to4 individually on hosts or over an entire network and transmit IPv6 packets over an IPv4 network. Interestingly, if 6to4 is implemented for an entire network, it requires only one IPv4 address. It does not support traffic between IPv4 and IPv6-only hosts.

Teredo also provides IPv6 packets to be routed to IPv4 networks, but is used when the client is behind a Network Address Translation (NAT) server that is not configured for IPv6. It stores IPv6 packets in the IPv4 datagram that allows forwarding from the NAT.

Windows 7 and Server 2008 R2 have implemented a protocol called IP-HTTPS that tunnels IPv6 packets in an IPv4 HTTPS. While IP-HTTPS has poorer performance than the other protocols, you can add additional IP-HTTPS servers to improve performance somewhat. IP-HTTPS is a fairly easy protocol to enable to get the IPv6-over-IPv4 network connectivity to work.

When designing the DirectAccess client configuration, you can either use DNS and the NRPT to separate Internet and intranet traffic, or you can use something called Force Tunneling and force all traffic through the tunnel. Force Tunneling, which requires IP-HTTPS, is enabled via Group Policy setting Computer Configuration\Policies\Administrative Templates\Network\Network Connections\Route all traffic through the internal network. This policy would need to apply to the DirectAccess clients. I noted previously that DirectAccess clients can access local resources while connected to the intranet. This still holds true for IP-HTTPS clients, but if the user tries to access Internet sites, for example, it would be routed through the intranet.

Certainly the IPv6 requirement and complex configurations are downsides to DirectAccess, but those are easily outweighed by user experience improvements and ease of remote client management for IT.

Great Promise

The number of remote workers, be they at a branch, in a home office or on the road, is increasing. BranchOffice and DirectAccess hold great promise for branch office and other remote workers, and IT managers and administrators would be wise to investigate them. Neither of these will be a quick and easy setup, and there are a number of options and features that are available. In addition, these features will only work on Windows 7 clients and Windows Server 2008 R2 servers, so this will definitely impact an implementation timeline. IT managers and administrators would be wise to study the Microsoft documentation available and configure it in a test lab to ensure success.

Related Content

 

Gary Olsen is a systems software engineer in HP’s Worldwide Technical Expert Center (Hewlett-Packard WTEC) in Atlanta, Ga., and has worked in the IT industry since 1981. In addition to being a Microsoft MVP for Directory Services, he’s founder/chairman of the Atlanta Active Directory Users Group and is a frequent contributor to Redmond magazine.