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 - http://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.
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.
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.
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)
Where SourceCentralSiteFQDN Like '<Source Site%'
All objects avaliable for migration
Where StateName = 'AvailableToMigrate' and IsActive = 1
Order by Type
Let’s take the last report a bit further and give some meaning to the Type value.
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'
Or How about a count of object to migrate organized by Type.
End, Count(Type) AS Count
Group By Type
Order by Count
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.