This post is more or less a follow-on to my previous post: ConfigMgr Site Server Operating System Instance Change. It lists the steps I recommend when performing a site backup and restore of a System Center Configuration Manager (ConfigMgr) site for one of the two scenarios I discussed in that previous post: operating system upgrade and hardware refresh.
The below steps make a handful of assumptions so adjust accordingly if these assumptions do not fit your existing environment. For complete documentation on site backup and recovery see Back up a Configuration Manager site and Recover a Configuration Manager site in the official documentation.
Assumptions
- SQL Server is co-located with the primary site server. See Why you should not use remote SQL Server with ConfigMgr 2012 if you for some reason you need convincing that using a co-located SQL Server is the better choice.
- You have access and can log into both the new and old ConfigMgr site servers with an account that is a local administrator on both systems as well as a sysadmin in the SQL instance hosting the ConfigMgr database.
- You used an AD security group containing the site server’s computer account to grant permissions on the System Management container, to site systems, on remote content locations, and on/to any other places or items where permissions are required by the site server. If you didn’t do this, now is a good time to do it because you’ll be swapping them out anyway. There is a slightly different workflow from the below that can be used if you didn’t use a security group to maintain permissions without having to modify any ACLs, but if I included those steps, I would just be re-enforcing your use of a terrible practice.
Terrible Practices
While I don’t believe in “best practices” (per my many soapboxes) as those are simply fool’s gold and not suitable for real-world, production environments, I do believe in bad and terrible practices as these are simply doing something that makes your life, or the life or your successor or subordinates, difficult or painful.
Old Site Server
- Perform a health check.
- Document all configurations that are external to ConfigMgr:
- Account passwords for accounts used in ConfigMgr (Monitoring namespace, Overview -> Security -> Accounts).
- Service accounts and password:
- SQL Server
- SQL Agent
- SQL Server Reporting Services
- Custom share and NTFS permissions.
- Certificates in use in IIS as well as in ConfigMgr.
- Content source locations.
- ADK version.
- If you will be restoring the site to a system with an upgraded operating system, remove the following roles from the site server (if they are installed on the site server):
- Software Update Point *
- Management Point *
- Distribution Point *
- Reporting Point
- Wait for them to be removed fully. Check the sitecomp.log as well as the individual setup and removal logs files for each component as listed at Log files in System Center Configuration Manager.
- Stop and disable all ConfigMgr services on the site server as well as any remote management points:
- SMS_EXECUTIVE
- SMS_SITE_COMPONENT_MANAGER
- Backup everything!
- SQL databases.
- Site server file systems (including cd.latest of course if currently on ConfigMgr Current Branch).
- Custom reports: SQL Server Database Backup and Restore reports.
- Stop and disable all SQL Server services:
- MSSQLServer
- SQLSERVERAGENT
- Rename the server to “oldserver” (or something appropriate). Renaming this server allows it to remain online and accessible when (not if) you forget something.
- Reboot.
Role Removal
Removing these three roles is optional; however, they are stateless and easy to reinstall after the restore. Also, because these three roles require IIS, this is a good opportunity to stand up a new site system to host them separate from the site server. By doing this, you eliminate the need for IIS on the site server completely which is something I (along with many others) highly recommend. Note that reporting services does not require IIS so moving it to another site system is not explicitly included in this recommendation.
New Server
- Build a new Windows server with same volumes and drive letters. Using a newer operating system is optional as long as the one you are using is supported. Now is a good time to move to Windows Server 2016 even if this is just for a hardware refresh though (two cats, one bullet).
- Join the server to the domain.
- Server Name:
- If you have not performed steps 8 and 9 above on the oldserver yet, use a temporary name for this new server and then rename it to the oldserver name after performing steps 8 and 9 above on the old server.
- If you have already performed steps 8 and 9 above on the oldserver, then name this server the same as the old server.
- Validate that DNS accurately reflects the IP Address of the new server for the site server’s name.
- Add the new server’s AD computer account to same AD security groups as the old server.
- If security groups were not used to assign permissions, first create a new AD security group, add the new site server account to this new group, and assign permissions for this group to the following:
- System Management Container
- Client Install Account (if used)
- Local Admins on all site systems
- Shares and NTFS permissions as needed
- If security groups were not used to assign permissions, first create a new AD security group, add the new site server account to this new group, and assign permissions for this group to the following:
- Install prereqs: Site and site system prerequisites for System Center Configuration Manager.
- Install SQL Server – including reporting services using the same service accounts. This must be the same version and edition of SQL Server as was used on the old site server.
- Install desired ADK based on the version of ConfigMgr you are using.
- Install WSUS (use SQL Server and not WID).
- Open WSUS console to verify it works, do not complete the first start wizard.
- Install WSUS hotfixes if installing site server on Windows Server 2012 or 2012 R2.
- 3095113
- 3159706 + Manual steps 1 & 2 in hotfix KB
- Restore ConfigMgr SQL database to same location and path it existed on the old site server.
- Copy SCCMContentLib from the old site server to the same location and path on the new site server.
- Copy the cd.latest folder from the old site server to a temporary location on the new site server.
- Run ConfigMgr install from cd.latest completing the wizard appropriately.
- Choose restore.
- Select the database option for a manually restored database.
- Choose same target locations as applicable. Double and triple check this! As noted in the previous post, it is technically possible to use different logical locations and drive letters, it’s more work than it’s worth.
- Sit back, relax and watch the log file if you are so inclined.
Windows Server 2012 R2 Update
If using Windows Server 2012 R2, make sure that you are using the latest media released so that Windows Server 2012 R2 Update is included.
Post Actions
- Re-add any roles removed or better yet, as noted above, stand up a new site system to host them.
- Import any custom reports from the backup done using the SSRS web pages or a supplemental script.
- Add account passwords back to ConfigMgr accounts.
- Backup everything!
- Validate!
- Validate some more!
- Test!
- Test some more!
Supplementary Actions
Source File Relocation
This is only necessary if your source files are located directly on the old site server. If this is the case, now may be a good time to move them to a file server or other server so that they are not on the site server. There are no technical benefits to doing this, but hosting them separately has advantages — like not having to ever move them in the future again during similar site server moves.
- Move source files to the new site server.
- Set up file share(s) with the same name(s) and permissions as on the old server.
- Use the ConfigMgr Content Source Update Tool 1.0.0 or a similar script to re-point content in ConfigMgr. This increments the version number on all content which in turn cause network traffic as ConfigMgr must re-validate all content files on all distribution points. It will not retransfer files though.
DB Maintenance
- Set up Ola’s SQL Server Maintenance Solution scripts for database re-indexing, statistics rebuild and backup.
ConfigMgr Upgrade
You can combine the above with an in-place ConfigMgr site upgrade or an in-place SQL Server upgrade. This can be done on the old server (before the restore) or the new (after the restore). I would generally recommend doing this before to isolate the changes to the old server and prevent any old components from ever being on the new site server; however, you may have to do this after if the old site server is on Windows Server 2008 R2 and you want to upgrade to ConfigMgr CB 1702. Do give time in between the operations though, too much change in too short a span of time will make troubleshooting much more difficult if something does go wrong.
Thanks to both Kent Agerlund and Marc Graham who contributed to and reviewed this post.
Can you elaborate a bit on why moving IIS out of the site server completely is a good thing and what kind of scenarios would benefit from this configuration?
Reduced complexity on the site server is the primary reason. The site server is the center of all ConfigMgr activity so keeping it clean helps performance and reduces the number of things that can go wrong. Also, when IIS has problems, they are challenging to troubleshoot or resolve. If you’ve moved your client-facing site roles off of the site server, worst case is you rebuild the site system completely. If that’s all on the site server, that’s not easy at all. Moving IIS and the client-facing site roles off of the site server also eliminates any [direct] client traffic from ever touching the site server also reducing the load placed on it. The only systems ever talking to the site server are other site systems. Because only other site systems need to communicate with the site server, this enables you to lock down traffic flows to the site server as well.
None of this is that big of a deal if you are managing 200 clients, but if you are managing 1,000 or more, the above helps tremendously and allows you to scale up easily as well.
Thanks for the prompt response! Great info, very helpful for future planning.
Can you point me towards any articles on how to do this?
How to do what?
Great article Jason, thanks for sharing. I’m currently looking into this method as we’re stuck with ConfigMgr 1606 on server 2008 R2 running on physical hardware. I’m nervous about the in-place upgrade option and we’re low on disk space so this feels like the best approach.
Annoyingly we also have a pointless CAS and I’m waiting on the availability of a new hypervisor platform that will be hosting our site servers in the future so I’m also staring down a site migration at some point later on. A similar deep dive article covering that would be great! 🙂
I stay away from migrations. The System Center Guys have a good post that may help you out though: https://www.systemcenterdudes.com/sccm-1511-migration/
Thanks, Jason.
Great tip on copying SCCMContentLib. I had not thought of that.
You’re Welcome!
Hey Jason,
Just came across this post and it has some great information in it, so thank you.
Looking to Backup and Restore our 1702 environment to new Server 2016 hardware, while also moving the SCCM install location off the C: (OS) drive.
Your previous post briefly mentioned this, but wondering if you can elaborate on how this might be possible? Does a Restore automatically reinstall to the same paths? Anyway around this?
Note that SQL exists on a remote server and would not need recovering.
The site restore process doesn;t actually restore ConfigMgr itself; it installs a new copy of ConfigMgr and restores the database to this new instance of ConfigMgr. From memory, in ConfigMgr CB (and since one of the later version of ConfigMgr 2012, you can actually change the installation path of this new instance of ConfigMgr during the restore process and it will work fine (and be supported). I can;t say that I’ve ever tried though and this is one of those major variables that I wouldn’t want to change during a restore unless I really, really, really had to.
Thank you for this! Does the ConfigMgr SQL database really need to be restored to same location and path it existed on the old site server? Looking to move the database to its own partition on the new hardware.
Thanks again.
Technically no, it doesn’t need to be. Pay attention to the details when trying to change paths though, and validate everything thoroughly after the restore. Note that moving the DB to its own partition has no actual advantage though. Moving the DB to its own sets of disks does have benefits though.
Hi there, what should i do in addition if i want to restore the database on a different location?
It’s been a while, but from memory, the restore will ask you where the DB is located so this shouldn’t be an issue.
Hey Jason,
Thanks for this great detailed post.
in following, is described the current environment and the desired environment:
OS Server: 2008r2 ==> Windows Server 2016 STD
SCCM Version: 5.00.8239.1000 – 2012 R2 SP1 (Only 1 site) ==> 1702 or 1706
MS SQL Version: SQL Server 2012 Service Pack 1 ==> SQL Server 2016 SP1
Installed Roles:
as I understood from your post , these are the steps I should take:
1. install New Windows server 2016
2. Install New SQL server (same version as the old), may I upgrade the SQL server to
2016 at the end?
3. should I the same SCCM version (2012r2 Sp1) and after every thing works ,upgrade
it to 1702? or I may install directly version 1702 ?
Thanks in Advance,
Ariel.
1. Yes.
2. Yes. Once the site is upgraded, you can perform an in-place upgrade of SQL server.
3. You can only restore to the exact same version of ConfigMgr. That means restoring to 2012 R2 SP1 and then upgrading. You could upgrade to 1606 first, then backup and restore, and then upgrade to 1706, but that seems like more work to me.
Hi Jason
I’m shortly going to be migrating a CAS and single Primary to new hardware/OS using this method. I’ve built the new servers but they’re currently not domain joined. I was wondering, how far I can proceed with the setup of the new servers before either joining them to the domain, or, if I join them now, before renaming them?
I want to do as much work in advance of the weekend where I schedule downtime for SCCM and actually switch over to the new servers. For example, if I were to install all the SCCM prereqs and SQL now, would it be OK to domain join or rename the server later? I’m just mindful of potential gotchas in taking this approach but want to leave myself as little work as possible over the migration weekend.
Also, being as I have a CAS and Primary to move, should I do them in a particular order or does it not matter in this instance? For example there is a SUP on both the CAS and Primary with the CAS being the upstream. I’ll be removing these roles ahead of the restore as per your recommendation, but I’m not sure if there would be issues if for example I migrated the CAS and restored to the later WSUS version but the Primary was still on WSUS 3.
Thanks in advance
Stewart
> “I’m shortly going to be migrating a CAS and single Primary to new hardware/OS using this method.”
Why? If you have a single primary site, you are just causing yourself pain and spending additional money by keeping the CAS without adding any capabilities whatsoever. I would highly recommend that you actually perform a full migration and get rid of the CAS.
Hi Jason
The CAS, like many, should never have been installed in the first place and I want to get rid of it. The issue I have is that the company I work for has recently signed a deal to outsource our hosting function. In the not-too-distant future, most of our services will be hosted by the 3rd party.
The immediate problem I have is that I have a very urgent requirement to upgrade SCCM past version 1606 and off of Server 2008 so we can patch Office ProPlus C2R natively and use the latest Win10 builds.
My long-term plan is to stand up a completely new site hosted by our service provider and migrate items across so I can get rid of the CAS. Given the urgent timescales, I think it’s going to be faster for me to backup-restore what we have than do the migration to a fresh site now.
I’ve managed to source servers that are equal in spec to the current site servers that were destined for decommissioning so there’s no additional spend in that sense.
Thanks
You mentioned that you can only restore to the exact same version of ConfigMgr.
Was this changed recently? I came across another post on the Microsoft blog with instructions on how to upgrade ConfigMgr to the latest version along with upgrading OS and SQL.
With this other article, would you still recommend restoring to the same version and than upgrade?
Second, anything that I need to consider differently if the ConfigMgr database consists of multiple files?
No, this was not changed. An in-place upgrade of the site and a site backup and restore of the site are two different things and have two different purposes although they can be combined to effect an OS instance upgrade. That blog does not describe a backup and restore of the site to a different version of ConfigMgr.
Hi Jason, thanks for the extended write up. Great work! I will be using this information at a future migration. In this specific case, the SQL-database is placed on a dedicated SQL-Server. Do I need to take additional settings into account for this migration? I assume I can just perform a Site Recovery on the new server which will use the remote SQL-server during the installation?
Since the old server is a virtual server, could I just mount the data drive to the new server with all its content and SCCMContentLib?
This is one scenario where having a separate SQL Instance makes life a little easier because you don’t have to do any of the SQL specific tasks. Other than that, it’s pretty much the same, just run the site restore from the ConfigMgr media and point it to the existing DB (making sure of course that the old site server is offline and will never be restored or at least the ConfigMgr services on it).
For the Content Library, absolutely, as well as any other file-based data that you may need like source repository, configurtion.mof, custom reports, etc.
Hi Jason, thanks for taking the time to comment on my question. Appreciate it!
Run ConfigMgr install from cd.latest completing the wizard appropriately.
Choose restore.
—–
Let me get this right, copy SCCMContentLib over to same logical drive and then…
1. Recover a site ->Next
2. Reinstall this site server / Skip database recovery ->Next
3. Recover primary site ->Next
We don’t need to check “Recover this site server using an existing backup”, by copying SCCMContentLib over does the trick?
I’m trying to restore SCCM 1610 on Win2008R2 to a new Win2016 VM, then run 1710 upgrade, then migrate SQL 2012 to a new SQL box running 2016SP1 with HA.
SCCMCOntentLib is simply your content and has nothing to do with your DB and really doesn’t define anything about the actual site. Step 8 above in the restore section calls out restoring the DB and step 11 calls out choosing the option to use the existing DB which you restored in step 8.
Hi Jason, I wanted to check up on you since I’ve used your guide to upgrade an environment and it helped me a lot. Thanks!! I’ve run into the issue where the WSUS catalog version was reset and clients couldn’t find new software updates. This is described perfectly in this blogpost: http://rzander.azurewebsites.net/query-to-get-mincatalogversion-from-sccm-updates/
Hopefully it can help someone who will experience these problems after the site restore. Cheers!
Hi Jason,
Thank you for this great article.
We have an SCCM 2012 r2 sp1 with SQL 2008 r2 (local) and we want to move to SCCM 1710 with DB’s attached to a remote SQL 2016.
Here are the steps i have planned :
1) Update site to SCCM 1602 (which support SQL 2016)
2) Backup and restore DB’s to sql 2016
3) Create VM Windows 2016 with SCCM 1602
4) Site restore
5) Update to SCCM 1702
6) Update to SCCM 1710
7) Upgrade clients
Is that a correct workflow ? Should i care of something other than what you mention in your article ?
I wasn’t moving SQL off-box in the post so that’s a difference and does change the workflow a bit. Why are you moving SQL off-box though? I strongly urge you to reconsider that.
If you are dead-set on doing this, then I at least wouldn’t combine the moving of SQL and the moving of ConfigMgr. Do each separately so that if something does go wrong, you know that it was one or the other instead of having two possible major changes occurring at the same time. With that in mind, add:
2.5) Configure ConfigMgr to use new SQL DB
Also, Installing ConfigMgr and the site restore are one in the same, so 3 and 4 should really be:
3) Create VM
4) ConfigMgr install with site restore
Also, you can’t upgrade to ConfigMgr CB 1602 since that’s not a baseline version (and doesn’t support Server 2016 anyway). You’ll have to use 1606 + hotfix rollup from KB3186654 (if you can still find it since it’s out of support).
We are not dead set on doing this but we cannot have an sql server installed for each application we use.
We are using SCCM only for updates we have collections with maintenance windows and we are servicing servers with updates, that’s all.
Don’t you think it would be better in our case doing a migration with a fresh Windows 2016 + SCCM 1710 with database off-box in a sql 2016 server ?
It seems to me that it would be quicker than doing the steps i have planned.
The site code will change but it should not cause issue i think ?
I understand a site restore is way better in most of the case but if you have a lot to upgrade like in our case, would not be better to use migration ?
Can you do all this if you are trying to move to a new server OS and sql version OS?
Yes. That’s the main reason I wrote this article. Keep in mind though that you must upgrade the SQL Server version before or after the restore as its not supported to perform a site restore to anything other than the version of SQL Server currently hosting the site’s DB.
Hi Jason,
Very good article. Thanks for this.
I need to move our ConfigMgr to new Windows Server 2016 server. When restoring ConfigMgr to new server and run the setup from cd.latest you have the option to “Recover this site server using an existing backup” or “Reinstall this site server”.
I think “Reinstall this server” is the right option to choose because OS is changed and we are not recovering to same server?
I think you had this answered in the TechNet forums but the answer is to choose recover.
Another question about WSUS. Should WSUS SQL DB be restored from old server or start from scratch?
I think you had this answered in the TechNet forums, but the answer is it depends. Starting with a fresh WSUS instance and DB though can be helpful as it cleans the DB nicely and WSUS DB bloat is an issue.
Thanks for the walk through. Is there a specific reason you chose to restore from a manually recovered SQL DB versus recovering from the SCCM generated backup set, or is it just preference? I’m going to be going through this shortly and am just weighing options.
Preference mainly. I like to manually control certain aspects like the backup and restore of the DB so I know exactly what state it’s in and can validate that before ConfigMgr even gets involved.+
Thanks for this precise article on sccm backup and restore – much appreciate it..!
I had SCCM 2012 SP2 running on a 2008R2 server, SQL 2008R2, which I want to migrate to a new 2016 server, likely with sql 2016 and upgrade sccm to Current branch 1802.
a.) So far I have upgraded SCCM on 2008R2 server to Current branch 1606 and SQL to SQL 2014 (As both these sccm and sql versions are supported on server 2008R2 and 2016).
b.) I have taken a backup of Site Server and Site Database. Also taken a backup database using SQL management studio and copied into the new server.
Questions:
If my plan is to finally completely replace the 2008R2 server with 2016 server as the Primary Site server:
1.) Is there any chance I could use different host names for both servers, yet do the Restore into 2016 server?
2.) As you mentioned if I use the same hostname for 2016 server: Do I have to run splash setup using CD.Latest from the backup or can I also use a new 1606 installation media to do so?
3.) Once I select ‘Recover a Site’ option, should I be selecting ‘Recover this site server using an existing backup’ and direct the path to ….\PS1Backup\SiteServer folder and also ‘Recover the Site database using the backup set at the following location and set the path to…\PS1Backup\SiteDBServer or select ‘Use a site database that has been manually recovered’ option?
4.) In step7 you mentioned to use SQL server not WID when installing WSUS. If I have already used WID, would that cause a problem?
5.) If SQL server and WSUS is already installed in the new server before it was renamed to match the old server, would renaming the new server cause any problems with SQL or WSUS? And would I have to uninstall and reinstall SQL and WSUS after I change the server name?
Once I restore SCCM to 1606 on SQL 2014 on new server, I am planning to upgrade SQL to SQL2016 and then SCCM to 1802.
Sorry to asking you number of questions. But I hope you could clarify the above as you have done so far in the main article
Thanks
Mari
Sorry, late reply here.
1. No, hostname must be the same. Why does it matter?
2. You need to use setup from cd.latest. Nothing else is supported. This ensures that the version you are installing exactly matches the version the backup is from.
3. Depends on how you performed the restore. I generally prefer manually restoring the DB from SQL Management Studio and then choosing the existing backup option.
4. WID just doesn’t handle resources or scale as well as SQL Server. Given the multitude of issues folks have had with WSUS catalog bloat over the past 2.5 years, every little bit of performance increase is a very good thing.
5. Yes. Search the web for what to do — it’s just a single stored procedure to run within SQL Server to tell it that the hostname has changed.
You might want to add one more thing to your list of things to do. Make sure you have a backup of your configuration.mof if you have custom hardware inventory items. This will be included in your site system backup but I always like to be sure I have an extra current copy somewhere.
Hi Jason, i am going to follow your guide to upgrade all our SCCM servers OS to 2016. Currently we have 2008s which are only DP’s and 2012s which are DPs. SS. SQL, Remote SUP etc, going to backup and restore the site.
My question is regarding 2 servers, a remote sup and second one with roles – SUP, MP and cloud management gateway. As the WSUS admin console should be of same version as WSUS on remote SUP, how and when do i restore SUP. For MP and CMG, can i just uninstall and reinstall on the new server (new server will have the same name). Thanks
There is no direct restore for the SUP role itself. The common practice is to remove the SUP role and WSUS making sure to leave the SUSDB in place. You can then either upgrade the OS in-place on that site system and reinstall WSUS or install WSUS on another system already running Server 2016. In both cases, make sure to use the same SUSDB. From there, you can simply add the SUP role to this system. As a side note, if you are using WID to host SUSDB, now’s a great time to move that to SQL Server. For the MP, yes, at most just remove and re-add. Not sure about CMG as I haven’t done that yet but I expect so.
Hi Jason, great Article!
I made the reinstallation of the site server correctly.
But, there are an post installation task with certificates on the new server? Because I have troubles with the client notification.
Thanks!
Hi Francisco. Client notification doesn’t explicitly depend on any certificates — why do you suspect a certificate issue?. Have you reviewed the client notification logs on the site server and the client: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/log-files#BKMK_BGB?
Hi jason, Thank you very much for you reply.
I read a lot of logs with problems about certificates issues and the comunication with clients.
But the issue is resolved, giving the proper permissions on system management the thing works correctly. (Service and Computer account full control on system management, but no in all descendant objects, changing that works!)
Thanks again
Francisco
Just one thing I want to verify which I didn’t see a step for is copying all of you data over to the new server drive letters (which should be the same drive letters)
Hi Jose,
Not sure what data you are referring to here. Steps 8, 9 and 10 list the relevant “data” that is required. Is there something else that you are referring to specifically?
Hi Jason, great article. I noticed that you created the WSUS DB from afresh without restoring it. I guess a WSUS DB could gather all kinds of unnecessary items over the years and a clean start would be best.
My question is, can you think of any scenarios where restoring the old WSUS DB on the new server would be advantageous?
Time and speed to be fully operational are the only advantages to my knowledge as re-downloading and syncing the catalog to ConfigMgr initially takes a while — anywhere from 30 minutes to several hours IME based of a few different variables like bandwidth to the Internet.
will the previosly created SUP, ADR, deployment packages stay after wsus db and sup role is uninstalled and reinstalled?
Yes. Those objects are not linked in any way to the SUP or WSUS and are ConfigMgr objects.
Thank you for the reply regarding restoring the WSUS DB. I am looking at building a new primary site server with a new OS using site restore. The environment in question has a remote SQL server. Therefore would the only difference in the process be, rather than choosing ‘Select the database option for a manually restored database.’
would you choose ‘Skip database recovery’?
Assuming I do the backup/restore with primary site (2008r2 1606 -> 2016), what do I do to upgrade the OS of secondary sites (MP, SUP, DP) ? Do I follow the same process ?
No, the backup and restore of secondary sites is unsupported. Deploying net new systems is really the only path for secondary site servers. Using content pre-staging you can preserve content at the remote location to minimize WAN traffic associated with content redistribution. I would strongly consider converting them to simple DPs though (you can still use content pre-staging to minimize WAN traffic).
Our company is currently looking at a hybrid migration to AWS via CloudEndure… but actually performing a clone. The concept is to build an AWS instance (via CloudEndure) that would be designated as a secondary site server, with the on-prem server still acting as primary. Then crossing over from on-prem to AWS, where the AWS instance eventually becomes the primary SS. The instance built in AWS would have a different name than the current on-prem server that’s being cloned.
Different from a true migration via CloudEndure. I can’t debate the advantages of one vs the other, and not really here to get into that conversation. But I’m curious to see if anyone else has gone through a similar type of SCCM move to the cloud. Looking for specifics on what needs to be changed/checked/considered. Any help or experience would be appreciated!
First, note that “secondary” has a specific meaning within ConfigMgr, a “secondary site”. That is not what you are referring to here at all so I strongly suggest that you don’t use the word “secondary”.
Next, cloning systems in a Windows world is a terrible practice. There are far too many unique identifiers that will cause you issues and of course, it’s completely unsupported.
What is your actual goal here? High Availability, moving the site server to AWS, something else?
Hi, just fyi, the link behind “Custom reports: How to Download All Your SSRS Report Definitions (RDL files) Using PowerShell.” is now a phishing site
Well that sucks. Thank you for the heads up. I found a new one and updated the page.
I’m planning on migrating my primary site to a new server soon and noticed you say new server needs the same volumes. How strict is this? My existing site server only has C: and D: as SQL is currently remote but I plan to move that to the new server which involves adding 3 more volumes. Also, ConfigMgr is installed to C: at the moment and I’d like to use c:\NO_SMS_ON_DRIVE.SMS, will that break it?
I think you can move things around, but I’ve never actually tried. Test, test, test.
Hi Jason,
Thanks for another solid post. Yours is one of my go-to sites for SCCM info.
I have a few questions that I hope you can answer:
– I’ve seen several people (including you, I believe) stating that a restore from a snapshot is something to avoid at all costs.
Would restoring the site server from a proper backup work? Ie. restoring the VM and then restoring the DB from a designated SQL DB backup? Or is a new, clean server the way to go (and then restore the backup onto that and install SCCM and do a site recovery)?
– If creating a new server is the way to go, how can I properly do a restore test – I can’t use the real servername and IP-address, since they are in use on the real server that is still spinning.
I hope it makes sense. Thanks in advance.
Br.
A
As long as you are restoring the site per the documented path, then yes, this would be fully supported. Restoring the entire server from a backup would be a bit tricky though as you’d have uninstall the site after the restore which would have other ramifications. I would definitely recommend using a new, clean OS instance. As for testing a restore, yes, this is tricky. IP address is irrelevant but you’ll have to restore to an isolated environment where you’ve cloned the domain.
Wow very helpful