Last February, when App-V 4.6 was released I blogged about the new features (see http://www.tmurgent.com/TmBlog/?p=151 ). It turns out that that, due to incorrect information supplied, there was an mistake in that post that has some people scratching their heads in how to make it work.
The error is about enabling BranchCache at a remote site with App-V Clients. Microsoft previously indicated that changes were made to the 4.6 client to enable it to utilize BranchCache.
To be clear, BranchCache does not recognize the RTSP or RTSPS protocols and will provide no value to App-V clients at the remote site for RTSP/S communication. Branch cache does provide help for Windows 7 machines using SMB and HTTP/S protocols.
A remote App-V client can communicate using all three methods, depending upon configuration. While RTSP/S is the most popular, it isn’t the only method. Companies using RTSP/S at a remote site have many options to reduce bandwidth consumption and the effect of latency. These include:
- An App-V Streaming Server at the remote site, using an ASR override at the client with RTSP://StreamingServer syntax.
- Just using the App-V Server at the central site and adding ASR override at the client with FILE://ContentServer syntax pointed at the central site.
- Just using the App-V Server at the central site and adding ASR override at the client with FILE://ContentServer syntax pointed at the remote site. You need to copy (use RoboCopy) the files any time there is a change.
- Same as above, but with a remote site DFS share. This can be done with or without an ASR override with FILE://dfsname syntax, depending on whether main site clients will receive the apps using RTSP or with FILE: syntax.
- A central site HTTP or HTTPS server. The App-V client either uses the HTTP/S server as a publishing server, or continues to the the RTSP/S central site for publishing and uses a client ASR override with HTTP: //IISServer syntax.
- Leveraging a SMS/SCCM Distribution point located at the remote site. This can be done with App-V clients configured to use SCCM (thus elliminating RTSP altogether), or tricking SCCM to deploy the package to the DP and manipulating the App-V client. The latter is not recommended, but has been done.
- My favorite method – use the StandAlone Client.
It seems BranchCache should help with Scenarios #2 and #5. I hope this helps to clarify this a little.