Oops, didn't see Jason's last message before sending that last email.  So
it IS just the catalog that you're talking about using branchcache for on
the SUP.  I hadn't considered that the catalog downloads might be enough to
cause issues.

On Fri, May 29, 2015 at 5:55 AM, Steve Whitcher <[email protected]> wrote:

> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>



Reply via email to