set cachesize - Sets the size of the local cache. <- Size of repub cache, big on clients nada on servers. set publicationcachesize - Sets the size of the local publication cache. <- Hashes, big on servers, nada on clients in distributed mode.
cachesize = total size you want to cache on clients. publicationcachesize = (All your packages size in bytes /2000) * 2 if doing both v1 and v2 hashes. If its too small it will warn like this; "svchost (7832) PeerDistPubCacheJetInstance: The database C:\Windows\ServiceProfiles\NetworkService\AppData\Local\PeerDistPub\PeerDistPubCatalog.pds has reached its maximum size of 200 MB. If the database cannot be restarted, an offline defragmentation may be performed to reduce its size." //A From: [email protected] [mailto:[email protected]] On Behalf Of Roland Janus Sent: den 29 maj 2015 23:12 To: [email protected] Subject: RE: [mssms] BranchCache Lol, I didn’t mean the phrase, I meant the size. Maybe a mood question, but I felt asking it ☺ I kept I think those 10%, but that comment from Phil: I may to rethink that, especially on those location w/o a server. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: Freitag, 29. Mai 2015 22:23 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Anything, it turns it into a hashed string so pretty much anything like: ”BranchCache is awesome” or ”One Cache to Rule Them All”? ☺ Your input is more to just create a way of getting same key. Usage: set key [[passphrase=]<Pass Phrase>] Parameters: Tag Value passphrase - A passphrase to use to generate the key. If a passphrase is not provided, a random key will be generated. Two keys generated using the same passphrase will always be identical. Using a passphrase is a convenient way to duplicate the same key on another machine. (Optional) Remarks: Generates a new key for the BranchCache service to use to protect content information. If the service is currently running, this command will stop and restart it in order to begin using the new key. Examples: set key set key passphrase="I want my content to be secure" //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Roland Janus Sent: den 29 maj 2015 22:15 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache What would you set it to? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Phil Wilcock Sent: Freitag, 29. Mai 2015 13:21 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Nope, server-secrets are not managed by CM. It’s best to co-ordinate them across all of your DPs and SUPs (and also if you are using BC across a cluster) Set-BCSecretKey PowerShell will do it for server 2012 or Netsh for 2008 If your estate is all Win7 you can also tell the content servers to only create V1 hashes using the Lanman -> Hash Version Support for BranchCache policy. They will generate V1 and V2 by default, so it will save you some ‘HashCache’ space. ..and you REALLY don’t want to run out of HashCache ☺ A lot of people overlook the HashCache size setting.. Phil From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: 29 May 2015 10:51 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Don’t think hashes are managed by CM at all on the DP’s… but not 100% on that. Will check when I am in the lab. So Win7 and Server 2012 will allow the server to instruct the clients of available hashes. But the clients are too dumb to get it. So you need to generate the hashes if you want better stats. If the catalog is downloaded using BITS it will be BranchCache enabled if the SUP has BC feature on it. And if you have multiple SUPs you need to align the secret key, just like the DPs(?). Is the catalog downloaded using BITS? //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Wallace Sent: den 29 maj 2015 11:28 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Brilliant again Andreas Not quite what I was asking. The customer has BC enabled across all of their DPs in the site (all DPs in the site have their secret managed by CM anyhow don’t they?) and that is working well. This customer is using Server 2012 and Win7 so we are good on the download piece. It’s not the patches themselves that I am concerned about at this point but the initial catalog download from the software update point which is causing the customer some pain. If they enable BC on the SUP will that help out any? If so do I need to worry about forcing the secret to be the same on the SUPs or am I good to just allow BC to manage it? This customer has multiple SUPs in their site Jason From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: 29 May 2015 10:19 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache It’s a bit more complicated than what we have said…. So on Win8 with Server 2012 the clients will detect that no hash is available (we are the first client in the ENTIRE enterprise to get the patch) and starting pulling down the data. Server then catches up and creates the hash and says, “Hey buddy, here’s the hash you asked for!”. The client then gets the hash and continues to download data. This means that from that point, it can share data downloaded AFTER it got the hash with other clients. So this means that most clients gets the hash, even if 3000 machines hits the DP at the same time. So if this is the case, I would leave it up to the DP to create the hashes as it sees fit. Windows 7 and Server 2008R2 is a different story. If there is no hash, clients will never go back to BranchCaching. So the hash is crucial at download start. Here I would script a fake generated GET with the right headers to force the server to create them. We do this today with a few different tools, PowerShell and .exe’s like our free tool HashiBashi. But if there are a lot of Win2Kr2 people asking for it we should clean that story up and make it downloadable. At server startup the DP then re-iterates the packages and creates the hashes, so they are ready when the clients come in. Plz let us know if that is needed. It’s really the BranchCache service integrated with IIS that creates the hash, so as long as the BranchCache FEATURE (not the ROLE) is enabled on the box (DP) it will create hashes if the request has the PEERDIST header. //A Ps. If you have multiple DP’s for the same bunch of clients you need to use the same secret key on all the servers, otherwise the hashes will be different and clients cannot share content unless the hash matches. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Wallace Sent: den 29 maj 2015 11:06 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Hi again Andreas On the SUP piece when a site has more than one SUP do you just allow BranchCache to calculate the hash-key or do you force it to be the same (as would CM for the DPs) or does it not matter? Jason From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: 29 May 2015 09:32 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Man, being late to the party sucks... thought you covered my shift Senior? The One time I am away… grrr. ☺ So a Pro machines has BITS had PeerDist-Common-BITS-Client-Enabled license info set. Which means that BITS will try to use the BITS API (Which is available in full) on a Pro Machine. Pure HTTP(s) connections on Enterprise that goes through winhttp.dll or wininet.dll will be BranchCache aware out of the box. So intranet/extranet to any BranchCache aware server will use BranchCache. .Net is not using that, so will not use BranchCache at all. BranchCachi enabling the SUP is a major win, especially on Win8/2012, as most content is the same so de-dup kicks in. In our labs we see about 70% reduction in transfer rate as content is already downloaded in the de-dup aware cache. So only 30% data will be downloaded, of course using BranchCache its only downloaded once. So 20 machines pulling down 1gig of patches without BC equals 20gig, right. With BC 70% is already down there, so only 300meg needs to be transferred. Which is done by one or two clients and then shared. It’s like magic. 300 MB is doable over a slow link, 20GB not so much… //Andreas Ps. Another thing, never use the BITS policy in ConfigMgr if you are using BranchCache. It’s using an old XP compatible schedule which cripples BC intra-LAN transfers to go at the same speed as BITS, major booboo. Use the new win7 policy with the check box to allow full speed intra-LAN. BC will lower transfer rate automagically to 45Mb/s to ensure sharing hosts are not overwhelmed. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Wallace Sent: den 29 maj 2015 10:14 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] BranchCache Hi Phil Thanks for the correction on protocol. To explain (and this is my understanding amid the confusion that is the documentation) what I was trying to say: The functional difference between Pro and Enterprise is that in Enterprise Branchcache is able to leverage BITS over SMB while in Pro this is limited to just HTTP. Of course this is all pretty much irrelevant for CM operation as the content is accessed from a DP via HTTP. One thing that my BranchCache customer has not done is to implement this on their SUPs. What's your take on doing this? On 28 May 2015, at 22:50, Phil Wilcock <[email protected]<mailto:[email protected]>> wrote: Phew! Hate getting to a thread late.. Interesting reading down this thread. What it does highlight is the way that BranchCache is misunderstood – and I think that MS must shoulder some of the blame for that ☺ So, yes it works fine across many thousands of sites. And yes, Server 2012 works better than 2008 as a content server – with 2012 you get the added bonus of Dedup + BranchCache too. It works fine on Windows Pro versions, because it is BITS (not http) that is ‘BranchCache aware’ – and it is BITS that SCCM uses so you’re fine. You can also use it in TS/OSD/WinPE (with some free tools from us – we just added Win10 support too) If you have Win 7 clients with Server 2012 it’s not quite as efficient (V1 hashing isn’t as efficient as V2 (Win8.x) hashing) but still works fine. Yes tiny files have to be retrieved over the WAN as there’s a tradeoff in efficiency – but as the blog states, it can be tweaked and works fine. Finally – feel free to email me offline if you have any Q’s around BranchCache/BITS etc. Cheers Phil From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Roland Janus Sent: 28 May 2015 18:18 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Andreas didn’t chime in yet ☺ Basically on 2008 1. If there is no hash calculated yet (which is required), the first client triggers the calculation when downloading (into SCCM cache), doesn’t populate branchcache 2. The 2nd client downloads into the cache and sccm 3. The 3rd client can use the 2nd 4. The first will never have it unless it has to download again. You see? Worst of all. Once the server is rebooted, the hash is gone, start over… Whatever they were thinking then. 2012 doesn’t do that. Overall, it’s basically a no brainer once implemented and it will save (a lot of) bandwidth potentially. -R From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Sean Pomeroy Sent: Donnerstag, 28. Mai 2015 17:53 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] BranchCache What does server 2008 R2 vs 2012 have to do with it? On Thu, May 28, 2015 at 11:41 AM David Jones <[email protected]<mailto:[email protected]>> wrote: We have 2008R2 On Thu, May 28, 2015 at 11:29 AM, Roland Janus <[email protected]<mailto:[email protected]>> wrote: Most importantly: While windows 7 is fine, you really need server 2012 for the DPs. If you’re stuck with 2008, that’s another story. -R From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of elsalvoz Sent: Donnerstag, 28. Mai 2015 15:27 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] BranchCache It doesn't work well or as advertised that's why many do not use it, the return is not worth the headache. This I've heard from colleagues and this list since I haven't tried it personally in production. The recommendation is to use 3rd party tools provider like 1e or adaptiva that have done intensive development on their tools. Cesar A On May 28, 2015 6:19 AM, "David Jones" <[email protected]<mailto:[email protected]>> wrote: There is not a whole lot written about this. Is anyone here using it? Your thoughts? Dave
