The following is a guest post from: Ted Skarbek
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. 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.
What I found was that it appeared the DP was giving an error that it couldn’t open the PCK file on the local server, which is somewhat to be expected since it isn’t there, but common sense would seem to indicate that if the file was not present that it would just get copied out automatically. At this point the package wouldn’t even remove from the targeted server since it was aware that it should be updating and that the PCK file was no longer present (apparently if the DP is trying to perform an action on a package, it won’t move onto the next one until the first one completes successfully). After a little investigation of the issue the best resources I was able to locate were the following:
http://technet.microsoft.com/en-us/library/bb892806.aspx
Under “What it does” for Package Updates:
“Builds a new, complete, compressed package file and a delta compressed package file from the updated package source files. The delta file is passed to all distribution points.”
http://www.myitforum.com/forums/m_82981/mpage_1/key_Clearing%252COld%252Cdata/tm.htm#82981
Under a post from “rlauder”:
“This is the compressed source of a package and is used for refresh purposes if a subordinate site server is instructed to refresh it' s own copy. If you' re lucky and you' ve trashed it, the parent server may well just request a new copy from its own parent, but don' t bank on it.”
So it seems that the expectation that the PCK files would automatically replicate out was apparently unreasonable. I have been able to determine two solutions to enable us to update the DPs when the PCK files have been removed:
1. In order to update a package on a DP which was last updated before our modification above here’s what seems to work:
a. Remove all targeted DP’s
b. Wait for the package status to be all 0’s on ALL DP’s (Source Version “0”, Targeted “0”, Installed “0”, Retrying “0”)
c. Update the Package from Source
d. Re-add the DPs
e. I’ve never seen this have a problem.
2. If the package is updated without removing the DP’s what you will likely see is that the Source Version stays the same, Targeted stays at “1”, Installed goes to “0”, and Retrying probably goes to “1” (as seen in the Package Status area). Once this starts happening even removing the DP won’t work (Targeted, Installed, and Retrying will all “0”, but Source Version will still stay the same).
a. To resolve the problem now the PCK files need to be manually copied from the parent server (\\<serverName>\sms_cpsg$\<PKG ID>.pck) to the target server (using the same sms_cpsg$ share).
b. Once the PCK file is back on the server(s) the package can be updated again and everything should be fine.
c. Note: only the PCK file needs to be copied, all files with the *.DLT and *.DLT.x extension can be ignored.
d. Sometimes I do have a problem manually copying the PCK files as it tells me I don’t have permission to write to the file on the target location (even though I have create and modify access to the target location and the file isn’t present) but in these cases the server Admin’s has been able to successfully copy the files.