SCCM inboxes despoolr

Ever since we installed SCCM 2007, SCCM 2012 and recently SCCM 2012 R2, we’ve been fighting disk space issues on all our SCCM servers. This recently started to become a very big problem because we kept running out of disk space any time we distributed a large package. After digging into the problem a bit further I found that there was one folder on the SCCM server that was taking up HALF of the disk space. That’s right, HALF! In this particular case, the following folder was taking over 55 GB if disk space; C:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\receive\. Many of the files had old dates. Some as old as 1 – 2 years!

At first, I had no idea what this folder was but it contained a ton of very large files with the .TRY and .PCK extensions. Many of these files were HUGE! We have a couple of really large packages and one OSD image (operating system deployment). It looked like there were duplicate .TRY files, all of them around 6 GB each. After doing some research, I found out what this folder is used for. The following is best explanation I found for what this folder is used for.

This folder temporarily stores data that is received from a child Configuration Manager site or parent Configuration Manager site. Files (.pkg and .rpl) are processed and moved as soon as the instruction file is received

The key thing in that explanation is temporarily stores data. To me, that means it is fair game to clean it up and delete the old files. After further research, I found postings explaining how this directory does not clean up after itself very well. Apparently when there are distribution issues with your SCCM parent site and the associated SCCM child sites, it leaves these temporary files in the despooler\receive folder. I found conflicting articles stating that it was safe to delete these files but also found posts stating to call Microsoft BEFORE deleting any of these files. I’m not normally a risk taker but in this case, we thought it would be safe to do the following to resolve our disk space issue on SCCM servers.

  1. Temporarily move the files in the despoiler.box\receive folder to a newly created folder called despooler_backup
  2. Reboot the SCCM server
  3. Make sure all SCCM services start up properly
  4. Wait until SCCM replication takes place over night or later on in the day
  5. Check for any errors in the SCCM console
  6. Finally, delete the temporary folder despoiler_backup

Once you are comfortable that the deletion of these files won’t cause an issue with your SCCM environment, you can just delete the old files directly from the C:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\receive folder. The best way to handle this is to create and schedule a simple script to delete all files older than 30 days in the despoiler\receive folder. This way it will keep your SCCM server disk space in check and you can focus your energy on more important matters. Good luck!

References
http://mpwiki.viacode.com/default.aspx?g=posts&t=143550

http://eskonr.com/2012/12/sccm-configmgr-clean-up-backlogs-in-desplooer-boxreceive-folder/

http://social.technet.microsoft.com/

George Almeida

Welcome to my little corner of the blogosphere. I'm an Information Technology Director. I specialize in Windows operating systems, applications, servers, storage, networks and also have a technical background on the IBM iSeries platform. My only purpose for this blog is the hope that it helps someone, someday, somewhere. Any meager proceeds derived from our sponsors will be donated to charity.

You may also like...

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

6 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Stefan Somogyi
Stefan Somogyi
8 years ago

Many thanks for this analyse and explanation. It helps alot to me.

mahesh
mahesh
8 years ago

Nice explanation,George. Thank you.

Samuel Valaparla
Samuel Valaparla
7 years ago

Good information indeed. I ran into this problem recently and did something similar to what was mentioned here. But its good to see the “WHY” explained so well. Thank You.

6
0
Would love your thoughts, please comment.x
()
x