Need to Migrate 2012 Clients to New Server

[MagnumVP]

We currently have a single 2012 R2 SCCM server with a single site that is soon to be retired.

 

We are going to spin up a new server and install and configure the new SCCM 2012 R2.

 

Once it's configured what do we need to do to migrate the clients (about 500) to the new server?

[h4x0r]

A few questions come to mind...first, if you have a single site, why are you retiring a SCCM 2012 R2 setup, only to re-install a new SCCM 2012 R2 environment with a different site code?

 

But check out this thread

https://social.technet.microsoft.com/Forums/en-US/e0a9d2c6-dd81-4d3c-8a37-52a6e1303928/reassigning-site-sccm-2012-r2?forum=configmanagergeneral

[MagnumVP]

The server is on an older server box (Single Proc with 8GB RAM, 36GB HD). Originally it was only going to be used for testing but the more they used it the deeper they got in and the deeper. They are wanting to use it in a more productive manner (software deployment, Windows Deployment, etc...)

 

I didn't create the problem, I'm just here to fix it.

 

Would it be easier to spin up the new server, join the existing site and then remove the old server?

[phil_w]

I'm assuming this is because the existing server isn't powerful to handle everything?

 

Personally I would keep the old server, and let it continue to function as the Primary Site Server and simply add the second server into the site, install all the roles you need on it and use boundary groups to make the clients use the new server instead of the old one. It's the least messy way of getting the new server into use, but it does mean keeping the old server on.

 

Alternatively you could do a complete site backup and do a restore during install on the server, in order to make that the primary server and decommission the old one. But that means more down time than just adding an additional server.

 

A funky third option would be to set up a new server as a new primary site along side the existing one, then from the existing site deploy a client package with install switches to connect to the new site. No downtime involved but it does mean waiting for all your machines to run the client install package.

 

But really it's much much easier to just add the new server into the existing site, and keep the old one running just to act as the Primary Site Server with all the real work being done by the new box.

[MagnumVP]

If we add a new server and keep the primary, are we able to decommission the server or does it have to stay running....forever!!!!? The end goal is to remove the server not keep it running.

[h4x0r]

If you are just needing to move it to different hardware, then do a site backup and restore on the new hardware. No need to create a new site.

 

*edit

Depending on your organization size, adding the secondary server may be something to look at, but the easiest thing will be to restore a backup onto the new server.

[MagnumVP]

I considered backup and restore but restoring to a different server name causes issues from the research that I've read.

[Peter van der Woude]

Correct. A backup and restore needs the same server name. To point the clients to the new site, either push the client using the new site, or push a script using the old site to reassign the clients.

[h4x0r]

So power off the old server and name your new server the same? Unless I'm missing something, you would just reset that computer object in AD and the backup would restore with the correct server name.

[MagnumVP]

I would normally agree that it shouldn't be an issue, but the powers that be don't want to make that leap if they can't go back to the original server if the new server is having issues.

 

I've tried to explain that even moving clients isn't 100% going to work and even a migration has some risk. However, they don't want to take down a working environment just on the chance that it should work. Hence why I'm trying to find a work around that they are willing to attempt.