Share via

System Center 2012 Configuration Manager Migration - Deep(ish) Dive Part 1

  • Article

In this series of System Center PFE blog posting I will be taking a deep-ish dive into the Configuration Manager 2007 to 2012 Configuration Manager Migration capabilities. This series of posts will examine logging, status messages, data, and the flow of the migration process. For a basic understanding of the migration such as what can and cannot be migrated, or how to configure migration please see the following TechNet library.

TechNet Library Link - https://technet.microsoft.com/en-us/library/gg682006.aspx

In this first article in the series I will be examining what the 2012 Configuration Environment looks like before configuring migration, migration prerequisites, and then the activities taking place just after configuring the first source site. I will also show some examples of custom reporting that may be helpful after the source site has been configured however prior to creating any migration jobs.

Disclaimer - In this article I will mention specific database tables; these should not be modified nor relied on for reporting purpose. They are mentioned here for progress or flow tracking purposes only. I will also dive into the created views which again should not be modified however can be used for reporting purposes.

 

Migration Related Objects Prior to Configuration -

Prior to configuring a source site and thus starting the data gathering activities, we will have the following item in our Configuration Manager 2012 environments.

SMS_Migration_Manager Component – this is the migration service standing for the most part idle waiting for instructions. Note that this component exists at both the CAS and Primary, however migration actives occur at the central most site.

MIGMCTRL.LOG – Migration Manager Component Log File. This is where most migration logging will occur.

Mmctrl.box – this is the folder on which the Migration Manager is monitoring for instructions.

Database Tables and Views – The Configuration Manager database has many preconfigured tables and views standing idle for migration operations and reporting. We will look at these further after configuring a source site, and when performing migration activities. The following is a list of included views.

  • v_MIG_ClientGroupState
  • v_MIG_Clients
  • v_MIG_ClientState
  • v_MIG_Collections
  • v_MIG_Dashboard
  • v_MIG_Entities
  • v_MIG_EntityRefrence
  • v_MIG_EntityState
  • v_MIG_Job
  • v_MIG_JobEntity
  • v_MIG_MigratedDPs
  • v_MIG_SiteMapping
  • v_MIG_SiteRelation

  

Permission and port requirements –

Before configuring the source site the following requirements will need to be considered (data has been taken from the TechNet library). The data gathering activity consists of the 2012 environment connecting to the source sites provider and site database. When doing so we are prompted to configure both a Source Site Access Account, and a Source Site DB Account. These accounts will require the following permissions.

Source Site Access Account – Read Permissions to all source site objects.

Source Site DB Account – Read and Execute on the source site DB.

Also if using the System Center 2012 Configuration Manager Computer account, ensure that it is a member of the Distributed COM users group in the source domain.

If you are going to upgrade any distribution points the Source Site Access Account will need delete permissions on the site class in order to perform the migration.

Finally the following ports are used during migration activities.

  • NetBIOS/SMB – 445 (TCP)
  • RPC (WMI) – 135 (TCP)
  • SQL Server – 1433 (TCP)

 

Configuring Source Site and Initial Data Gathering -

Here is a rough outline detailing the sequence of events that follows the configuration of a Source Site.

  1. Source Site is configured in the console.
  2. *.SYN file is dropped into Mmctrl.BOX
  3. Connection is established to Source DB and Provider using an impersonation of the configured security context.
  4. Status Message 8600 is generated indicating that the connection was successful to the source site.
  5. Source Site validation and source child site discovery is performed.
  6. Status Message 8616 is generated indication that the migration process was able to gather all child sites to the specified source site.
  7. Site mapping is created and entered into the MIG_SiteInfo table; the job is recorded in the MIG_SiteMapping Table. Additionally the v_MIG_SiteMapping view is populated.
  8. Data Collection is executed; this includes object, collection, collection dependencies, and deep dependences data gathering. This data can now be found in the MIG_Entity and MIG_Collection tables. Additionally the following views are populated which may be helpful for reporting purposes - v_MIG_EntityState, v_MIG_Entities, v_MIG_Collections.
  9. Status Message 8065 is generated indicating that the data gathering process has completed.

Status Messages after source site definition and data gathering.

 

 Pre Migration Custom Reports –

So with the data gathering activities completed for the parent source site, we may want to look at some of the data collected before creating migration jobs. I have found that the easiest way to achieve this is through custom reporting. I will not walk through creating the Configuration Manager reports, rather will give a few TSQL examples which can easily crafted into SRS reports.

Count of Object Available for Migration (specify Source Site)

SELECT

SourceCentralSiteFQDN,

NumOfSourceSiteObjects,

LastSuccessfulSynced

From v_Mig_Dashboard

Where SourceCentralSiteFQDN Like'<Source Site%'

 

 

 

All objects avaliable for migration

Select

EntityName,

Type

From v_MIG_Entities

Where StateName ='AvailableToMigrate' and IsActive = 1

OrderbyType

 

 
 

Let’s take the last report a bit further and give some meaning to the Type value.

SELECT

EntityName,Type=

  CASE [Type]

    WHEN 1 THEN'Collections'

    WHEN 2 THEN'Software Distribution Packages'

    WHEN 3 THEN'Advertisements'

    WHEN 7 THEN'Queries'

    WHEN 9 THEN'Metering Rules'

    WHEN 11 THEN'DCM CIs'

    WHEN 12 THEN'DCM Baselines'

    WHEN 13 THEN'Update Groups'

    WHEN 14 THEN'OS Install Packages'

    WHEN 15 THEN'Update Templates'

    WHEN 16 THEN'Update Deployments'

    WHEN 18 THEN'OS Images'

    WHEN 19 THEN'OS Boot Images'

    WHEN 20 THEN'Task Sequences'

    WHEN 21 THEN'Device Setting Packages'

    WHEN 23 THEN'OS Driver Packages'

    WHEN 24 THEN'Update Deployment Packages'

    WHEN 25 THEN'OS Drivers'

    WHEN 26 THEN'AI Software Lists'

    WHEN 250 THEN'Boundaries'

    WHEN 252 THEN'App-V Packages'

    WHEN 254 THEN'AI Categories'

    WHEN 255 THEN'AI Hardware Requirements'

    ELSE'Type not defined'

End

From v_MIG_Entities

Where StateName ='AvailableToMigrate'and IsActive = 1

OrderbyType

 

 

Or How about a count of object to migrate organized by Type.

SELECT

Type=

  CASE [Type]

    WHEN 1 THEN'Collections'

    WHEN 2 THEN'Software Distribution Packages'

    WHEN 3 THEN'Advertisements'

    WHEN 7 THEN'Queries'

    WHEN 9 THEN'Metering Rules'

    WHEN 11 THEN'DCM CIs'

    WHEN 12 THEN'DCM Baselines'

    WHEN 13 THEN'Update Groups'

    WHEN 14 THEN'OS Install Packages'

    WHEN 15 THEN'Update Templates'

    WHEN 16 THEN'Update Deployments'

    WHEN 18 THEN'OS Images'

    WHEN 19 THEN'OS Boot Images'

    WHEN 20 THEN'Task Sequences'

    WHEN 21 THEN'Device Setting Packages'

    WHEN 23 THEN'OS Driver Packages'

    WHEN 24 THEN'Update Deployment Packages'

    WHEN 25 THEN'OS Drivers'

    WHEN 26 THEN'AI Software Lists'

    WHEN 250 THEN'Boundaries'

    WHEN 252 THEN'App-V Packages'

    WHEN 254 THEN'AI Categories'

    WHEN 255 THEN'AI Hardware Requirements'

    ELSE'Type not defined'

End,Count(Type)AS Count

From v_MIG_Entities

Where StateName ='AvailableToMigrate'and IsActive = 1

GroupByType

OrderbyCount

 

While there are no out of the box pre-migration reports, given the data provided during the migration data gathering activities we can pull together some pretty useful and slick reports. For instance in a very mature Configuration Manager 2007 hierarchy there may be thousands of objects collected and available for migration. In order to review this data prior to creating an actual migration job one might use a series of the above examples to plan what object to migrate and what objects to exclude from migration.

 

Part 1 Wrap Up -

I hope this information was useful. In my next post to this series I will walk through the migration job creation process in much the same detailing the back end movement and status messages. In future posts I will detail sharing content between the two hierarchies, upgrading DP’s, and finally removing the migration link.

Comments

  • Anonymous
    January 01, 2003
    thank you
  • Anonymous
    February 26, 2014
    Any chances to have part 2 of this post ? :)
  • Anonymous
    May 30, 2014
    Hello Neil ,

    A great article on migration , it would be so kind of you if we can have part 2 and part 3 as well .
    Thanks a lot in advance for posting these articles.
  • Anonymous
    April 30, 2015
    Port 1434 UDP is also required for SQL named instances if SQL is not co-located with the primary site server.