10/19/13

Hands-on: BranchCache

10/14:

Two improvements to BranchCache in Server 2012 and Windows 8: 1) workstations can be configured via group policy to act in distributed mode, but reconfigure themselves if a hosted cache server is later implemented in their subnet; 2) you don't need a SSL certificate on your hosted cache server anymore because data encryption is improved.

I wanted to simulate a WAN environment because workstations decide whether or not to use BranchCache by checking network latency. By default, it kicks in if latency is above 80 milliseconds. Hyper-V 3.0 can simulate low bandwidth environments, but not low latency. So, tried the NetworkSimulator, but it wouldn't install on Server 2012. Next, tried the popular live-Linux ISO WANem, which is based on Knoppix. The 3.0 beta gave wildly unpredictable latency, ranging from 2ms to over 3,000ms, with or without any configuration in it. So, switched to the 2.3 version...which worked out perfectly. This blog post encouraged me. I can now set *exactly* how much network latency I want to have between two virtual machines!

10/17:

Spent 4.5 hours studying tonight, mostly on "Why can I ping both interfaces of my WAN simulator from either side, but not through it?".

It was because WANem (and everything else in 192.168.0.x) was forwarding packets to my D-Link router at 192.168.0.1...which consulted its internal routing table and thought the return path for 192.168.5.x must be on the Internet, ignorant that 192.168.0.10 on the LAN should handle it. This I deduced, but confirmed it using Hyper-V 3.0's new port mirroring feature. The solution was to add a routing statement to each server - route add 192.168.5.0 mask 255.255.255.0 192.168.0.10.

10/19:

Fell into a deep time sink when a newly minted domain controller - pdx-dc1.portland.contoso.local - couldn't replicate Active Directory because its replication partner lacked a manual routing statement (needed for this lab setup). After that was fixed, the slow pace of replication imposed by my simulated 1.54Mb link with 90ms of latency meant that incomplete AD replication made WinRM unable to communicate using the server's FQDN, causing the DHCP installation wizard to fail. Nice, huh?

Some troubleshooting take-aways from the above paragraph:
 
ncpa.cpl opens Network Connections
net stats srv shows uptime
winrm get winrm/config displays the configuration of WinRM
winrm id -r:pdx-dc1.portland.contoso.local failed until AD replication was done
dcdiag showed when replication was still in progress

Here’s a list of the machines involved in today’s study:
  • dc1.contoso.local (idle)
  • sea-dc1.seattle.contoso.local (BranchCache enabled file server)
  • pdx-dc1.portland.contoso.local (idle)
  • pdx-pc1.portland.contoso.local (Windows 7 workstation)
  • pdx-pc2.portland.contoso.local (Windows 7 workstation)
  • pdx-pc3.portland.contoso.local (Windows 8 workstation)
  • pdx-pc4.portland.contoso.local (Windows 8 workstation)
Portland and Seattle are separated by a simulated 1.5Mb T1 with (a high) 90ms of latency.

When I first opened up the GPMC on pdx-dc1, was puzzled to find that it only presented the top-level domain. To fix, right-click “Domains” and select “Show Domains”. While researching, I learned that applying GPOs across domains is generally frowned upon. You can’t apply a GPO to a generic Active Directory container, such as the default “Computers” folder.








On sea-dc1 (file server), installed BranchCache for Network Files (under the File Server Role), then enabled the GPO “Allow hash publication for all shared folders” so BC doesn’t have to be manually enabled for each share. Configured a GPO to enable BC on Portland PCs. This article offers a general overview. Here is a nice step-by-step article that I wish I’d gotten to earlier. Here’s how BranchCache speeds up the Exchange OAB download. Windows 7 clients need a hotfix for BranchCache to work with files open in read/write mode. Here’s the exhaustive TechNet overview of BranchCache. Here’s how to open Performance Monitor and watch the BranchCache counters. Links to info on SMB 3.0. BranchCache verification and monitoring from TechNet. What’s new in BranchCache for Windows 8/2012. This blog post explains some not-so-well documented aspects of BranchCache.

gpresult /r showed me that sea-dc1 had indeed picked up the GPO that I created.

Disabled the firewall on two Windows 7 PCs and installed the Excel Viewer. Opened perfmon and loaded the BranchCache counters, then zeroed them out by running netsh branchcache reset, then re-enabled BranchCache by running gpupdate. A moment later, ran netsh branchcache show status all to verify that it was ready.

Comparisons with a 1.5MB XLS file, opened in Excel Viewer (after running hashgen -f c:\shared on sea-dc1 to ensure that hashes were ready immediately):

First Windows 7 PC: 14.5 seconds on first try (and PerfMon BC counters ticked upward); 3.7 seconds on second try (opened from the local Offline Files Cache).

Second Windows 7 PC: 5.6 seconds on first try (and PerfMon BC counters ticked upward) because it loaded from the BC cache on the first PC. Nice!

Oddly, I can’t find any TechNet sources (only forum posts and blogs) where Microsoft officially acknowledges that BranchCache is an extension of (and thus dependent on) the Offline Files feature.

However, it’s true. If you disable Offline Files, group policy (at least on Windows 7) does not automatically start the BranchCache service…and if you start the BC service yourself, the BranchCache PerfMon counters go from “—” to “0.000″, but won’t budge again.

Moving on to hosted cache…you can’t enable it on a writeable domain controller. You run Enable-BCHostedServer -RegisterSCP and then Get-BCStatus.