Windows Server 2008 R2 Unleashed (264 page)

Configuration\Policies\Administrative Templates\Network\BranchCache).

3. Enable and configure the BranchCache for Network Files GPO setting (Computer

Configuration\Policies\Administrative Templates\Network\BranchCache). Here,

the latency value that determines when the network files aspect of BranchCache will

kick in must be specified. The default is 80.

1336

CHAPTER 32

Optimizing Windows Server 2008 R2 for Branch Office

Communications

NOTE

The latency value can be set to 0, which forces BranchCache for network files (SMB) to

be turned on all the time. Also, when you configure BranchCache via GPO, it overrides

any configuration that is done via Netsh.

Lastly, once the BranchCache GPO settings have been configured, the next step is to

configure Windows Firewall to allow incoming HTTP and WS-Discovery traffic:

. Allow TCP HTTP - 80 Inbound (from all other BranchCache clients—at the branch

office).

. Allow UDP WS-Discovery - 3702 Inbound (from all other BranchCache clients—at

the branch office).

Understanding WS-Discovery

WS-Discovery (Web Services Dynamic Discovery, or WSD) is a technical specification for a

multicast discovery protocol that is used to locate services on a local network. WSD,

which is not proprietary to Microsoft, is used by BranchCache to discover locally cached

content. For example, BranchCache clients will initiate multicast WSD Probe messages

ptg

with the hashes of the content probes to other BranchCache clients (also known as peers).

If these peers have the content, they will then reply with a unicast Probe-Match message.

To understand how this all works, here is the basic flow:

1. Client2 will first contact the content server FileServer1 for a document named

File.doc.

2. FileServer1 will respond with list of hashes that make up the indices of the

requested content.

3. Client2 will then send out a WSD Probe message to other clients in their local

network.

4. If there is a match on another peer, it responds to the Probe message with a Probe-

Match.

5. Client2 then will decide on where to get the content from (content server or other

peers).

NOTE

If content is retrieved from other peers, this is done via HTTP.

Testing Distributed Cache Mode

To test BranchCache in Distributed Cache mode, the following must be in place:

1. A Windows Server 2008 R2–based content server and content to put on that server.

2. Two different network segments with some sort of latency.

3. Two or more Windows 7 clients across continents from the content server.

Understanding and Deploying BranchCache

1337

Next, after the previously mentioned requirements are in place and BranchCache has been

correctly configured for Distributed Cache mode, BranchCache can be tested using the

following steps:

1. On Client1, copy a file from the share on the content server to your desktop.

2. Next, on Client2, copy the same file from the share on the content server to your

32

desktop.

NOTE

These steps assume that BranchCache for network files is being tested.

Hosted Cache Mode

Hosted Cache mode is still kind of peer-to-peer. However, in this deployment mode, all

the content that is cached on each peer is also cached on a central server in the branch

office. This hosted cache then becomes the central point of reference for peers to validate

locally cached content and then to retrieve that content from the cache. In other words, a

Hosted Cache server is kind of a glorified caching proxy server.

ptg

Server-Side Configuration

The server-side configuration for a Hosted Cache deployment is exactly the same as a

Distributed Cache deployment. However, there is one difference; a Hosted Cache server

must be deployed. Use the following steps to complete this task:

1. Install the BranchCache feature.

2. Next, execute the following Netsh command:

netsh BranchCache set service mode=HOSTEDSERVER

3. Install an SSL server authentication certificate where the subject name is set to the

FQDN of the Hosted Cache server.

4. Lastly, configure the Hosted Cache server to use the server authentication certificate.

To do that, get the certificate hash from the certificate you just installed, and exe-

cute the following command:

netsh HTTP ADD SSLCERT IPPORT=0.0.0.0:443 CERTHASH=”cert-hash” APPID=

➥{d673f5ee-a714-454d-8de2-492e4c1bd8f8}

Understanding the SSL Certificate

As mentioned before, BranchCache peers do not upload content to the Hosted Cache

server. Instead, they advertise the content in their cache, and the Hosted Cache server

then downloads the content it needs from the client. The SSL certificate is required

because clients “advertise” their content to the Hosted Cache server by doing an HTTP

post over TLS.

1338

CHAPTER 32

Optimizing Windows Server 2008 R2 for Branch Office

Communications

Client-Side Configuration

Like Distributed Cache mode, there are two methods for configuring Hosted Cache mode.

The first method is via Netsh. For example, run a command prompt (Run As

Administrator) and execute the following command:

netsh branchcache set service mode=HOSTEDCLIENT LOCATION=”FQDN of Hosted

➥Cache Server”

The second method for configuring BranchCache on clients in Hosted Cache mode is

GPO. Use the following steps to complete this task:

1. Enable the Turn On BranchCache GPO setting (Computer

Configuration\Policies\Administrative Templates\Network\BranchCache).

2. Enable the Set BranchCache Hosted Cache Mode GPO setting (Computer

Configuration\Policies\Administrative Templates\Network\BranchCache).

3. Enable and configure the BranchCache for Network Files GPO setting (Computer

Configuration\Policies\Administrative Templates\Network\BranchCache). Here,

the latency value that determines when the network files aspect of BranchCache will

kick in must be specified. The default is 80.

ptg

Lastly, once the BranchCache GPO settings have been configured, the next step is to

configure Windows Firewall to allow incoming HTTP:

. Allow TCP HTTP - 80 Inbound (from all other BranchCache clients—at the branch

office).

Troubleshooting (Is BranchCache Doing Something?)

Unfortunately, BranchCache is kind of a black box. When it’s working, users shouldn’t

notice anything. On the flip side, when BranchCache is not working, users will still proba-

bly not really notice anything (besides a performance hit). Therefore, to determine if

BranchCache is functioning, the following might be performed:

. Load up NetMon and watch the traffic flows. Or, if a tool is being used that can

monitor bandwidth across the WAN, improvements in bandwidth usage should be

seen.

. Watch the BranchCache event logs. However, this is only partly useful as a majority

of the BranchCache event messages are not very meaningful.

. Run the netsh branchcache show status command. The results from this

command are actually a really good starting point to see how BranchCache is config-

ured on a BranchCache client or Hosted Cache server.

. Look at the BranchCache performance counters (the BranchCache Kernel mode and

BranchCache counters). Just keep in mind that Kernel mode counters are only seen

server side.

Enhancing Replication and WAN Utilization at the Branch Office

1339

Enhancing Replication and WAN Utilization at the

Branch Office

Windows Server 2008 R2 introduces new technologies and refines existing ones to maxi-

mize performance, replication, and file sharing and to reduce WAN bandwidth utilization

32

consumed between branch offices and hub sites. The following technologies that address

and improve bandwidth utilization, latency, and reliability of the WAN links at a branch

office include the following:

. Read-Only Domain Controllers

. Next Generation TCP/IP

. Distributed File System

. DirectAccess

. Virtualization

. Group Policy

. SMB v2

ptg

Read-Only Domain Controllers

As revealed earlier in this chapter, the amount of information replicated over the WAN

between a Read-Only Domain Controller residing at a branch office and a writable domain

controller at a hub site is significantly minimized. This is because changes do not originate

at an RODC, eliminating the need to replicate data from an RODC to a writable domain

controller replication partner at a hub site, resulting in a reduction of bandwidth and

WAN utilization being used.

Next Generation TCP/IP Stack

A tremendous amount of improvement is seen in the Next Generation TCP/IP stack

introduced in Windows Server 2008 R2. Some of the features for the new TCP/IP stack

that directly impact and improve branch office WAN utilization and replication include

the following:

.
Receive Window Auto-Tuning—
Support for Receive Window Auto-Tuning is new

in the Next Generation TCP/IP stack. Receiver-side throughput is improved through

Receive Window Auto-Tuning because this feature is able to calculate the best possi-

ble receive window size for each connection by taking into account bandwidth,

latency connection, and application retrieval rate. Bandwidth performance naturally

improves with better throughput. Bandwidth performance can improve even more if

all applications receive TCP data.

.
Compound TCP/IP (CTCP)—
Compound TCP/IP, which is most often used for TCP

connections that have a large receive window size in addition to a large bandwidth

delay product, ultimately improves receiver-side throughput. With CTCP, the

amount of data sent across connections is significantly greater; however, TCP

1340

CHAPTER 32

Optimizing Windows Server 2008 R2 for Branch Office

Communications

connections are not impacted negatively. If CTCP and Receive Window Auto-Tuning

are used together, even more benefits, including increased link utilization and

performance gains for large bandwidth delay connections, can be witnessed.

.
ECN support—
When a TCP segment is lost, TCP assumes that it was because of

congestion at a router, so it performs congestion control. This lowers the TCP

sender’s transmission rate. With Explicit Congestion Notification (ECN) in the

routing infrastructure, routers experiencing congestion mark the packets as they

forward them. TCP peers receiving marked packets lower their transmission rate to

ease congestion and prevent segment losses. This increases the overall throughput

between TCP peers.

.
Improved routing—
Path maximum transmission unit (PMTU) black-hole router

detection automatically adjusts the PMTU for a connection when large TCP

segments are detected.

.
RFC optimizations—
The TCP/IP stack has better support for RFCs related to TCP

communications.

.
Neighbor detection—
The Next Generation TCP/IP stack supports neighbor

unreachability detection for IPv4 traffic. A computer such as a branch office main-

tains status about whether neighboring computers such as a hub site are reachable.

ptg

This provides better error detection and recovery when computers are not available.

.
Dead Gateway support—
Unlike the previous Windows versions of Dead Gateway

Detection, the Next Generation TCP/IP Dead Gateway support now provides a

failover and failback mechanism when encountering dead gateways.

For more information on the new TCP/IP stack, review Chapter 10, “Domain Name

System and IPv6.”

Distributed File System (DFS)

DFS in Windows Server 2008 R2 builds upon the completely revised replication engine in

Windows Server 2003 R2. DFS, which was first introduced with Windows 2000 Server,

provides a robust multimaster file replication service that is significantly more scalable and

efficient in synchronizing file servers than its predecessor, File Replication Service (FRS).

With Windows Server 2008 R2, DFS includes an impressive list of benefits for both Active

Directory and branch office server management, including simplified branch server

management, reduction of backups, and more efficient storage management. In addition,

DFS Replication (DFSR) enhances branch office implementations because it is possible to

schedule and throttle replication schemes, support multiple replication topologies, and

utilize Remote Differential Compression (RDC) to increase WAN efficiency. If WAN connec-

tions fail, data can be stored and forwarded until WAN connections become available. As a

result, WAN replication is reduced and optimized, branch office mission-critical files can be

replicated among branch offices, hub sites can reduce the amount of IT management that

takes place in the branch office, and the need for backups can also be reduced.

Additionally, a new feature that was introduced in Windows Server 2008 R2 is support for

read-only copies of information stored in Distributed File System (DFS) replicas. Because

Enhancing Replication and WAN Utilization at the Branch Office