SOLVED Migration to new hardware and version, objects missing

[Partholan]

Hi!

We want to move our current SCCM setup to new hardware. Here's the data of the current setup:

ConfigMgr Server: Primary Site, Current Branch 1610 on Windows Server 2012 R2
SQL Server: Dedicated MS SQL Server 2012 instance on a Windows Server 2008 R2 which hosts several other databases in other instances.

Since the OS of the SQL Server isn't supported by updates 1703 and higher and we don't want the hassle with the shared SQL server anymore we decided to move the whole setup to new hardware:

Target:
ConfigMgr Server: Primary Site, Current Branch 1802 on Windows Server 2016
SQL Server: Dedicated MS SQL Server 2016 (default instance) on Windows Server 2016

We also have a testing environment which resembles the above but in smaller scale. In a first test we installed the target site using the same site code as the source site and started the side by side migration. The data gathering seemed successful and returned an appropriate number of objects (about 1100) that could be migrated.
Yet, when we wanted to create an actual migration job it only listed numbers in some of the categories (e.g. collections and software metering) but showed 0/0 in most other categories (eg. applications and task sequences), even though the source site has all of these. The total of objects offered to migrate doesn't come close to the 1100 objects found by the data gathering job.

What could be the cause of this? Does the new site need a different site code for this to work? And, if we manage to migrate the site, how do we get the clients to communicate with the new site?

Kind regards,
Partholan

 

[Prajwal Desai]

Setup a new Configuration manager environment with new site code and change the site code on all clients to point to new ConfigMgr server.

 

[Partholan]

Hello Prajwal,

thanks for your reply.

So it really needs a different site code for the migration to work? OK, I'll do as you've suggested and report the results when done.
As for the clients, what method would you suggest to change their site code? I've found VB scripts on the internet to do that but I guess you could also push install a new ConfigMgr client. Maybe there's a more elegant solution.

Btw, your SCCM2012 guide really helped me set up my first working SCCM server

Kind regards,
Partholan

 

[Prajwal Desai]

When you setup a new SCCM infra on a new hardware, you basically go with a new site code. I prefer to go with a new site code. Once the client agents are part of new site, the agent upgrade is done automatically. I would not bother about client agent upgrades as it can be managed with auto client upgrade feature.

 

[Partholan]

We did some more tests with different versions of SCCM and always got the same results. If the site code for the destination system is the same as the source site code we get the phenomenon described in the OP. With a different site code the migration job offers all objects for migration.

The client migration doesn't satisfy, though. The client entries get migrated so the Devices section is populated after migration, yet since the clients' agents still have the source site code they are listed with a "No" in the "Client" column and also don't have a site code.
Enabling auto client upgrade didn't do anything on the clients but maybe I'm just not doing it right.
We tried client push installations on our test clients and they successfully moved to the new site (Client=Yes, Site Code=NEW) but they lost all of their Collection assignments in the process.

Could you please elaborate on the client migration part a bit more?

Thanks,
Partholan

 

[Partholan]

Gonna answer my own post.

Alright, I think we now have a method that works, although this requires a bit of manual work. Apparently, SCCM doesn't evaluate the collections after the migration and relies on the scheduled full update to do this (usually after 7 days). It does update the membership of a specific collection when you select its properties and change any value. So we did a CTRL+A on our collection folders and clicked on "Update Membership" and it only took a few minutes.

I don't know if this is a general issue or if it just happened in our test scenario. Maybe someone else can confirm this behaviour.

So, to summarise the whole migration process, we:
- installed a new site with a new site code and new versions for OS, SCCM and SQL server.
- gathered data and created/started migration jobs.
- copied the source folder (which is on our SCCM server) to the new server and used a script to replace the source share in all deployment types so it points to the new share on the new server (if you keep your repository on a separate server you don't have to do this, of course).
- made a few adjustments, e.g. create the users (which don't get migrated, btw) and their security roles.
- installed the new ConfigMgr Agent using client push. We also tried changing the site code on client computers using a script which also works (just as a backup strategy).
- updated the collection membership using the method described in the first paragraph.

Other things that don't get migrated are:
- Site settings like PXE in DP settings etc.
- Customized security roles (can be exported and imported, though)
- Client settings for the SCCM agent
So it's mainly stuff on the Administration tab that has to be taken care of manually.

Kind regards,
Partholan