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.
To read the full post “Savings Space on SMS / SCCM servers by deleting PCK files – the pitfalls and fixes”.
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 user deleted PCK files:
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 which hadn’t been modified in the last 3-6 months figuring that anything that hadn’t been modified in that time probably wouldn’t need to be modified, and if it did then the PCK file should just replicate back out to the DP so it might just take a little longer.
Somewhat shortly after making the decision to delete the older PCK files we encountered a few older packages which 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 updated (under package status these sites still indicated the previous source version, targeted “1”, but installed was “0”, and retrying was “1”).
This had been an observed behavior in the past and typically would be resolved by just updating the DPs again. In this case it did not resolve the issue so I began digging into it further.
More details on above link……