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.”
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:
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.
Anoop is Microsoft MVP! He is a Solution Architect in enterprise client management with more than 20 years of experience (calculation done in 2021) in IT. He is a blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. E writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc…