Partager via

Migration Tool - ConfigMgr 2012 to ConfigMgr 2012 R2 using the Computer Account

  • Article

Migration Tool - ConfigMgr 2012 to ConfigMgr 2012 R2 using the Computer Account

 

Section A - Ports

Before you configure the Source Hierarchy to start your Data Gathering, you will want to assure the following ports are open.

 

When gathering data the following network protocols and ports are used by Configuration Manager to communicate between the two systems.

 

1) NetBios/SMB on port 445 (TCP)

2) RPC (WMI) on port 135 (TCP)

3) SQL Server on port 1433 (TCP)

 

If any of these ports are not correctly configured to allow data travel, you will end up with Data Gathering issues.

 

Section B - Preparing the Source Hierarchy

You want to do this with the highest point in your existing ConfigMgr 2012 environment, (Example: In a Hierarchy with a CAS and two primary site servers you will want to specify the CAS as the source).

I also recommend following best practice to use the Configuration Manager 2012 R2 computer account for the migration account on the source. Why not use a regular domain account, you could but using the Computer Account, which is a Local

System account and has powerful access to the computer assures higher success rates for migrations.

 

(Configure the Computer Account in the ConfigMgr Console)

These steps are going to give the ConfigMgr 2012 R2 Computer Account the minimum permissions to migrate data from the existing ConfigMgr 2012 site.

 

1) On the Source ConfigMgr 2012 environment, assure you are on the highest point in the Hierarchy

2) Open the ConfigMgr 2012 Console

3) Navigate to Administration \ Security \ Security Roles

4) Right click "Read-only Analyst", select Copy

- On the Copy Security role dialog:

- Set the Name to ConfigMgr2012R2Migration

- Set the Description as "Role used for Migration to new ConfigMgr 2012 R2 Environment", Click OK

5) Navigate to Administration \ Security \ Administrative Users

6) Right click Administrative Users, select Add User or Group

- On the Add Users of Group dialog:

- Next to "User or group name" click Browse

- Enter the "Domain\ComputerAccount$" for the ConfigMgr 2012 R2 Site Server (Example: CONTOSO\CM12R2$), click OK

- Next to "Assigned security roles:" click Add

- Check the "ConfigMgr2012R2Migration" security role box, click OK

- Click OK

 

(Configure the Computer Account in the SQL Database)

These steps are going to give the ConfigMgr 2012 R2 Computer Account the minimum permissions to migrate data from the existing ConfigMgr 2012 site.

 

1) On the Source ConfigMgr 2012 environment (or remote SQL server if remote for that environment), Open the SQL Server Management Studio

2) Enter your credentials and click Connect

3) Click New Query

- Enter the following query: CREATE LOGIN [Domain\ComputerAccount$] FROM WINDOWS

- Execute the query, assure that you get the return of Command(s) completed successfully

4) Navigate to Security \ Logins

5) Select the "Domain\ComputerAccount$" you just added, right click and select Properties

- On the Login Properties dialog:

- Select User Mapping

- Under "Users mapped to this login", check the "CM_SITECODE" DB box

- Under "Database role membership for:CM_SITECODE", check db_datareader, db_onwer and assure public is checked, then click OK

 

 

Section C - Specify Source Hierarchy

Now that we have the existing ConfigMgr 2012 environment prepared, we need to create the Source Hierarchy in the ConfigMgr 2012 R2 environment to gather data.

 

1) On the ConfigMgr 2012 R2 site server, open the ConfigMgr 2012 R2 Console

2) Navigate to Administration \ Migration \ Source Hierarchy

3) Right click Source Hierarchy, select Specify Source Hierarchy

- On the Specify Source Hierarchy dialog:

- Set the Source Hierarchy to "New source hierarchy"

- Set the "Top-level Configuration Manager Site Server:" to the Fully Qualified Domain Name of the ConfigMgr 2012 Top-level site server name

- Under the Source site access accounts, select "Computer account"

- Under Specify the Source Site Database Account to use to access to the SQL Server for the source site server, select "Computer account", Click OK

4) You should then see the Data Gathering Status process on the screen

 

Section D - Migration Jobs

Now that you have completed the Data Gathering process, you are ready for the next phase of the migration which is to create a migration job

Below you will find an example of a package migration.

 

1) On the ConfigMgr 2012 R2 site server, open the ConfigMgr 2012 R2 Console

2) Navigate to Administration \ Migration \ Migration Jobs

3) Right click Migration Jobs, select Create Migration Job

- On the Create Migration Job Wizard dialog:

- Set the Name (Example Adobe Packages Migration)

- Set the Job type: Object migration, click Next

- On the Select the objects to migrate dialog:

- Select Software Distribution Packages

- Check the boxes for each Adobe product you wish to migrate (example Adobe Reader XI 11.0), click Next

- On the Assign ownership dialog:

- Set the top-level site server as the site you want to assign ownership (Example: CAS), click Next

- On the Security Scope dialog:

- Check the Security Scope you want to assign it to in the list, you can take default or create a custom security scope, click Next

- On the Settings dialog:

- Select Run the migration job now (default) or Schedule the migration job

- Select Do not migrate updated objects (default)

- Assure "Transfer the organizational folder structure for objects from the source hierarchy to the destination hierarchy" box is checked, click Next

4) Click Ok until you reach the Completion dialog, then click Close

 

The job will run now, unless you scheduled for a later time. You can troubleshoot and look for its progress in the "migmctrl.log" which will be created on the ConfigMgr 2012 R2 Site Server.

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use