Hi, The despoolr.box/receive folder has 50GB worth of pck files on it, which has used up all the space on the disk so that it now has 0 bytes left. There are no errors as such on the despoolr.log file, logging stopped 3 days ago when it ran out of space (which means it stopped logging before any errors came up). Question now is... seeing as the server can't really do anything as it has no space at all, what's the correct procedure for fixing this? cogu

Well, being slightly sarcastic here :) you know I'm going to say the correct procedure is to get more drive space. Lots more drive space. What I think you are really asking is "what can I do in the next few hours to help it limp along until I can get more real drive space". About the only thing you can do is look for things to delete; like temp files, or perhaps you have IIS log files on the same drive; sometimes those can get huge if you aren't watching. Is the same drive the one that has the smspkg folder? This isn't really recommended, but IF that drive has the smspkg folder, you could, as a temporary thing (think days, NOT weeks or months) selectively delete a few of the files in that folder to free up some space. Those are only temporary solutions--just to limp along for a few more days. The only real solution is more drive space, and lots of it.Standardize. Simplify. Automate.

Already deleted every single log file I could find, including backing up the SCCM files to another drive. That got me about 300mb of space which was eaten up in under 5m. smspkg is not on the same drive. Can I move the Program Files (x86)\Microsoft Configuration Manager\WAIK folder to another drive for the time being? That's got over 1GB in there...

There's another partition in the same disk that has enough free disk space. However, shrinking a partition and then extending another one transforms the disk to a dynamic disk. Is there any issue with having SCCM installed on a dynamic disk? Any reason why this shouldn't be done?

There are no issues with CM07 on dynamic disks.http://www.enhansoft.com/

Thank you Garth. I'm still having some problems because of this though. The despoolr.box appears to have cleared 1 of the 30GB+ files about 12h ago and moved it to the schedule.box\tosend to send it to the secondary sites. The secondary site finished downloading this file about 5h ago, but the file still exists on both the despoolr.box on the primary server and the schedule.box\tosend on the secondary server. The information on the schedule.log or schedule.lo_ on the primary server has already been replaced so there's no log of this transaction. As for the despoolr.log on the secondary server, the last entry on the log was on Friday 2/March/2012, so it seems like it's not even attempting to process the file. The SMS_DESPOOLER component is started on the secondary server and it's obviously downloading the files properly, just not processing them afterwards. Also, there was a second 30GB file on the primary server that never finished downloading. Even though it now has 40GB free space, the size of that 30GB file has not increased by a byte in the last 15hours. Again there's no information on the logs about that particular file at all. What steps can I take to get rid of it/force it to finish downloading? Lastly, my understanding is that the despoolr.box holds the compressed source of packages. However, we don't have any packages with 30GB+, let alone 3, which is what it seemed to have started to download. So, where did this come from? Also, the two .pck files that fully completed downloading had exactly the same size but different unique IDs. The remaining file that hasn't increased in size in over 15h is currently sitting at 27GB, but I imagine it's full size would be the same as the other two. Any help would be appreciated. cogu

Here's a detailed doc about site to site communications: http://blogs.technet.com/b/configurationmgr/archive/2010/07/15/new-deep-dive-document-component-details-and-data-flow-for-site-to-site-replication-in-sms-2003-and-configuration-manager-2007.aspxTorsten Meringer | http://www.mssccmfaq.de

Thanks Torsten, but honestly that doesn't answer any of my immediate questions. I'm still stuck with a 27GB .pck file that is no longer being downloaded on the despoolr.box box on the receiver whilst the schedule.box box on the sender is empty. A restart of the secondary site seems to have kicked the SMS_DESPOOLER component back to life, so I'm not too concerned about that one anymore, just the 27GB file that's stuck on the primary. Also, I'm still trying to figure out where these files came from as well.

Managed to track the 30GB file down to a package ID that no longer exists on the server. The SMS_DESPOOLER components has two error messages both saying the same : SMS Despooler failed to decompress package "XXXXXXX" from "D:\SMSPKG\XXXXXXX.PCK". The operating system reported error 13: The data is invalid. Possible cause: The compressed image "D:\SMSPKG\XXXXXXX.PCK" is either missing or corrupt. Solution: SMS Distribution Manager will attempt to recover the package by requesting a new compressed package image from the site that sent it. That could explain why it's trying to download the same file several times, but does not explain why the one containing invalid data was not deleted automatically and is still sitting on the despoolr.box. And does not tell me whether I can delete it or not Also, the file that was previously on the despoolr.box of the receiver secondary site is now gone, however that same file hasn't been deleted from the schedule.box on the sender primary site. Taking into account the file has been processed by the receiver and that the package doesn't seem to exist anymore, is it safe to delete it? cogu

CM07 will not clean up when something goes wrong. That is why looking at the Inboxes is one of the maintenance tasks you should preform on a regular bases.http://www.enhansoft.com/

Garth, My understanding is that it's only safe to delete files that are more than 6 months old. Is this correct? If so, taking into account these files are 4 days old, I need to wait 6 months before they can be deleted, which means I'll struggle with space until then. Is there any way to confirm if it is safe to delete these files now (short of deleting them and keeping the fingers crossed of course)? cogu

Sure you review the log files, see if they are still being updated. Based on how you have your senders setup, it should be fairly quick to see if they are still being updated or not. But the really solution is to get a lot more disk space. Maybe even look at mount points for some of the directories. http://www.enhansoft.com/

Well, we've given it a lot more disk space so it's happy for the time being. Going through the logs I can see several messages saying the download of the file sitting in the despoolr.box folder is at 81%. A few hours later it still says it's at 81% (and I can confirm that the number of bytes hasn't risen in over 3 days at the very least). This message repeats itself several times for well over 12 hours and then any information to do with that file just stops abruptly, which leads me to believe SCCM is no longer looking at that file at all. Which log should I be looking at exactly to find out if the server is still updating it? The one on the schedule.box is now gone, so we've gained another 30GB+ of space. Only the one in the despoolr.box folder doing my head in now, occupying 27GB and not doing anything for the past 3 days!