Event banner
Event details
I have a Config Manager site installed on a physical server that is beginning to report hardware issues so I am working on migrating to a new Config Manager site in a VM. The old site is tenant attached, co-managed, and has a CMG. It has been suggested in various forums to deploy a script that will simply change the site code to the new site. I've done some preliminary testing and this seems to work, though various client logs such as policyagent show warnings concerning policies from the old site which I'd expect. My question is, is this a recommended method? Are there any "gotchas" in doing this? The new site isn't configured for the cloud yet (no tenant attach, co-mgmt, or CMG) and so I don't know if simply changing the site code on an endpoint will cause issues with it communicating with those components or other things that I haven't thought of.
Jason_Sandys
Microsoft
MicrosoftHi Michael,
The best path here is to do a "site" backup and restore. This will allow you to restore the site, as is, including all configuration to a new "server" (virtual or physical is irrelevant). This is completely transparent to the clients and thus requires no client-side changes (including site code) whatsoever. Here's a nice post that will help you understand what's involved (as this is essentially a disaster recovery scenario): https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/change-configuration-manager-site-server-os-disaster-recovery/ba-p/3765562
- I looked into this and found it worrisome since the hostname of the primary site server must not change which means completely taking down the old server. So if something goes wrong, there probably won't be an easy way to fall back. I have a question about doing this though. Do the sizes of the volumes of the new server need to match the sizes of the old? The old server has a volume several TB in size and I don't have the capacity to match that in the new VM environment. A number of forums that I read about this process have stated the volumes need to be the same size.
- Jason_SandysKind of. Yes, the server name must remain the same but that is easily managed as you can simply disable the ConfigMgr and SQL services on the old server and change its name. In this way, it can still be available on the network for file copies. In the case of needing to fallback, simply rename it back and reenable the services. Volumes do not have to be the same size but they probably need to be at least the same size as they are currently. You need perform some analysis to determine exactly what you need though and of course, in the VM world, expanding volumes is generally trivial. Capabilities like thin provisioning make this even easier as the volumes can be sized as large as ever anticipate but the back-end storage is only actually allocated when needed. But, as noted noted, they don't need to be the same size. I suspect that what most forum posts are calling out is that if you don't make them the same size, you may quickly run into space issues or failures. Here's an additional resource in the form of a blog I wrote a while ago and is still accurate: https://call4cloud.nl/2017/06/configmgr-site-server-os-instance-change/