How to Increase SCCM Client Cache Size: 4 Proven Methods (2026)

Your large software deployment just failed because the SCCM client cache ran out of space. You're not alone—I've seen this happen in environments ranging from 500-seat schools to 50,000-device enterprises. The default 5 GB cache simply wasn't designed for today's bloated applications and feature updates.

The good news? You have four solid ways to fix this, and I'll walk you through each one—including a workaround for that frustrating 99999 MB hard limit that's been haunting ConfigMgr admins since 2018.

What Is the SCCM Client Cache and Why Does Size Matter?

Before we dive into the how, let's talk about what we're actually adjusting. The SCCM client cache—technically the CCMCache folder—is a staging area where the client downloads content before installing it. Think of it as a loading dock: packages arrive, get unpacked, and then get moved into production.

Default Cache Size and Location

Out of the box, the ConfigMgr client cache sits at C:\Windows\CCMCache with a default size of 5 GB (5120 MB to be precise). Microsoft's documentation [needs verification] states this as the standard since Configuration Manager 2012, and it hasn't changed through the current MECM 2303 release.

Five gigs might have been plenty back when we were deploying Office 2010. But today? A single Windows 11 23H2 feature update can chew through 6-8 GB during pre-caching alone.

Common Scenarios Where You Need to Increase the Cache

Here's where I've seen the 5 GB limit become a real bottleneck:

• Large OS upgrades: Windows 11 feature updates (23H2, 24H2) routinely require 6-10 GB of staging space. I've had clients where the upgrade failed silently because the cache filled up mid-download.
• Pre-caching for Peer Cache or BranchCache: When you're trying to distribute content across your network efficiently, the cache needs to hold entire packages. A single Visual Studio 2022 enterprise install package can hit 4-5 GB.
• Deploying large application suites: Adobe Creative Cloud, AutoCAD, or full Microsoft 365 Apps for Enterprise—these aren't small. I've seen Adobe packages exceed 8 GB.

The pattern is clear: if you're doing modern Windows management, you'll hit the cache ceiling eventually.

Method 1: Increase SCCM Cache Size via Client Settings (GUI)

This is the method most admins start with, and for good reason—it's right there in the console. But it comes with some gotchas you need to know about.

Step-by-Step Configuration in the SCCM Console

Here's how to change SCCM cache size through the GUI:

1. Open the Configuration Manager console and navigate to Administration > Client Settings.
2. Right-click and create a new custom client setting (or modify an existing one).
3. Select the Client Cache Settings group.
4. You'll see two options: set a maximum size in MB, or set a percentage of the total disk. I usually recommend using both—the client will respect whichever limit is hit first.
5. Set your values. For a typical environment, I start with 20480 MB (20 GB) and 20% of disk.
6. Deploy this policy to your target collection.

The policy refresh happens on the normal client polling cycle (every 60 minutes by default), or you can force it with gpupdate /force followed by a ccmexec.exe -policy trigger.

Limitations of This Method

Here's where things get frustrating. The GUI method has a hard-coded limit of 99999 MB—roughly 97.6 GB. This isn't a design choice; it's a known bug that's been documented since at least 2018. Microsoft has acknowledged it, but given ConfigMgr's current maintenance mode status, don't hold your breath for a fix.

There's another limitation: this method can't dynamically adjust based on free disk space. If you set 20 GB and the drive only has 15 GB free, the client won't adapt—it'll just fail to download content.

Method 2: Increase SCCM Cache Size Using PowerShell (Dynamic Script)

If you want more flexibility than the GUI offers, PowerShell is your next stop. I've been using this approach for years, and it's particularly useful when you need to increase SCCM cache size PowerShell-style across hundreds of machines.

Using the UIResource.UIResourceMgr COM Object

The simplest PowerShell approach uses the COM object that ConfigMgr exposes:

$UIResourceMgr = New-Object -ComObject UIResource.UIResourceMgr
$Cache = $UIResourceMgr.GetCacheInfo()
$Cache.TotalSize = 20480  # Size in MB
$Cache.Commit()

This works, but it has the same 99999 MB limit as the GUI method. The COM object and the client settings share the same underlying code path.

Advanced Script: Dynamic Cache Based on Free Disk Space

Here's where PowerShell really shines. I wrote this script years ago for a client who had wildly different disk configurations across their fleet—some machines had 120 GB SSDs, others had 500 GB HDDs. Setting a static cache size for everyone was impossible.

Function Get-FreeSystemDiskSpace {
    $SystemDrive = Get-WmiObject Win32_LogicalDisk -Filter "DeviceID='$env:SystemDrive'"
    return [int64]$SystemDrive.FreeSpace
}

$FreeDiskSpaceInMB = [int]((Get-FreeSystemDiskSpace)/1MB)

switch($FreeDiskSpaceInMB){
    {$_ -lt 20480}  {$NewCacheSize = 6144}   # <20 GB free: set 6 GB cache
    {$_ -ge 20480 -and $_ -lt 49600} {$NewCacheSize = 10240}  # 20-50 GB: 10 GB
    {$_ -ge 49600 -and $_ -lt 102400} {$NewCacheSize = 20480}  # 50-100 GB: 20 GB
    {$_ -ge 102400} {$NewCacheSize = 40960}  # >100 GB: 40 GB
    default {$NewCacheSize = 10240}
}

If ($NewCacheSize){
    $UIResourceMgr = New-Object -ComObject UIResource.UIResourceMgr
    $Cache = $UIResourceMgr.GetCacheInfo()
    $Cache.TotalSize = $NewCacheSize
    $Cache.Commit()
    Write-Output "Cache size set to $NewCacheSize MB"
}

Deploy this as a Configuration Baseline, and it'll automatically adjust the cache on every evaluation cycle. I've had this running in production for over three years without issues.

Method 3: Bypass the 99999 MB Limit via WMI (Advanced)

This is the method that saved my bacon on a particularly nasty project. We needed to pre-cache a 150 GB Peer Cache job, and every standard method hit the wall at 97.6 GB.

Why the WMI Workaround Is Necessary

The hard limit exists in the UIResource COM object and the client settings policy engine. But the underlying WMI class—CacheConfig in the ROOT\CCM\SoftMgmtAgent namespace—doesn't have that restriction. It's like finding a back door that the front desk doesn't know about.

I first learned this trick from Maik Koster (credit where it's due), and it's been documented on DeploymentResearch.com. It's not officially supported by Microsoft, but it works reliably in my experience.

Step-by-Step WMI Configuration (e.g., 128 GB)

Here's how to set the cache to 128 GB using WMI:

$SplattingWMI = @{
    NameSpace = "ROOT\CCM\SoftMgmtAgent"
    Class     = "CacheConfig"
}

$Cache = Get-WmiObject @SplattingWMI

$Cache.Size = 128000
$Cache.Put()

Get-Service -Name CcmExec | Restart-Service

Important caveats:

• You must exclude these devices from any Client Settings or Baselines that manage cache size, or they'll overwrite your WMI change.
• The CcmExec service restart is mandatory—the change won't take effect otherwise.
• This is a per-machine manual process unless you script it and deploy via a different mechanism.

I've used this for machines that needed to hold 200+ GB of pre-cached content for large-scale OS deployments. It's not pretty, but it works.

Method 4: Skip the Cache Entirely with Task Sequences

Sometimes the best way to solve a problem is to avoid it altogether. If you're dealing with massive content downloads and cache management is becoming a headache, consider bypassing the SCCM client cache location entirely.

Using the 'Download Package Content' Action

Task Sequences offer a "Download Package Content" step that can write to any path you specify:

1. Create a Task Sequence with a single "Download Package Content" step.
2. Point it to your large package.
3. Configure the destination path (e.g., C:\Temp\LargeDeployment).
4. Crucially: Do NOT enable "Download all content locally before starting task sequence" on the deployment. That setting forces content into the cache, which is exactly what we're trying to avoid.

This approach has a few advantages: no cache size limits, no service restarts, and you can clean up the content manually when you're done. The downside? You lose the cache management features—automatic cleanup, content sharing between deployments, and Peer Cache integration.

SCCM Cache Size Best Practices for Large Deployments

After years of trial and error (and more than a few late-night troubleshooting sessions), here's what I've learned about SCCM cache size best practices.

Choosing the Right Size for Your Environment

There's no one-size-fits-all answer, but here's a framework I use:

• Small environments (<500 clients, basic software deployments): 10-15 GB. The default 5 GB is too tight even for basic setups.
• Medium environments (500-5000 clients, some OS deployments): 20-30 GB. This handles most feature updates and application packages.
• Large environments (5000+ clients, frequent OS upgrades): 50-100 GB. If you're doing Windows 11 migrations, go higher.
• Peer Cache scenarios: Calculate based on your largest package plus 20% buffer. I've seen environments need 150+ GB.

The percentage-based setting is your friend here. Setting "20% of disk" adapts to different hardware configurations automatically.

Monitoring and Maintenance

Setting the size is only half the battle. You need to know what's happening:

Get-WmiObject -Namespace ROOT\CCM\SoftMgmtAgent -Query "Select * from CacheConfig"

This returns the configured size and current usage. I run this as a weekly report to catch machines where the cache is filling up unexpectedly.

For cleanup, I use a script that removes content older than 21 days:

$CMObject = New-Object -ComObject "UIResource.UIResourceMgr"
$CacheInfo = $CMObject.GetCacheInfo()
$CacheElements = $CacheInfo.GetCacheElements()
$CutoffDate = (Get-Date).AddDays(-21)

$CacheElements | Where-Object {$_.LastReferenceTime -le $CutoffDate} | 
    ForEach-Object {$CacheInfo.DeleteCacheElement($_.CacheElementID)}

Set up alerts when cache usage exceeds 80% of the configured limit. In my experience, that's the warning zone where you need to investigate before deployments start failing.

Frequently Asked Questions

How do I increase the SCCM client cache size beyond 99999 MB?

The standard GUI and PowerShell COM object methods both have a hard limit of 99999 MB (~97.6 GB). The only reliable workaround is the WMI method I described in Method 3. Use the CacheConfig class in the ROOT\CCM\SoftMgmtAgent namespace, set the Size property to your desired value in MB, and restart the CcmExec service. Remember to exclude these devices from any Client Settings policies that manage cache size.

Can I change the SCCM cache size without restarting the client?

Changes via Client Settings or the PowerShell COM object typically take effect after a policy refresh—no restart required. However, the WMI method explicitly requires a CcmExec service restart for the change to apply. If you're using the Task Sequence bypass method (Method 4), you avoid this entirely since you're not using the cache at all.

What is the default SCCM client cache size and location?

The default cache size is 5 GB (5120 MB), and the default location is C:\Windows\CCMCache. You can change both via Client Settings in the Configuration Manager console. The location can be modified during client installation using the SMSCACHEDIR property, though I rarely recommend moving it from the system drive.

Why is my SCCM cache size setting greyed out?

This usually happens when a higher-priority Client Setting policy is overriding your configuration. Check the policy precedence in the console—the setting with the highest priority (lowest number) wins. Also verify that your custom setting is deployed to the correct collection. I've seen cases where admins created the setting but forgot to deploy it, leaving the default policy in control.

Conclusion

Let me recap what we've covered. You have four ways to increase SCCM client cache size:

1. Client Settings (GUI): Simple, but limited to 99999 MB.
2. PowerShell: More flexible, especially with dynamic scripts, but same limit.
3. WMI: The only way past 99999 MB, but requires service restarts.
4. Task Sequence bypass: Avoids cache entirely for large content downloads.

The method you choose depends on your scale and requirements. For most environments, the dynamic PowerShell script deployed as a Baseline hits the sweet spot of flexibility and simplicity. For those edge cases with massive pre-caching needs, the WMI workaround is your lifeline.

One final piece of advice: whatever method you choose, monitor it. I've seen too many environments where someone set a cache size, forgot about it, and months later wondered why deployments were failing. A little proactive monitoring goes a long way.

Need a head start? Download our free PowerShell script to dynamically manage SCCM client cache size based on free disk space. [Link to resource]