We have SCCM 2012R2 installed on Server 2012R2, and all of our clients are Win7 Enterprise with BranchCache enabled in various modes.  SCCM 2012R2 clients download content from this server via BITS, which uses BranchCache.  I first noticed a problem on the server where the amount of Committed Memory for the svchost.exe associated with PeerDist (BranchCache) was growing larger & larger over time.  It eventually got up to over 40GB of Committed Memory, and because we had the virtual memory file set to a specific size, we started seeing Resource Exhaustion events in Event Log.  I checked the BranchCache Event Log & saw it was also full of Event ID 13 ("BranchCache cannot publish the content with content-id ... because the publication cache size was exceeded or the disk does not have enough space.  Error: 5 Access is denied.").  We decided to have another disk added to the server, move the virtual memory file to it, leave its size "system managed", and I configured BranchCache to use the new disk, so we would have more space available for the hashes.  I tried to generate the content hashes ahead of time via publish-bcwebcontent.  This worked for the first directory, but the second one generated this exception after an hour or 2 of running:

publish-bcwebcontent : Could not generate hashes.
At line:1 char:1
+ publish-bcwebcontent -path X:\somedirectory -recurse -useversion 1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (MSFT_NetBranchCacheOrchestrator:root/StandardCi...cheOrchestrator) [Pub
   lish-BCWebContent], CimException
    + FullyQualifiedErrorId : HRESULT 0x80070003,Publish-BCWebContent

Checking get-bcstatus, we are nowhere near the max sizes for either the hashcache or datacache, and I am seeing these same Event ID 13 for BranchCache in the Event Log now.  Any commands dealing with hashcache are now taking a few minutes to run before displaying any output.  Some of the Event ID 13's mention that a file is in use as the reason for the error, but most say "because the publication cache size was exceeded or the disk does not have enough space.  Error: 5 Access is denied."  The new location of the PeerDistPub folder has over 3.3 million files in it within 11 folders.  I let the folder properties run for about 15 minutes to get this info, and the numbers are still going up. 

At some point, we started getting run-away Event ID 13s.  1000's of them.  And this is when the svchost.exe for PeerDist starts increasing its Committed Memory.  I've restarted the BranchCache service, and I've seen 1 Event ID 13 since.  The details on this one say "because the publication cache size was exceeded or the disk does not have enough space.  Error: 112 There is not enough space on the disk."  But that is not true at all - there is plenty of room to grow the hashcache & datacache, as verified by get-bcstatus output, and plenty of free space on the disk.

I've tried uninstalling the BranchCache feature, rebooting, reinstalling, reconfiguring, and re-generating hashes, but have run into the exact same problems.

Any ideas of how to troubleshoot this one?  Thanks in advance!

hi Shaun,

what size, or % of disk do you have the hashcache set for?

The rule of thumb is (ContentSize) / 2000  * 1 (if only generating V1 hashes, or  *2 if both). As you only have Win7 clients you only need V1 hashes, and that can be set by GPO - look for 'Hash Version Support for BranchCache'

Also, have you considered using De-Dup on the SCCM DP? 

If the content is 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.

Careful with SCCM though, you can't de-dup the content source folders..only the ContentLib. There's an article about that somewhere..

cheers

Phil

Hi Phil - Thanks for the reply.  We currently have a 60GB disk for virtual memory & BranchCache with 37GB free.  Cache stats:

HashCache:

    CacheFileDirectoryPath               : F:\BranchCache\PeerDistPub
    MaxCacheSizeAsPercentageOfDiskVolume : 30
    MaxCacheSizeAsNumberOfBytes          : 19286457120
    CurrentSizeOnDiskAsNumberOfBytes    : 4390890182
    CurrentActiveCacheSize                       : 69392023

DataCache:

    CacheFileDirectoryPath               : F:\BranchCache\PeerDistRepub
    MaxCacheSizeAsPercentageOfDiskVolume : 5
    MaxCacheSizeAsNumberOfBytes          : 3214409520
    CurrentSizeOnDiskAsNumberOfBytes    : 29433874
    CurrentActiveCacheSize                       : 0

    DataCacheExtensions:

The combined total size for the other disks is 230GB, so the 18GB for the hashcache should be more than enough.  I'm aware of Server 2012's de-dup capabilities, but we don't want to introduce any new variables into the mix right now.  Just looking to figure out this problem.  Thanks!

hi,

from another thread - but might be worth a try

working with BC means a lot of random IO. Still performance was very, very bad. Processmonitor as well as Resource Monitor revealed BC was working from the pagefile all the time, generating lots and lots of small IO's to the pagefile (which is on the very same disk array).

So perhaps try disabling Paging providing you have plenty of ram in there? (worked for the case above)

cheers

Phil

Thanks for the reply!  I don't want to risk running out of memory on this production server though, so I'm probably not going to try this, but maybe it would be worth trying to put the pagefile & the branchcache files on separate disks?  This is all running in VMware with enterprise storage on the backend.

Sure, that may help, but worth running ProccesMonitor/Perfmon etc to see if it is a memory/paging problem first.

thanks

Phil