I recently ran into an issue while replacing the hardware some secondary sites. During our build process the .pck files are copied to the new hardware prior to shipping the server to its permanent location. Once the server is on-site SCCM is installed and the preloadpkgonsite.exe tool is used to preload the .pck files into the database in bulk using the process described by Marcus Oh in his blog. After doing this some of my packages wouldn’t decompress to the new sites. I tried removing the packages from the DP, then resending them but that didn’t help. I could see in distmgr.log “A newer version (15) of package xxx000B6 has already arrived, delete the replication file D:\SCCM\inboxes\distmgr.box\INCOMING\NK81JJDQ.PKG for version 12 .” This was rather puzzling for a couple of reasons, first of all the current version of my package is 16, not 15 nor 12. Secondly not only does the console show that there’s no version of the package installed at this site but just to make sure I ran a delete statement to delete the pkgstatus directly from the database. It seems really strange that this package is not in the database for this site yet when it gets copied down the site thinks the package is already there and deletes the replication files.
Once I was at my wits end I called CSS, got a very knowledgeable guy by the name of Cliff and we worked through the issue quickly. Hopefully by posting the resolution here someone else can also benefit from his expertise without having to place a call to CSS.
With the old preloadpkgonsite.exe tool (or the new one in SCCM Toolkit v2 if you do not specify the /UpdateStoredPkgVersion switch) the stored package version is automatically set to the source package version. These two versions are not always the same and in cases where they differ you will have the problem I am describing here. If you want to see which packages will experience this issue prior to using the preloadpkgonsite.exe tool run this query in SQL Management Studio. You can then prevent the issue by simply specifying the correct values when you run the preloadpkgonsite.exe tool.
Select All
Name,
PkgID,
SourceVersion,
StoredPkgVersion
from
SMSPackages
where
StoredPkgVersion <> SourceVersion
Greg Ramsey came up with a nifty little PowerShell script that will check the database for each storedpkgversion and write out a bat file to run preloadpkgonsite.exe with the correct parameters for each package. Here's a copy of that script. Besure to replace MYSMSPROVIDER with the name of your provider machine and XXX with your site code. Be sure to use the new version of preloadpkgonsite.exe from the SCCM v2 toolkit.
$pkgs = get-wmiobject sms_package -computer MYSMSPROVIDER -namespace root\sms\site_XXX
$pkgs | foreach {
if (test-path @("D:\smspkg\" + $_.PackageID + ".pck"))
{
$output += @("PreloadPkgOnSite.exe " + $_.PackageID + " /UpdateStoredPkgVersion " + $_.StoredPkgVersion)
}
}
$output | out-file -filepath "D:\SCCM Install\preloadpck.bat" -encoding ascii
If it’s too late for you to add the the /UpdateStoredPkgVersion switch because you’ve already run the preloadpkgonsite.exe tool without the switch like I did and you need to fix this issue keep reading the fix is coming up next
Start by removing from the child site server any files that contain the package ID that’s not working. This includes the compressed files from SMSPKG, the uncompressed files from SMSPKGx$ and the .ICO, .PKG and .NAL files from inboxes\pkginfo.box and lastly the .PKG file from inboxes\distmgr.box
Next run the following in SQL Management studio on the central site server as well as, if applicable, the broken sites direct parent primary site. Be sure to replace the below entries in < > with the appropriate Package ID and Server Name
Select * from PkgStatus where ID = '<PackageID>' and PkgServer = '<ServerName>'
This first entry should return the package for the server and its status and sourceversion.
Status of 0 and SourceVersion of X where X is your current package version, would be a normal working package.
Anything other than status 0 or 2 indicates the package is in process, and may need to be manually updated with the Update PkgStaus query below:
It is also possible, that the status could be correct, and that the version is correct, but that the target server will not extract the latest version due to some failure in the past.
Here are the possible status codes and their meaning:
PKG_STATUS_NONE 0
PKG_STATUS_SENT 1
PKG_STATUS_RECEIVED 2
PKG_STATUS_INSTALLED 3
PKG_STATUS_RETRY 4
PKG_STATUS_FAILED 5
PKG_STATUS_REMOVED 6
PKG_STATUS_PENDING_REMOVE 7 // Not used.
PKG_STATUS_REMOVE_FAILED 8
PKG_STATUS_RETRY_REMOVE 9
Please note the disclaimer… Directly editing the SCCM database as we are about to do is totally unsupported and shouldn't be done unless you really know what you are doing and you have a current backup of the SCCM database.
Now that you read my disclaimer above, (You did read it did you?) you need to set the SourceVersion to 0 and the status set to 2 which will force a new copy down to the Site/DP, if more than one DP is at the Site in question, then you will have to use the PkgServer instead of SiteCode.
So run this in SQL Management Studio.
Update PkgStatus
Set Status = '2', SourceVersion = '0'
Where ID = '<PackageID>' and PkgServer = '<ServerName>'
Once you update the package with status of 2 and source version of 0, then run the Manage Distribution Points Wizard in the ConfigMgr Console, and choose to refresh the package on the affected server. This should allow the package to be updated correctly.