There can be many reasons for package replication in a large hierarchy to fail, the compressed package files may not exists anymore on the child site, antivirus may have blocked files in the scheduler on a parent or because of problems fixed with few hotfixes in SP2.
The symptom can be that the latest version of the package does not reach your DP's or the package just does not appear or reappear and the package status shows install pending.
Figuring out if you actually have a problem is not so easy because large package assigned to a DP on the other site of the planet may have to go through number of sites and very slow links, so it may be normal to wait for more than a day.
How to identify the problem:
- By running this query on the site where the package was created:
SELECT PkgStatus.* FROM PkgStatus WHERE (Type = 1) AND (ID = '<PackageID>') AND (SiteCode = '<SiteCode>')
When Status<>0 and SourceVersion>0 you may have a problem but only if persistent over long period of time, this can be a normal state where the size of the package and available bandwidth causes the delay,
- The distmgr.log on the child site managing the DP contains entries like this, this is a normal state until the PCK files arrive, but will continue forever if there is a problem and the PCK files are never send:
Package <PackageID> requires a newer version (3) of source files and the new compressed files haven't arrived yet, current version is 2.
- The despool.log on the child site managing the DP contains entries like this showing that a delta has been created with version 3 but version 2 cannot be found, the PCK files may have been deleted:
Received package <PackageID> version 3
CCompress::Open: Failed to open X:\SMSPKG\<PackageID> (2)
Solutions:
There are few possible methods of repairing this covered in this article which can be defined as a supported methods: http://www.blogcastrepository.com/blogs/mattbro/articles/687.aspx
These methods may not always work and do also require you to either copy large PCK files over those slow links without any bandwidth control or by burning them onto a DVD to be sent.
The unsupported method which has always worked for me is to reset the delta replication values by changing entries in the database, the compressed PCK file will then be replicated using the SMS bandwidth control you have already put in place and should then not saturate your WAN links.
WARNING, modifying tables in the SMS database is not supported and should be tested in your testlab.
Replace <PackageID> with the package ID of the package with the problem and <SMSChildSite> with the name of the Site server managing the DP's, not the DP's them self:
UPDATE PkgStatus SET Status = 2, SourceVersion = 0 WHERE (ID = '<PackageID>') AND (Type = 1) AND (PkgServer = '<SMSChildSite>')
When this has been done you must trigger that the PCK files are replicated by refreshing the DP’s of the package in the SMS Admin console.
Posted
Oct 01 2007, 09:03 PM
by
Larus Milan Bulat