Yeah, it depends on a lot of things… Since the DTS job also randomizes the order of files in package you might have several downloads of the same package but different files going. Which is hard to combat with the BITS policy and BC will never know about that situation.
//A From: [email protected] [mailto:[email protected]] On Behalf Of Phil Wilcock Sent: den 2 juni 2015 12:22 To: [email protected] Subject: RE: [mssms] BranchCache And in a perfect world, you would have one client pulling from the Content Server (DP) and the rest pulling locally from that client. But that’s a whole other story ☺ From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: 02 June 2015 11:06 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Short story, on Win7-8.1 you cant. Long story, on Win10 you can, but its heap of info. Since each segment is reported which clients offered and which client it got it from its just too much info to make sense. There is a thread on our forum about it I believe. I think a better way is to report on the stats of how much data your clients give out to others. But that removes the capabilities to report on certain packages etc. This can also be done on Win7-8 through MOFinf the BC perf counters and report on them. Also, if you have 3 clients with the content you will find that it got roughly about 33% from each clients. So the reports get a bit boring after a while as BC is really efficient of sharing among the group. //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kehl Reto Sent: den 2 juni 2015 11:42 To: [email protected]<mailto:[email protected]> Subject: AW: [mssms] BranchCache I have just implemented BranchCache and also installed those great reports from 2Pint Software (http://2pintsoftware.com/products/branchcache-reporting/), many thanks! how can I find out which client serves the content? Von: [email protected]<mailto:[email protected]> [mailto:[email protected]] Im Auftrag von Matt Browne Gesendet: Montag, 1. Juni 2015 17:01 An: [email protected]<mailto:[email protected]> Betreff: RE: [mssms] BranchCache This was a really useful conversation btw. Thanks to everyone for the comments and links etc. Branchcache is something we’ve been meaning to look at for a while, but I had a few concerns and question. This has answered pretty much all of them ☺. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Phil Wilcock Sent: 29 May 2015 23:30 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Perfmon on the server gives quite a decent overview of how much data you have saved by using BranchCache over time https://technet.microsoft.com/en-us/library/ff468720%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Russ Rimmerman Sent: 29 May 2015 23:16 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache I created a powershell script that parses the branchcache events and totals up the “bytes from peer” and stuffs it into WMI. It has a math bug I’ve not had a chance to fix but it’s 97% completed otherwise. If you’re powershell savvy and feel like tracking/fixing it I’ll be happy to share ☺. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Wallace Sent: Thursday, May 28, 2015 9:47 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] BranchCache Yeah – that’s one of the pains – the only way you really CAN tell is by checking out the perfmon counters on the clients themselves. I guess that as that data is WMI’able you could gather it somehow From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Steve Whitcher Sent: 28 May 2015 15:38 To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] BranchCache I have branchcache enabled on my distribution points here, although honestly I don't have any measurements of how much WAN traffic it saves us. I know it's used, as when I have occasion to go through client logs to troubleshoot a deployment I sometimes see log entries that show it using branchcache for packages. I probably should try to figure out just exactly how much data is being distributed by branchcache instead of over the WAN, but at best that's a project for the "spare time" list, and that's a long list. Steve On Thu, May 28, 2015 at 9:23 AM, David Jones <[email protected]<mailto:[email protected]>> wrote: Thanks for the feedback. I have one question about a blog post at 2pint. Has anyone found this to be a problem? Does this mean that for the very small files within a package all computers will have to go back over the WAN to a DP to get them? Dave ==== WARNING TEST THIS FIRST OR WE’LL ALL BE DOOMED I TELL YOU! BranchCache has a built-in filesize limit, under which it will ignore content. By default that is set to 64k, which is fine for a lot of scenarios. If, however your content contains lots of small files, (think xml, config files, sharepoint, web pages, need I go on!?), then you might want to implement this little registry hack. So, go to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\PeerDistKM\Parameters)- on your BC server. The value that you need to change is MinContentLength You do need to cycle the BranchCache service for this to take effect so bear in mind that you will lose your existing BC content hashes and will have to recreate them. Set this to something smaller than the default of 64k, then do some testing to see if your wee files are indeed being cached – don’t just throttle it right down straight away! I’ve had it down to 4096 (4k) and it behaves perfectly well, but be aware that changing this setting can and will have an effect on BranchCache performance so tread lightly. Cheers! Phil 2Pint On Thu, May 28, 2015 at 10:04 AM, Jason Wallace <[email protected]<mailto:[email protected]>> wrote: I would have to disagree with you on that. Branch Cache does indeed work well and performs as expected. There are certainly some pieces where OneSite and Nomad offer functionality that is plain not provided within Branch Cache but generally with Branch Cache you configure it once on the devices and it plain works. While Branch Cache Regards “intensive development” Branch Cache was introduced in Windows VISTA and has been included and supported in the Windows family ever since. The developers have done a good, sound job and the feature is largely without issue. A reasonable and responsible recommendation is to evaluate products alongside other solutions and to propose the solution that best meets your customer’s budget and needs. FWIW I have deployed a Branch Cache solution to an estate with 1400 sites globally and I presently support a CM2012R2 estate of 22,000 devices running almost exclusively on Branch Cache and an organisation considerably larger than this with OneSite. Perhaps you’d like to point out where you feel Branch Cache is inferior and we can then approach matters constructively Jason From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of elsalvoz Sent: 28 May 2015 14: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 ________________________________ Information in this message is sent in confidence and is intended only for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, any use, distribution or copying of the information is strictly forbidden. Please notify the sender immediately by return email or telephone 01823 721400. If you received this email in error please delete it and any copies of it from your system. Viridor Waste Management Limited Registered Office: Peninsula House, Rydon Lane, Exeter EX2 7HR Registered in England No. 575069 ________________________________
