Andreas ( or anyone that knows), Can you explain the PS at the end a little more. I'm not familiar with a new way to set BITS speeds in Windows 7.
----- Dwayne Allen [email protected] (479) 310-0027 On Fri, May 29, 2015 at 3:32 AM, Andreas Hammarskjöld < [email protected]> wrote: > 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]] *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 > > > > > > > > > > > > > >
