Hi, Yes you will really reap the benefits once you start to roll out more Win8/10 clients. And yes, in essence, BranchCache will only transfer a chunk once – then use it for any files that need it. So if you have 10Gb of content that is 1Gb when De-duped, you will only get that 1Gb copied over the network, and it will only take up 1Gb of Cache space. Also when you re-distribute that content, only the chunks that have changed will be transferred. And no, I wouldn’t exclude zips, or any other archive type..
Your BITS settings look fine, just remember that if an install is triggered by a user via Software Center – the BITS job that SCCM creates is set to FOREGROUND priority for some crazy reason, and will ignore every policy you have in place ☹. Well done ConfigMgr team. From: [email protected] [mailto:[email protected]] On Behalf Of David Jones Sent: 23 July 2015 12: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
