SMS Package deployment to Distribution Points-compressed files haven't arrived yet

Found this article on internet for troubleshooting package-DP problems:
http://blogcastrepository.com/blogs/mattbro/pages/687.aspx

First off, the obvious things to check or try for a misbehaving package:

1. Go to System Status->Package Status and browse to the Package/DP having issues. Right-click on the DP and choose “Show Messages“-> “All“. This should show you some useful information on what might be going on.
2. Confirm that the Source Directory for the Package actually exists.
3. Try re-pushing the Package to the DP.
4. Make sure the permissions on your DP are good. I found one DP where the Administrators group had their permissions applied only to the root of the Dist share. This caused problems with any packages that were configured to store themselves in a nested subfolder. SMS was able to create the first level folder but was not able to create the subfolders under that folder.

(Let me preface the next part by saying that almost all of our remote DPs are also CAPs and MPs - I'm not exactly sure what components will be on a separate server if you have these functions split up. The same methods should work though)
Ok, now on to the fun stuff. After doing the things above, I was left with about 50 instances of packages that didn't want to deploy properly.
After doing a bit of digging, I found the following errors in DISTMGR.LOG on the remote DPs for every package that wouldn't deploy:

Processing incoming file E:\SMS\inboxes\distmgr.box\INCOMING\Z3AWAX9I.PKG.
Package 009000B7 requires a newer version (3) of source files and the new compressed files haven't arrived yet, current version is 2, skip E:\SMS\inboxes\distmgr.box\INCOMING\Z3AWAX9I.PKG

My friend Brian Tucker told me about a method he has used in the past to fix these issues. I tried it and it had a good success rate of fixing the issue. The only thing I didn't like about it is the fact that it forces the package to re-deploy too ALL DPs. Sometimes you have a really big package that you don't want to saturate your entire WAN with. Also, I wanted to understand why changing the sourcepath forced the package to redeploy.
This leads us to PCK files. PCK files are the compressed copies of each package that SMS sends to each DP. Once the PCK gets copied to the DP it gets extracted onto the Dist share. At least, that is what is supposed to happen. For the majority of the packages that were misbehaving, this wasn't occurring. I was able to fix the majority of them by using the following process:

• Manually copy the PCK from \\primaryserver\smsdrive\SMSPKG to \\DPServer\smsdrive\SMSPKG
• Make sure the Read-Only attribute is set on the PCK file. I also removed the Archive attribute so it would be like all of the other PCK files.
• Run PreloadPkgOnSite.exe to force the package to decompress and register itself propery at the DP.

(PreloadPkgOnSite.exe comes with the SMS 2003 Toolkit 2. All you have to do is give it the Package ID as a command-line parameter)

• Re-push the package to the DP. You can use the SMS Console for this. This will not copy the compressed content to the server again since we just manually did this. This will just give SMS a little kick to help things along.

During my testing with PCKs I was able to determine why Brian's fix (linked up above) works most of the time. Whenever you change the sourcepath on a package, it regenerates the PCK on the Primary. The new PCK is then deployed to all of the SMS servers. It seems to go ahead and push itself on through on the DPs that were having problems fairly well after this. I have a feeling this is because the package has a new source version so the problematic DPs start the entire deployment process over again. Also, I found that I didn't have to permanently change the sourcepath on the package. All I had to do was just add a number to the end of it and then go right back into the sourcepath and change it right back to what it originally was set to. This way you don't have to actually rename the folder on the file server.
While testing this process I did run into a few cases where updating the source path did not generate a new PCK. If you are ok with redeploying to all DPs, I found that you could go ahead and delete/rename the PCK on the Primary (located at \\primaryserver\smsdrive\SMSPKG ) and then update the sourcepath and detailed above. This will definitely force it to regenerate the PCK on the Primary.
Now for the remaining packages... I had a few that were giving me the following error when I tried to run PreloadPkgOnSite.exe on them:

The compressed package path for package 0090002C is already set in the database
OR this is the site where the package was created.
 There is no need to use this tool for this package on this site.

Apparently these packages got just a little bit further into the deployment process before they bombed out. I was able to get around this problem by deleting \INBOXES\DISTMGR.BOX\packageid.PKG on the DP. Then I was able to run PreloadPkgOnSite.exe on that DP for that package without any problems.

You might have to re-push the package to the DP before running PreloadPkgOnSite.exe. If you get the following error, just re-push and wait a few minutes:

Failed to get the specified package 0090002C in the database. Please check if you have instance rights to that package.

You should see the following when it works properly:

Forward package status for pkg 0090002C to site 009
****** Successfully set the Compressed Package Path on this site ******
****** Successfully forwarded the information up the hierarchy ******

Note: At any time, feel free to go into the SMS Console and re-push the package to the DP. It really seemed to help kick things through once I did some of the other steps to fix the underlying issue. I always did a re-push after running PreloadPkgOnSite.exe.

That's pretty much it. These steps might not work for every situation but I have a feeling that most people running into this problem can fix the majority of their issues with these steps.

Other misc. info I found while doing my testing:

• Each package also gets the following files generated when it gets deployed:
  • \SMS\inboxes\pkginfo.box\packageid.NAL
  • \SMS\inboxes\pkginfo.box\packageid.PKG
  • \SMS\inboxes\pkginfo.box\packageid.ICO (this is a folder)
  • \SMS\inboxes\colleval.box\packageid.CLF
  • \CAP_XXX\pkginfo.box\packageid.NAL
  • \CAP_XXX\pkginfo.box\packageid.PKG
  • \CAP_XXX\pkginfo.box\packageid.ICO (this is a folder)

I messed around with deleting these files to help things along but it didn't seem to make a difference.

• Removing the package from a DP (via the SMS Console) and then re-adding it never seemed to help things much.