Jump to content


Kops

Migrate ConfiMgr 2012 R2 to new Server

Recommended Posts

Hey guys, its been a while since I've posted here but I've gotten great help in the past and am hoping to find the same results :).

 

I currently have a Dell R710 server running our ConfigMgr 2012 R2 environment which is no longer under warranty, and we'd like to move ConfigMgr to a newer R730 server which is under warranty. Some info about our current setup

 

- Windows Server 2008 R2 and ConfigMgr 2012 R2

- SQL Server 2008 R2 installed locally

- All installation packages kept locally on the server

- Server is handling all Site System Roles

- Application Catalog web service point/website point
- Component Server

- Distribution Point

- Endpoint Protection Point

- Management Point

- Reporting Services Point

- Site Database Server

- Site Server

- Site System

- Software Update Point

- State Migration Point

 

I have read a few different threads that advise using Backup Site Server followed by Restore Site Server on the new server, but is there anything else involved? This is my plan..

 

- Install Server 2012 R2 on new server (with same server name)

- Install WSUS role

- Install ConfigMgr R2 with the same site code

- Install SQL Server (can I upgrade to SQL Server 2012 R2 at this time, or can I move the database to our SQL cluster without much impact?)

- Copy all packages/sources to new server (in same directory/folder structure)

- Perform Site Server Backup on old server

- Perform Site Server Restore on new server

 

Any comments or experience with this type of migration is greatly appreciated!

Share this post


Link to post
Share on other sites

Hey all, I just wanted to post here because when I made the original thread I accidentally submitted it when I had only written a couple lines and it didn't make much sense. Hopefully some people may have a second look now that the details are filled in :)

Share this post


Link to post
Share on other sites

If it were me, and I was wanting to also move my SQL location to a cluster that is already setup, then I would do that first and verify that everything is good. Then run a backup, and restore on the new server.

 

As far as your setup on the new server goes, you wouldn't need to install CM first and then restore the backup...you would do that during the install on the new server.

 

Couple links with a quick search...

http://anoopcnair.com/2012/07/01/sccm-configmgr-2012-primary-site-server-and-database-recovery-part-1/

 

http://blogs.technet.com/b/configurationmgr/archive/2013/04/02/how-to-move-the-configmgr-2012-site-database-to-a-new-sql-server.aspx

Share this post


Link to post
Share on other sites

Yeah, I wouldn't move your SQL unless it was absolutely necessary...you mentioned wanting to move it, so I suggested moving it first and then moving CM...but really, that will just be creating more work for you.

Share this post


Link to post
Share on other sites

OK - point taken, SQL will be kept locally. Appreciate the suggestions.

My other question/concern is around the name of server (currently SCCMP1). Right now all my applications/packages have their source files stored in \\sccmp1\sources\. I also have a GPO which points the Intranet WSUS server to http://sccmp1.domain:8530. I can easily update the GPO to point to the new server sccmp2, and the application/packages source files path with a little legwork (we have maybe 50 applications/packages), but I feel this method leaves room for human error.

 

Are there any suggestions on a good approach to this as well? I could name the server the same, but it wouldn't be possible to have them on the domain at the same time. I'm not sure if I could take a site backup, then shutdown the server, join the new sccmp1 to the domain, and restore the site that way?

Again your help is greatly appreciated!

Share this post


Link to post
Share on other sites

I've never done a site restore but looked at it when I was considering moving our MP from Virtual to Physical. From what I remember you have to keep the server name and domain name the same if you are going to do a site restore. Also from what I remember it is recommended to keep the site server name the same, so that when you join the new MP to the domain you can have it take over the existing AD Computer object for the old site server. The computer object itself in AD has permissions to do some activities, if you were to make a new computer object you would have to go back through and grant it permissions again...

 

~Tom

Share this post


Link to post
Share on other sites

Appreciate the quick replies! Thanks for linking me to that tool Peter, it looks like this could be very useful if I decide to shift our packages to our NAS in the future. For now I'm going to try to build the new server out as closely as I can to the old server and try the site backup/restore. Will update!

Share this post


Link to post
Share on other sites

You could use something like the following tool to adjust the source location of packages: http://www.scconfigmgr.com/2015/08/26/configmgr-content-source-update-tool-1-0-0/

Just remember that if you adjust the source file location, CM12 will need to redeploy all of your packages.

 

Personally I never both moving/changing the source file until I need to update the package, and even then I will create a new package and delete the old one when it is not longer needed.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.