Share via

How to control the folder c:\Windows\CCM\Temp？

  • Article

Question

Monday, January 5, 2015 2:10 AM

I have installed the SCCM2012 in my company.

And I find the free space of c: disk becomes little in every computer with sccm client .

I find the folder c:\Windows\CCM\Temp grows rapidly.

What can I do to control it?

Green Hand In Microsoft.

All replies (37)

Monday, January 5, 2015 7:17 AM ✅Answered

What does the folder contain and how much data is in it?

Torsten Meringer | http://www.mssccmfaq.de

Monday, January 5, 2015 8:44 AM ✅Answered

Hi,

You can specify following properties to configure caching options on clients:

  • DISABLECACHEOPT – If set TRUE, disables the ability of end users to change the client cache folder settings using Configuration Manager in Control Panel.
  • SMSCACHEDIR – Specifies the location of the client cache folder.
  • SMSCACHESIZE – Specifies the size of client cache folder in megabyte.

For more information, please review the link below:

Managing Configuration Manager 2012 Client Cache

http://blogs.technet.com/b/meamcs/archive/2012/10/04/managing_2d00_configuration_2d00_manager_2d00_2012_2d00_client_2d00_cache.aspx

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

Monday, January 5, 2015 12:50 PM ✅Answered

Those files are not normal operational files. Notice that their dates, they are way in the past.

Is this happening on all of your managed clients?

I honestly don't know what is creating them. You should search all of the log files (using PowerShell, WinGrep, or something similar) for occurrences of this folder or file names to see to if you can figure out why and when the ConfigMgr agent is creating them. You should also use ProcMon to verify that the ConfigMgr agent is indeed creating them in the first place.

Jason | http://blog.configmgrftw.com | @jasonsandys

Monday, October 9, 2017 2:30 AM ✅Answered

Just wait for better treatment.

Green Hand In Microsoft.

As stated, it is not recommend that you delete the files using this method. you should either use the cm SDK to clear the cache or contact CSS directly for support.

Garth Jones

Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

Friday, October 13, 2017 8:31 PM ✅Answered | 1 vote

I was able to get to one of the machines experiencing the issue this morning. There is only one folder in C:\Windows\CCM\Temp, which is "express_a140fc0e-d7b0-4180-a42e-de6dd8a1f519.1". This folder is 31.Gb in size containing 43 files. Except for one file, {C3097644-26EE-4DD2-B1F9-8FAAB006DCB9}, they all match the pattern BIT*.tmp. Each file is either OKb or 1,478,211,853 bytes (1.37 Gb), but the hashes don't match. All of these have been created in the last 24 hours. As soon as one download finishes, another starts.

I know it doesn't help from a diagnostic/logging standpoint, but I removed the agent and deleted the CCM folder (In hindsight, I should have at least preserved the logs folder). The client reinstallation was done in an attempt to keep the end user from experiencing the side effects of a full disk. 

I reinstalled the agent (same version, 5.00.8540.1007) 5 hours ago and it seems to have pulled its deployments and reported all of its details back to the site server. The express_a140fc0e-d7b0-4180-a42e-de6dd8a1f519.1 folder was recreated within C:\Windows\CCM\Temp, but now it only has one express update file, windows10.0-kb4038782-x64_4.psf. This file was created an hour ago and the constant download activity seems to have stopped.

Friday, October 20, 2017 11:05 AM ✅Answered

As AMReagan states, we have also gone down the road of removing the SCCM client.  We followed the article https://technet.microsoft.com/en-us/library/bb694276.aspx to remove all traces of the SCCM client.  Once the client has been fully removed, we reinstalled the client.  In our infrastructure, we used the switches "/forceinstall SMSMP=$MP DISABLECACHEOPT=TRUE DISABLESITEOPT=TRUE SMSCACHESIZE=10240 SMSSITECODE=$SiteCode FSP=$FSP"

After monitoring the clients post-install, the problem appears to have been resolved.  We are now looking for the right solution to repair the remaining Windows 10 computers in our infrastructure.

Personally, I'm still wondering if the issue was more related to https://support.microsoft.com/en-us/help/4038782.

Symptom Workaround
After installing this update, downloading updates using express installation files may fail.

This issue has been resolved in KB4041688.

 

Friday, October 20, 2017 1:21 PM ✅Answered

Any news regarding this client behaviour? We have had problems with several (not all) Windows 10 1607 clients and express updates, fixed them by stop using express updates, clearing BITS jobs and delete expressupdate folder in CCM\Temp. Could https://support.microsoft.com/en-us/help/4041688/windows-10-update-kb4041688 be the solution for this problem on 1607 clients?  "Addressed issue where downloading updates using express installation files may fail after installing OS Updates 14393.1670 through 14393.1770."

Friday, October 20, 2017 9:17 PM ✅Answered

Just to clarify, I had disabled express updates and branch cache for troubleshooting purposes and have not re-enabled them yet. The machines experiencing the issue had to have the client re-installed to stop the runaway downloads in C:\Windows\CCM\Temp even with express updates disabled in the SUP role and branch cache disabled in client settings for the PCs. I suspect the problem is stemming from the express updates, not branch cache itself, but can't confirm that or prove that it isn't a combination of the two.

Saturday, October 21, 2017 7:54 AM ✅Answered | 2 votes

Express Updates and SCCM are not quite working too well yet.. so don't use them.

If you want to leverage Express Updates - configure the clients to go direct to Windows Update and get them via Delivery Optimization, that works well.

thanks

Phil

Phil Wilcock http://2pintsoftware.com @2pintsoftware

Monday, January 5, 2015 7:24 AM

Hi Torsten

Tks for your reply.

The files are all *.tmp, and the size of them is almost 10G.

Green Hand In Microsoft.

Tuesday, September 12, 2017 9:01 PM | 3 votes

sorry to dig up an old thread, but i'm not finding much else on this issue.  

in my case, c:\windows\ccm\temp has taken up pretty much my entire drive. i was able to delete a win10 ISO i had been working with from my temp dir to get a couple gigs back, so at least my machine isn't crawling anymore.

machine is a dell latitude 7370 w/ 256gb ssd, and windows\ccm\temp is taking up almost 200gb with 2907 files.  every single file is named with what looks like MSI product IDs or GUIDs.  most have no extension, but 142 of them are *.tmp files. all of the tmp files range from 2k to 120k each and have a date of dec 31, 2000 at 6pm

as for the ones without an extension, 161 of them are exactly 1,205,245,758 bytes each. 2 more are just slightly smaller at 1,166,784,365 bytes and these 2 are timestamped july 11 2017, 5:07pm. the rest are between 1k and 4-5 megs each, and all stamped 8/8/2017 between 4:12pm and 4:28pm.  nothing in this folder is newer than 8/8.  opening a few random smaller files in notepad doesn't show anything human-readable. 

this computer was partitioned/formatted and installed win10 enterprise 1607 back in May 2017.  

we don't specify the ccmache location, only how big it can be (40gb).  and there's plenty of normal-looking stuff in windows\ccmcache\# so that's working right.  as a standard user, i can't delete anything in windows\ccm\temp\ but i CAN delete them as an admin.  i haven't deleted them all because i want to find out where the heck they came from so i can make sure it doesn't happen again, or on any other clients.  all of them seem to be owned by SYSTEM and only admins have full control.  standard users can't open/read them.  

tried using procmon but the path doesn't show up at all - makes sense if the files aren't actually in use.  used windows explorer to search file contents of the ccm\logs dir for the first section of a few of the GUID filenames, but came up dry.  granted, the logs may have aged out since it's been a month since the files were created (assuming those timestamps are accurate).  

checked event viewer to see if i could figure out what was going on 8/8 at 4:12pm. application, security, setup and system all hardly have anything at all from august 8.  if it wasn't for my AV updating itself at 4:02pm and a few other routine entries, i'd almost think the machine was turned off most of the day.

the windows\ccm\temp folder was created when the machine was last built using our standard win10 task sequence, which doesn't use a gold image - it actually installs win10 using the install.wim from the iso.  i don't create it as part of the job - sccm itself must have done it. 

so far my own machine is the only one in our environment where i've seen this happen, which in a way is good since i can troubleshoot at my leisure without inconveniencing a user.  i'm worried it may be happening on others and they just don't know yet because either they aren't observant (ie: stereotypical "USERS"), or it just hasn't filled up their drive yet - most of our desktop machines have 1TB drives so if this process (whatever it is) only spams 200gb to a drive, our desktop people will never notice.  but the laptops users certainly will, since they all have either 128gb or 256gb ssd's.  I only noticed it myself because i got a low disk space popup from windows itself, and the machine suddenly started acting REALLY sluggish.  I don't usually save anything locally - everything goes on the network.  

in case it might help, here's the directory listing of the ccm\temp folder: http://www.gibson99.com/downloads/ccm-temp-dir.txt

Wednesday, September 13, 2017 5:50 PM

@kiy wu - please un-mark my question as an answer.  it is not an answer and you marking it as such probably messes up search results.  thanks!

Thursday, September 14, 2017 12:54 AM

You are very kind!

Green Hand In Microsoft.

Thursday, September 14, 2017 11:50 AM | 2 votes

@kiy wu - please un-mark my question as an answer.  it is not an answer and you marking it as such probably messes up search results.  thanks!

Microsoft, we still need an answer here! C:\Windows\CCM\Temp taking up the entire SSD. It is NOT related to CCMCACHE. It is not deleted when you perform a CCM cache cleanup. How are we suppose to fix that?

Thursday, September 14, 2017 12:15 PM

Microsoft, we still need an answer here! C:\Windows\CCM\Temp taking up the entire SSD. It is NOT related to CCMCACHE. It is not deleted when you perform a CCM cache cleanup. How are we suppose to fix that?

Have you opened a support case with CSS? If not, it will never get fixed. There are not MS staffers here that can do anything about this.  

Garth Jones

Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

Thursday, September 14, 2017 12:54 PM

@kiy wu - please un-mark my question as an answer.  it is not an answer and you marking it as such probably messes up search results.  thanks!

Microsoft, we still need an answer here! C:\Windows\CCM\Temp taking up the entire SSD. It is NOT related to CCMCACHE. It is not deleted when you perform a CCM cache cleanup. How are we suppose to fix that?

I am having the same issue. Please help.

Thursday, September 14, 2017 12:58 PM

I am having the same issue. Please help.

Have you opened a support case with CSS on this issue? If not it will never get fixed.

Garth Jones

Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

Friday, September 15, 2017 6:47 AM

I am sorry, I haven't opened a support. And I haven't got a suitable schema. I marked your reply for answer just because I think I should be polite.

Also, if you get a good idea, please share me!

Green Hand In Microsoft.

Monday, October 2, 2017 12:01 PM

Same Issue here. Solution for me @ mom is a Script Runscript SCCM 1706 

Get-ChildItem -Path C:\windows\ccm\Temp -Include * | remove-Item -recurse -Force.

How could this datagrowing happen?

@Microsoft any better solutions???

Monday, October 2, 2017 12:22 PM

Same Issue here. Solution for me @ mom is a Script Runscript SCCM 1706 

Get-ChildItem -Path C:\windows\ccm\Temp -Include * | remove-Item -recurse -Force.

How could this datagrowing happen?

@Microsoft any better solutions???

Have you open a support Case with CSS, if not this issue will never get fixed. Again no one from MS monitors these forums and those that do can do nothing about it. 

It is not recommend to delete object from the cauhe folder as you have done. 

Garth Jones

Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx

Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased

Monday, October 9, 2017 1:10 AM

Thank you for your reply, and this method can delete the cash, but not solve this problem.

Green Hand In Microsoft.

Monday, October 9, 2017 1:12 AM

Just wait for better treatment.

Green Hand In Microsoft.

Monday, October 9, 2017 2:44 AM

OK. Thank you very much.

Green Hand In Microsoft.

Monday, October 9, 2017 3:32 PM | 1 vote

We have a very similar issue occurring with our Windows 10 computers.  In the CCM\Temp folder, the issue appears to be related with the ability of express updates downloading and installing.  We see a folder in CCM\Temp called express_a140fc0e-d7b0-4180-a42e-de6dd8a1f519.1, which translates to 2017-09 Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4038782).  In this folder, we see many GUID formatted files with a size of ~ 1.4 GB.  We may also see the psf files from the KB4038782 update each over 1 GB in size.

The datatransferservice.log and deltadownload.log show the contents of the update attempting to be downloaded either to the CCM\Temp folder or moving the contents from CCM\Temp to the ccmcache folder.  The ccmcache folder will have many .dlt delta folders.  In one example, the computer has the structure:

  • 9.1B52.dlt
  • 9.5C4B.dlt
  • 9.33A0.dlt
  • 9.40AA.dlt
  • 9.41DB.dlt
  • 9.304E.dlt
  • 9.334F.dlt
  • 9.5889.dlt
  • 9.C224.dlt
  • 9.E167.dlt

The ccmcache folder will also have a 9 folder, and the 9 folder contains the .psf files seen in the Content Information for KB4038782.

A snippet from the DataTransferService.log will show:

DTSJob {C2241FED-722C-4E04-9BFE-3D093EF4E201} in state 'PendingDownload'. DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
DTSFlag is 0x0348058e DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
ContentInfo root location - .BCWork\ContentInfo DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
Exclude file list:  DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
Using branch cache option DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
Using branch cache option DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
Failed to add file C:\WINDOWS\ccmcache\9.C224.dlt\windows10.0-kb4038782-x64_5.psf to range download. Add it to full download list. DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)
DTSJob {C2241FED-722C-4E04-9BFE-3D093EF4E201} in state 'DownloadingData'. DataTransferService 10/9/2017 4:19:05 PM 5640 (0x1608)

A snippet from the DeltaDownload.log will show:

In the Service Thread: url: http://localhost:8005/Content/eea7b988d2d7488b769fa3b0d3ae7e6763a5b423.psf DeltaDownload 10/9/2017 4:23:54 PM 12392 (0x3068)
Received a GET request for http://localhost:8005/Content/eea7b988d2d7488b769fa3b0d3ae7e6763a5b423.psf DeltaDownload 10/9/2017 4:23:54 PM 12392 (0x3068)
Request Initialized with URL: http://localhost:8005/Content/eea7b988d2d7488b769fa3b0d3ae7e6763a5b423.psf and AbsPath /Content/eea7b988d2d7488b769fa3b0d3ae7e6763a5b423.psf DeltaDownload 10/9/2017 4:23:54 PM 12392 (0x3068)
FileName = windows10.0-kb4038782-x64_5.psf, ContentID = express_a140fc0e-d7b0-4180-a42e-de6dd8a1f519.1 DeltaDownload 10/9/2017 4:23:54 PM 12392 (0x3068)
Request is from User Agent: Microsoft-Delivery-Optimization/10.0 DeltaDownload 10/9/2017 4:23:54 PM 12392 (0x3068)
Single range request for bytes 1146028032-1146093567 DeltaDownload 10/9/2017 4:23:54 PM 12392 (0x3068)

We are experimenting on a very limited basis the use of BranchCache, but this is in the very early stages.  I have confirmed that the computer in question is not part of the BrachCache experiment, and I have run the command

netsh branchcache show status all

to verify that branchcache service mode is disabled.

Also, running BitsAdmin on the computer will show there can be over 300 Bits Jobs in either a Suspended or Error state.

The issue for us appears to be related to the download of express updates on Windows 10, and we have verified the Windows 10 version is capable of handling the express updates.  The client setting is applied successfully, and the port is kept at the default of 8005.

We have a case open with Microsoft and we have submitted many logs and diagnostic packages for their review.  We as they are still struggling with understanding why this is occurring.  The strange thing is on some Windows 10 computers, the update is showing as being installed successfully.

Tuesday, October 10, 2017 1:28 AM

Hi messindj,

That's really an appreciating news.

And we will all wait for your treatment patiently.

Green Hand In Microsoft.

Thursday, October 12, 2017 9:34 PM

Messindj, you've gotten a lot farther with this issue than I have, but we are also seeing this issue on Windows 10 machines. I am still seeing the issue after disabling branch cache, but can't rule out that a few machines possibly have to failed process the disabling of branch cache.

I moved WSUS to a server 2016 box when I mistook the WSUS redlining issue for a busted WSUS role. When I set up the new WSUS 4 instance, I enabled the "Windows 10 Dynamic Update" product classification, which is about the time the helpdesk started reporting huge C:\Windows\CCM\Temp folders. Prior to the recent help desk reports, I wasn't aware of this folder and had never had a need to troubleshoot anything related to it.

Friday, October 13, 2017 2:08 AM

I'm afraid it is not the real reason for my issue, as I don't have enabled any "Dynamic Update".

I just enable “Definition Update” and “Security Update”.

Look forward to more replies.

Green Hand In Microsoft.

Friday, October 13, 2017 1:18 PM

Dynamic updates is not a classification so listing it with security and definition updates is invalid. Dynamic updates are listed with the products.

Jason | https://home.configmgrftw.com | @jasonsandys

Monday, October 16, 2017 1:18 AM

OK, I will try to remove the client and reinstall it.

Green Hand In Microsoft.

Friday, October 20, 2017 11:07 AM

Thank you very much!

Green Hand In Microsoft.

Tuesday, October 31, 2017 5:59 PM

I've seen a few machines where the BITS queue prevents download of the content to re-install the client.

From command prompt running as admin:

C:\Windows\ccmsetup>ccmsetup.exe /uninstall

(Monitor C:\Windows\ccmsetup\Logs\ccmsetup.log to see when the uninstall completes.)

C:\Windows\ccmsetup>bitsadmin.exe /reset /allusers

C:\Windows\ccmsetup>net stop "Background Intelligent Transfer Service" && net start "Background Intelligent Transfer Service"

C:\Windows\ccmsetup>ccmsetup.exe /mp:<Primary Site Server FQDN>

Monitor C:\Windows\ccmsetup\Logs\ccmsetup.log to see when the reinstall completes.

Monday, November 27, 2017 4:11 PM

Has anyone worked out how to resolve this without needing to re-install the CCM client?

I'm still polling how many of my clients are affected by this, but it's safe to say the thought of re-installing CCM client on anything more than a dozen machines is not appealing.

So far I'd turned off Express Updates (over a week ago) and today tested just doing October's Win 10 CU, to see whether November's update causes the ccm\temp folder to start filling... And sadly it does.

Hoping someone's just worked out that there's some client policy in WMI which is stuck / needs fixing, rather than a full re-install.

Monday, November 27, 2017 4:33 PM

The previous post I made failed to mention that the bitsadmin.exe /reset /allusers might have to be run as system. Try using "psexec /s \computername cmd" to connect to the problem client and see if the BITS queue keeps getting new download jobs for the update after it has been flushed. I also had to disable express installation files in the SUP properties.



Tuesday, November 28, 2017 9:06 AM

I think bitsadmin /reset /allusers is just resetting the current queue, right?

It's the same as doing a Get-BitsTransfer -AllUsers | Remove-BitsTransfer in PowerShell, and yes it must be run as System (a scheduled task easily achieves this).

Good shout about the Software update Point settings, I'll give that a shot next.

Tuesday, November 28, 2017 9:19 AM

sometimes /reset doesn't cut it - in which case you need the Nuclear option...

net stop bits
TIMEOUT /T /5
del c:\qmgr*.dat /s
net start bits

Phil

Phil Wilcock http://2pintsoftware.com @2pintsoftware

Tuesday, November 28, 2017 9:34 AM

Yes - if you have jobs stuck in Downloading or Failed states that aren't cleared after a queue reset, this is the only way.

I found just the files in %ProgramData%\Microsoft\Network\Downloader were enough to clear (rather than scouring the whole c: drive). Also, a machine policy reset is sometimes needed to kick CM back in to action...

Which has actually prompted me to try just the policy reset on the next broken client I find...

([wmiclass]'ROOT\ccm:SMS_Client').ResetPolicy(1)

([wmiclass]'ROOT\ccm:SMS_Client').TriggerSchedule('{00000000-0000-0000-0000-000000000040}')

([wmiclass]'ROOT\ccm:SMS_Client').TriggerSchedule('{00000000-0000-0000-0000-000000000021}')

Friday, February 2, 2018 7:34 PM

Phil,

Have you (or anyone else reading) done any personal testing with express updates in a 5.00.8577.1108 (ConfigMgr 1710 with KB4057517) environment? I was wondering if the change listed below was part of the general problem with express updates and the %windir%\ccm\temp folder or something more specific?

Download of express updates may fail on Windows 10 clients because of an issue that affects files in temporary and cache folders. In this situation, errors that resemble the following are logged in the DeltaDownload.log file: 

HttpSendResponseEntityBody failed with error 1006.

NO_ERROR == dwRetVal, HRESULT=800703ee

NO_ERROR == dwRetVal, HRESULT=800704cd

HttpSendResponseEntityBody failed with error 1229.