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 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:
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.
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:
Figure 3 In the Group Policy Management Console, enable the BranchCache for branch office caching.
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:
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.
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:
Here’s what I like about BranchCache:
BranchCache will certainly have its place, but beware these drawbacks:
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.
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.
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:
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.
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:
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):
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 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
Figure 9 Firewall Settings for the Intranet Firewall
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
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.
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.
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.