Month: October 2015

ConfigMgr 2007 to 2012 R2 – Hung Conversions

Posted on Updated on

Recently when helping a customer migrate to ConfigMgr 2012 R2 SP1 + CU1, the site had major problems with fully completing DP upgrades.  First, it would start the uninstall of a CM07 secondary site, then do nothing.  So we would restart the process to which it reassigns the DP and then stalls again…but even worse, it never completed the process and it couldn’t be restarted again.  So the status never came to a full completion and the old content (SMSPKG, PCK files, etc.) were not removed.  Additionally, the state of the migration status never went beyond “Reassigning distribution point” as in the image below.

cm12conversion1

Ultimately I had to engage Microsoft to get an answer.  Even they had to dig through the SQL stored procedure (sp_MIG_ UpgradeDistributionPoint) to understand for themselves what the conversion process does.  Essentially the stages boil down to these high-level steps:

  1. Uninstall of the 2007 components, then delete the values in MIG_DistributionPointSource in the database
  2. Drop a .dpu file into the distmgr.box  (for more info, see TechNet article “DP converts, but content fails“)
  3. Convert DP values of various package and DP mapping values in SQL
  4. And finally, set the DPUPgrade status where Action=2 and Status=0 for complete.  The example below shows an incomplete “hung” state of a DP with Action=2 and Status=1.

cm12conversion2

To get these statuses, the following SQL query was used so that we would know when the remote server had completed the uninstall of the secondary site and was ready to have a manual .dpu file dropped in distmgr.box to initiate the content conversion.

-- Result must be empty
select * from MIG_DistributionPointSource where PKGServer like '%ServerName%'

-- Result must have content listed
select * from PkgServers_G where NALPath like '%ServerName%'
select * from PkgServers_L where NALPath like '%ServerName%' 
select * from PkgStatus where PkgServer like '%ServerName%'
select * from ContentDPMap where ServerName like '%ServerName%'
select * from DistributionStatus where DPNALPath like '%ServerName%'

-- Result must have Action=2 and Status=1 to know server is ready to convert content
select * from DPUpgradeStatus where NALPath like '%ServerName%'

-- Use the DDPID number to create the .dpu file name
select * from DistributionPoints where ServerName like '%ServerName%'

The secondary site conversion woes occurred in primarily three ways:

  • First problem – a rerun the stored procedure did not occur after the uninstall of 2007 components.  While this is still unsolved and would take ‘significant’ effort to diagnose the cause, PSS provided a query to identify if the site is ready for the content conversion by creating a dummy .dpu entry.
  • Second problem – A manual restart of the conversion tools led to the system having a “failed to convert content”.  This was occurring because a couple dozen of the packages had mysteriously updated their source files, so there is a hash mismatch between 2007 and 2012.  The solution will be to delete those identified packages in 2012, re-migrate from 2007, and then restart the failed DP conversion (or drop a dummy .dpu)
  • Third problem – On a “completed” DP, files were leftover on the DP, both the PCK and extracted SMSPKG$ files.  Since we did not migrate ALL packages that were on the 2007 DP into 2012, those files are left behind such that they still could be converted at some point if desired.  Otherwise they need to be manually deleted after the conversion process completes.  Then, any package that had a CM07 advertisement that is set to “run from server” will migrate over to CM12 with the option to “Copy content to a package share on DP” – meaning the files in the SMSPKG$ share will remain.  These files should not be deleted from the SMSPKG$, but rather it would be better to change the package setting to not copy the contents (if appropriate for that package).
Advertisements

Why update ConfigMgr clients after upgrades?

Posted on Updated on

I was recently asked by a couple of friends, is it required for me to update my ConfigMgr clients after upgrading my site?  Intuitively I knew the answer and the why, but they need “proof” or documentation from Microsoft that stated it as such.  It was a bit of a needle-in-the-haystack to find, but the following reference on TechNet illustrates the case.

From the guide for Planning to Upgrade System Center 2012 Configuration Manager, in the upgrade checklist, the last step is to Upgrade Clients.

“After you upgrade a primary site, plan to upgrade clients that are assigned to that site. Although a Configuration Manager primary site or secondary site can support communication from clients that have a lower service pack version (including clients that run Configuration Manager SP1 talking to a site that runs System Center 2012 R2 Configuration Manager), this communication should be a temporary configuration. Clients that run a previous service pack version of Configuration Manager cannot use the new functionality that is available with the new version of Configuration Manager.”