ConfigMgr SCCM Do not delete PCK files under SMSPKG folder

ConfigMgr SCCM Do not delete PCK files under SMSPKG folder. I was looking for documentation that states the disadvantages of deleting ‘.PCK’ files to free up some space in SCCM servers. Shaun Cassells had already done good documentation on the same topic.

Read the full post “Savings Space on SMS / SCCM servers by deleting PCK files – the pitfalls and fixes.”

Latest Post Fix Report Server Cannot Open A Connection Error ConfigMgr | SCCM HTMD Blog (

Update :- In my personal experience, We can safely delete the PCK files from SCCM ConfigMgr servers in emergency situations. I had seen disk space issues in SCCM servers where SCCM Inbox folders are located. As emergency we can safely delete the PCK files !!!

ConfigMgr SCCM Do not delete PCK files under SMSPKG folder

The following is a write up on package replication after the user deleted PCK files:

Patch My PC

With our aging SMS 2003 servers running out of drive space for the distribution points and new packages being created much faster (and typically larger on average) than the older packages were being retired, we were scraping for bits of space to keep moving until the new SCCM 2007 system gets into production. ConfigMgr SCCM Do not delete PCK files under SMSPKG folder.

It was found that the servers being used as the DPs had a significant portion (roughly 40%) of the total drive space assigned to the DP being taken up by PCK files. To free up the capacity, we elected to delete PCK files that hadn’t been modified in the last 3-6 months, figuring that anything that hadn’t been changed in that time probably wouldn’t need to be modified. If it did, then the PCK file should replicate back out to the DP, so it might just take a little longer.

Shortly after deciding to delete the older PCK files, we encountered a few older packages that needed to have slight modifications to them replicated out to the DPs. Sometime after issuing an “Update Distribution Points” command from the SMS console, it was noticed that on at least a few of the DPs, the package had not yet been updated (under package status, these sites still indicated the previous source version, targeted “1”, but installed was “0”, and retrying was “1”).

This was observed in the past and would typically be resolved by updating the DPs again. In this case, it did not resolve the issue, so I began digging into it further.



Leave a Comment

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