Ok, this may be a silly question, but how does a SUP use branchcache? The SUP doesn't actually distribute the patches to the PC's, it just contains the catalog of updates that the clients check against, correct?
On Fri, May 29, 2015 at 4:50 AM, Andreas Hammarskjöld < [email protected]> wrote: > 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]] *On Behalf Of *Jason Wallace > *Sent:* den 29 maj 2015 11:28 > > *To:* [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] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* 29 May 2015 10:19 > *To:* [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] <[email protected]>] *On > Behalf Of *Jason Wallace > *Sent:* den 29 maj 2015 11:06 > *To:* [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] <[email protected]>] *On > Behalf Of *Andreas Hammarskjöld > *Sent:* 29 May 2015 09:32 > *To:* [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. J > > > > 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] <[email protected]>] *On > Behalf Of *Jason Wallace > *Sent:* den 29 maj 2015 10:14 > *To:* [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]> 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 J > > > > 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] <[email protected]>] *On > Behalf Of *Roland Janus > *Sent:* 28 May 2015 18:18 > *To:* [email protected] > *Subject:* RE: [mssms] BranchCache > > > > Andreas didn’t chime in yet J > > > > 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] <[email protected]>] *On > Behalf Of *Sean Pomeroy > *Sent:* Donnerstag, 28. Mai 2015 17:53 > *To:* [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]> > wrote: > > We have 2008R2 > > > > On Thu, May 28, 2015 at 11:29 AM, Roland Janus <[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]] *On Behalf Of *elsalvoz > *Sent:* Donnerstag, 28. Mai 2015 15:27 > > > *To:* [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]> wrote: > > There is not a whole lot written about this. Is anyone here using it? > Your thoughts? > > > > Dave > > > > > > > > > > > > > > > > > > > > > >
