Just tested this in 1606, and for User launched Applications, the BITS job is still created as FOREGROUND (or Hell for Leather as we like to call it) priority…
User launched Package/Programs however come with a BITS priority of LOW – much more sensible. Created a UserVoice item for this – so feel free to vote your asses off.. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/15351201-bits-priorities-for-user-initiated-deployments Easy fix for them ConfigMgr folks ☺ Phil From: [email protected] [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: 22 July 2016 08:28 To: [email protected] Subject: RE: [mssms] Bits and BranchCache revisited 1602 you say, haven’t tested with Apps, could be that they forgot to reset that. So maybe the good ol’ (not RTM yet) does have a fix for you. //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jay Marsett Sent: den 22 juli 2016 01:07 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Bits and BranchCache revisited Phil, So far all of our testing is with Windows 7, as that is 9/10ths of the current system footprint. We do have the "goldilocks" patches for bits in win 7 applied in the test images. We are also using the GPO based Bits policy, I believe using the "win7" bits version policy, but will double check tomorrow. We also have the "ignore" policies for subnet transfers, in the gpo. Definitely not using configmgr based Bits policy. Will try what you suggested about testing the branchcach via IE from our troubled system, was not something that had occurred to me. Thanks again everybody. On Jul 21, 2016 17:53, "Phil Wilcock" <[email protected]<mailto:[email protected]>> wrote: Pretty sure that the Foreground issue was fixed in Current Branch. Also relevant is the OS version and the type of policy that you are using – if Win7 there are a couple of hotfixes that you need that stop BITS from ignoring policy, and even in Win10 there were still some minor bugs until recent builds affecting BITS policy. Using the built-in ConfigMgr policy is not as effective as using the newer policies for Work and Maintenance schedules, which also allow you to specify that peer transfers using BranchCache ignore the rate limits if on the same subnet.. Regarding the machine that’s going back to the DP – check the BITS log for errors, and try to grab the same content using IE and see if BranchCache behaves the same. Phil From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Jay Marsett Sent: 21 July 2016 18:57 To: [email protected]<mailto:[email protected]> Subject: [mssms] Bits and BranchCache revisited Finally have some real feedback about BranchCache and BITS. Got our site built and began unit testing, What we found so far; 1. Seems like all Package and Program downloads are BITS background transfers, so they follow rate limits, however, User initiated Application downloads STILL happen in the foreground. Anyone seen any documentation that explains that? 2. Seeing a single test machine that randomly seems to have issues as large transfers from Branchcache are occuring. The system becomes unstable, freezes as the hybrid drive software (lenovo expresscache) seems to peg the HD, as this is occuring, the transfer from cache seems to stop, and it begins to transfer from the DP. Then randomly, back to the BranchCache. Seems to happen with any type of "Cacheable" content, but only user initiated Application installs seem to ignore the BITS rate limits. Anyone seen this behavior? Have any documentation that can explain it? We haven't yet debugged the problem laptop yet, but theoretically, all of our test systems are identical. Long story short, it makes it impossible to use self service with the AppCatalog if we can't reasonably plan for when this type of issue might occur in this BranchCache with BITS model. If all Application based pushes need to be background, we can't use self service. Please let me know your thoughts.
