Hey,

Add all files, it’s just encrypted files that won’t be de-duped. But de-dup 
service checks that for us, so just add it all. I think Rob has gotten the 
“already compressed” bit somewhat wrong, de-dup doesn’t compress anything, it’s 
just removes duplicate file blocks. So go nuts! Keep in mind that there are 
some VSS limitations for de-dup, think volume has to be smaller than 64TB, will 
try to find that.

The way that de-dupe and BranchCache works on the server: If the files are 
stored on a de-duplicated volume then there is no need to generate hashes as 
the deduplication process also generates hashes compatible with BranchCache. 
Thus BranchCache works best when accessing a de-duplicated volume on a Windows 
Server OS, as there is no need to create the hashes.

General file server should be good enough, if you want to be sure either 
trigger a PowerShell command when a new package is distributed to it, or 
distribute packages before clients download, in order to allow de-dup process 
to generate the BranchCache/de-dup hash.

De-dup hash is only working with V2 clients, so if you are looking to 
distribute to Windows 7 you need to script the V1 generation or let time have 
its toll.

Generally de-dup works better with larger files, so if you can, zip up the 
content and expand it as part of the install. Each file will generate a 
BranchCache Probe request and each client replying with a ProbeMatch response. 
(Simplified). So that will add a latency aspect if you have 10,000 files that 
are 70KB large.

//Andreas

From: [email protected] [mailto:[email protected]] On 
Behalf Of David Jones
Sent: den 23 juli 2015 13:34
To: [email protected]
Subject: Re: [mssms] Getting BranchCache Configured

OK. I have taken your advice. I replicated the DP's then de-duped. I had to set 
the dedup to any file 0 days or older to get it work since it was a new DP. The 
article you recommended suggested not including compressed files in the dedup 
such as PNG, CAB, ZIP, LZA, 7Z (I added 7Z). Do you agree with that 
recommendation? Since these are physical servers, I set data deduplication to 
'General purpose file server'. You say that dedup saves bandwidth when sending 
to the workstation BC. Does it only send the chunk once then tell the BC client 
to keep using it each time it is needed? I will set up the BITS in GP, however 
I can't turn off the BITS settings in the SCCM Client settings until we deploy 
this full house. We are deploying to a small workstation OU first to see how it 
goes. We have some Win8 and will be testing Win10 soon so I will keep both 
hashes. We have a ton of small files in our packages so I set the min size to 
4k. And I ran the powershell command to pre hash what is there now. This has 
been very simple.


Here is the meat of the email I will send to the folks who will create the GP:


There are 4 GP settings to make. One setting is under Background Intelligent  
Transfer Service (BITS). Three settings are under BrancheCache.

[Inline image 1]

1.     Under BITS:  Set up a work schedule to limit the maximum network 
bandwidth used for BITS background transfers

a.     Enabled

b.      Check the box: Ignore bandwidth limits if the source and the 
destination are on the same subnet

c.       Work Days: From Monday to Friday

d.      Daily Work Hours:  6am to 6pm

e.       Bandwidth Limits During Work Hours: High 0/Unlimited, Normal 2/Mbps, 
Low 1/Mbps

f.        Bandwidth Limits During Non-Work Hours: all 0/Unlimited
     2. Under BranchCache: Turn on BranchCache = Enabled
     3. Under BranchCache: Set BranchCache Distributed Cache mode = Enabled
     4. Under BranchCache: Set percentage of disk space used for client 
computer cache

a.     Enabled

b.      Set to:  50
Dave




On Wed, Jul 22, 2015 at 4:17 PM, Phil Wilcock 
<[email protected]<mailto:[email protected]>> wrote:
Nah I didn’t miss it – just checking that you were awake ;-)

And yes, the SCCM BITS policy harks back to the XP days – that’s why it was 
there, for the backwards compatibility I guess… That whole policy should just 
be retired as it confuses an already confused audience!

Phil

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>] 
On Behalf Of Andreas Hammarskjöld
Sent: 22 July 2015 17:12
To: [email protected]<mailto:[email protected]>
Subject: RE: [mssms] Getting BranchCache Configured

Most important, cant believe you missed that Senior ;-) , is to NEVER use the 
ConfigMgr BITS policy. It cripples the P2P to the same speed as the DL, 
grinding it all down to a slow mess.

Pointed this out to the ConfigMgr team a long time ago but they obviously don’t 
care as its still like that in TP2. There is a feedback item on Connect for it 
if they should start caring about BrancCache again.

Should really add a FAQ item for this: You need the AD policy to get the right 
BITS policy for BranchCache. Set the “Set up a work schedule to limit the 
maximum network bandwidth used for BITS transfers” policy, disable all other 
old as they don’t work well together, and ensure that you check the “Ignore 
bandwidth limits if the source and the destination are on the same subnet”.

//A

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Phil Wilcock

Sent: den 22 juli 2015 17:26
To:
[email protected]<mailto:[email protected]>

Subject: RE: [mssms] Getting BranchCache Configured

Hi David,

You pretty much got it covered. Few points to note inline below:

Aside from that I would add the following.
If you only have Win7 clients – consider setting the server to only create V1 
hashes. By default they will create V1 and V2 (Win8)
You can set this with a server policy - Hash Version Support for BranchCache
If, however you are moving to Win10 in the near future – don’t forget to turn 
on V2!

Finally – if you haven’t already done this – Enable De-Dupe!! This will 
potentially save you a ton more bandwidth, especially if you have a lot of 
common content – think Updates, WIMs, Zips etc.
Andreas wrote a wee blog about the savings just last week - 
http://2pintsoftware.com/branchcache-de-duplication/
And Rob Marshall wrote a great article on how to enable it in SCCM! 
http://wmug.co.uk/wmug/b/r0b/archive/2014/02/21/windows-2012-server-deduplication-and-configmgr-2012

Any questions, of course just ping us offline

Cheers

Phil


Phil Wilcock
2Pint Software
http://2pintsoftware.com<http://2pintsoftware.com/>
@2pintsoftware<https://twitter.com/2pintsoftware>





From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of David Jones
Sent: 22 July 2015 15:38
To: [email protected]<mailto:[email protected]>
Subject: [mssms] Getting BranchCache Configured

I get the impression that configuring BranchCache is quick and easy. I just 
want to make sure I have my thoughts on this straight.

I have a CAS and 2 Primaries, SCCM 2012 R2. Other than that I have Distribution 
Points. Each Primary is a different site code of course. Each site has a DP 
that is set to Allow Fallback. It is these DP's that I want to be the root of 
BranchCache for each site. Both of these DP's are Server 2012 R2. These 2 DP's 
are the same in terms of packages. Each has all packages created. Since they 
are set to allow fallback, all computers from both sites can use each one.  All 
clients are Win 7 Pro.

I have checked the box to Allow BranchCache on both DP's and BC is now 
installed on both servers via SCCM. I am OK using the SCCM BITS settings.  I 
already have the daytime BITS throttled to 2MB.


1.      I am thinking that all I need to do now on the servers is set both to 
have the same server secret phrase so all computers can continue to use both 
servers in BC.

Correct – you need this so that clients can all share content with each other 
no matter which DP they got it from.

2. For the Win7 Pro environment, all I need to do create GP the following 3 
settings;
    a.  Turn on BranchCache = enabled
    b.   Set BranchCache Distributed Cache mode - enabled
    c.   Not Needed but; Set percentage of disk space for client computer cache 
= enabled set to 50


2.      I could use HashiBashi to preset all the hashes. Do I just run it once 
for each main DP folder, SCCMContentLib, SMSPKGD$, and SMSSIG$?

HashiBashi is just a ‘quick and dirty’ tool to check individual content hashes. 
As you have WS2012R2 you can use PowersShell to create the hashes, and you just 
need to do it for the SCCMContentLib folder. So the syntax would be:

Publish-BCWebContent –path <drive letter>:\sccmcontentlib -recurse


3.      Additionally I could set the MinContentLength to 4k. Does this have to 
be set on every computer or just the servers?

Just the servers. You have to cycle the BranchCache service for this to take 
effect. You only need to use this if your content has a lot of small files, but 
it can save extra bandwidth.

Dave










Reply via email to