First published on CloudBlogs on Aug, 21 2013
This blog post describes a problem that prevents pull-distribution points, which were introduced with System Center 2012 Configuration Manager SP1, from acquiring packages that were migrated from another Configuration Manager site.
Scenario
After a package is migrated from one site to another (e.g., from a System Center Configuration Manager 2007 site to System Center 2012 Configuration Manager site*), the package may not successfully distribute to pull-distribution points, even though it can be distributed to regular distribution points. This applies to legacy-style packages that have been updated on the source site with
Update Distribution Points
before they were migrated.
There is a known issue in the migration wherein one of the properties is not updated, and the pull-distribution point uses this property. Specifically, on the destination site server the SQL Server view SMSPackages is updated, while the tables CI_ContentPackages and CI_Contents are not correctly updated with the MinPackageVersion that matches the SourceVersion in SMSPackages. This leaves the data about the package in an inconsistent state.
*This issue can occur when you migrate a package from any supported version of Configuration Manager, including from another System Center 2012 Configuration Manager site.
Discoverability (Simple)
Distribution of the affected packages to pull-distribution points will fail. Look in the pull-distribution point log—often located at C:WindowsCCMLogsPullDP.log. Check for the following lines:
CPullDPPkgJob::LoadJobFromXML() could not load any content jobs from XML!
CPullDPPkgJob::LoadJobFromXML() could not fully load job! Malformed or incomplete XML. Job has failed.
These are the best indicator that the distribution failure is due to package migration. If you find these entries in your log, you may be able to fix the problem using the steps below.
Discoverability (Advanced)
The site server database can be examined to find packages that are affected. The following query will show the package ID and name of affected packages:
SELECT p.PkgID, p.Name
FROM SMSPackages p
-- Ensure this is a legacy-style package
WHERE p.PackageType <> 3 AND p.PackageType <> 5 AND p.PackageType <> 8
-- Ensure no consistent row exists
AND NOT EXISTS
(SELECT 1 FROM CI_ContentPackages cp WHERE cp.PkgID = p.PkgID
AND cp.MinPackageVersion = p.SourceVersion)
-- Ensure this is a migrated package
AND EXISTS
(SELECT 1 FROM Library_ImportedObjects i WHERE i.ObjectKey = p.PkgID)
The Problem
For content distribution to regular distribution points, these tables do not matter. However, when notifying pull-distribution points to pull down the content, we need to know some information in those tables. As such, it is necessary to update the entry inserted into CI_ContentPackages with a corrected MinPackageVersion and Content_UniqueID, as well as update CI_Contents to match that corrected Content_UniqueID.
Solving the Problem
To solve this problem, you must update the package in the destination site. This will automatically update the properties and bring the data in the tables to a consistent state.
To do this, open the Configuration Manager console, navigate to
Software Library
and locate the package. Then, right click and select
Update Distribution Points
.
Note: this operation can be slow if the package has already been distributed to many distribution points.
--
Brandon Waterloo
This posting is provided "AS IS" with no warranties and confers no rights.
