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]] On
Behalf Of Roland Janus
Sent: den 29 maj 2015 22:15
To: [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
