Distributing packages to troublesome DP’s

I’m sure i’m not the only one who has had issues with trying to push out lots of packages to DP’s! Especially where the link to it is very small.

PCK files are copied to the SMSPKG folder but not uncompressed or not received at all. Trying to run the preloadpkgonsite.exe tool can be confusing. Distmgr.log has messages that don’t really make that much sense.

Before you look at the below, here is some good reading – http://blogs.technet.com/configurationmgr/archive/2009/05/07/configmgr-2007-the-preload-package-tool-preloadpkgonsite-exe-explained.aspx – it explains the preloadpkgonsite.exe tool very well, although i did try the instructions at the top but unfortunately it didn’t distribute the packages.

Anyway after quite a while of troubleshooting, here is how I like to do it.

Deploying all packages to DP’s on small links
Just built a secondary site and need to deploy all your packages? Yep, i’ve been there! Normally i would simply use the Copy Packages wizard and put my feet up but its not always that easy. If i know there are going to be problems getting the packages to sites, say where the link is very small or you’ve been told to limit the rate to a ridiculous %, then i’ll use this method:

1. Copy all the PCK files from a DP thats already had the packages ditributed to it (maybe use a child primary or an already built secondary) to your SMSPKG folder on the new secondary (if the folder hasn’t yet been created, you can manually create it on the partition you want). If you don’t want to do it over the wire then simply copy them to an external source and post across.

2. Once the PCK files have been copied to the new DP, you then need to run the preloadpkgonsite.exe tool (this can be downloaded from the web) on them all. To do this easily, I normally browse to the SMSPKG folder in a command window and run:
DIR /B > C:\packages.txt
This will give me a list of all the pck files in that folder. Using a few replace commands allows me to append “preloadpkgonsite.exe ” to each one and remove the .pck extension. You need to ensure you have the following structure:
preloadpkgonsite.exe XXX00001
preloadpkgonsite.exe XXX00002
etc

3. Once you have the list, open a command prompt (as admin if using WS2008) and browse to the folder location where preloadpkgonsite.exe is saved. When there simply copy and paste the list into the cmd prompt and it should start processing each package. You want to see a similar message to the following after its processed each package:
D:\ConfigMgr\bin\i3860000409>PreloadPkgOnSite.exe XXX00001
****** Preload Package On Site ******
Forward package status for pkg XXX00001 to site XXX
****** Successfully set the Compressed Package Path on this site ******
****** Successfully forwarded the information up the hierarchy ******

4. Once all the packages have been processed (hopefully with the majority being successful) you need to play with the SCCM DB (***DISCLAIMER***: Do not touch the DB unless you have a full backup and are happy with what you are doing). I’m presuming the DP you are trying to add these packages to is a secondary site. If so on the direct parent primary site, open up SQL Server Management Studio and create a new query for your site DB. The first thing we want to do is confirm that the preloadpkgonsite.exe has populated information in the SCCM database for each of the packages. To do this run the following:
Select * from PkgStatus where SiteCode = ‘XXX’ where XXX is your new secondary site’s code.

This should give you a table back with ID, Type, Sitecode, Pkgserver, Personality, Status, SourceVersion etc etc. Once you’re happy that all the packages have been entered here, you can go to the next step.

5. You must now change the source version for each of your packages in that table (see the link above for what source version is and does) but to do this we must first disable a trigger in the PkgStatus table that stops us updating more than one row at a time. Go to the PkgStatus table in SQL Server Management Studio, go to Triggers > right click over “PkgStatus_ins_upd” > disable.

Once disabled you can now run the command to change the source version to 0:
UPDATE PkgStatus Set SourceVersion = 0 where SiteCode = ‘MOS’ and SourceVersion != 0 where XXX is your new secondary site code.

When completed, go to the PkgStatus table in SQL Server Management Studio, go to Triggers > right click over “PkgStatus_ins_upd” > enable.

6. Now that all the packages have a source version of 0, we can now deploy the packages to the secondary site DP. To do this I normally use the “Copy Packages Wizard” and I simply selecting the same DP as I copied the PCK files from, as the source. This way I know it’s only going to add packages that I have PCK files for. Do the same for any software updates you have (again you can use the copy packages wizard available by right clicking the Deployment Packages folder)

7. The packages should now start decompressing on the secondary site (give it 5 mins or so) and its a case of waiting now (although i’m sure you’re used to that if you’ve used SCCM before!). In my experience a good 95% of the packages (sometimes more) will uncompress fine, just keep an eye on the Active Packages report. If after a while you notice no more packages are uncompressing but you still have packages in your report (check the distmgr.log on the secondary site for entries saying “Used 0 out of 3 allowed processing threads.”. This usually means it won’t be processing any more packages) then I find simply refreshing the secondary site, from its parent primary, of those particular packages does the trick.

Hope the above helps!

Cheers
Nik