SCEP Updates filling ccmcache

[dustin033]

Is there a way to prevent SCEP updates (AM_delta_patch_xxxxx) from being downloaded into the C:\Windows\ccmcache folder? I thought this would only be the case when using Configuration Manager to distribute SCEP updates, but it seems to be happening with only WSUS and Windows Update selected.

[Jorgen Nilsson]

Hi,

The only way is to use UNC for downloading the definition updates. WSUS and Microsoft Update will not place the files in the CCMCache but then you must make sure that the client isn't targeted with the updates as well.

Aren't the defition files purged when the cache fills up?

Regards,
Jörgen​

[dustin033]

We haven't been on SCCM 2012 very long, so I can't say if the cache is purged. We would rather not use a UNC path.

 

My test consisted of removing ConfigMgr as a source from the Antimalware policy, but we do still have an ADR running and deployment set for definition updates to all endpoint managed systems. Sounds like you're saying I need to make sure the test machine isn't targeted by this in order for this test to be valid.

[h4x0r]

Is there a reason you don't want to use the UNC share? Next to WSUS, it is probably the easiest method for having those updates available for clients. There are scripts out there which will download the updates for you, so all you have to do is schedule the script to run on your server at set intervals.

[dustin033]

We already have a SUP and WSUS set up, and I believe we used WSUS in 2007. Just trying to stick with what worked for us. We may end up just using Microsoft Update for definition updates.

[dustin033]

My tests show that using Microsoft Update as a source does not place the updates in the ccmcache folder, but WSUS does. How do I verify where the updates are actually coming from?

[HotdogSCCM]

Disable your ADR. That will prevent the updates from showing up in the ccmcache.

 

As for validating, check the WindowsUpdate.log file. It'll show where the files are being stored when they're actually coming from Microsoft/WSUS. Otherwise, your ADR will be being processed, which can be located in the UpdatesDeployment.log and CAS.log, you'll need to correlate those two to validate the files in question.

 

The CCMCache has a number of write ups about it; for example:

 

http://blogs.technet.com/b/manageabilityguys/archive/2013/05/07/configmgr-2012-client-cache-part-1-overview.aspx

 

From there:

 

 

So, does the cache actually maintain itself? Well, content remains in the cache for at least 24 hours, after that time it’s available to be overwritten by new content if it requires the space. If you configure your packages to persist content in the client cache, the client will not automatically delete the package/overwrite content in the cache. If the client cache space is used by packages that have been downloaded within the last 24 hours and the client must download new packages, you can either increase the client cache size or choose the delete option within the control panel applet of the client to delete contents of the cache. (See screenshot above)

 

If your CCM cache is set up correctly for your environment, the placing of the SCEP files in there is no different than any other files; be it normal patches, applications, packages, etc; it'll maintain and clean itself as needed.

[dustin033]

The collection that is targeted by the ADR does not include the machines that I'm testing with. Why is it still affecting these machines?

 

Thanks for the info - I'm aware of the ccmcache maintenance process. Here's a little more background....we have some servers with relatively low disk space. This isn't a problem until the ccmcache has a bunch of SCEP updates in it every few days. I could set the cache size very low, but then I run the risk of not being able to install anything somewhat large. That's why I'm just trying to get it to work with WSUS and not place updates here.