Failing over the SCCM Primary site to a new server

[Angersma]

We are installing the Passive Site Server role on a new server and will be failing over to this server soon, to move our Primary to a new server with a newer OS.  

The new server will have a provider installed locally ahead of time.     We were going to install the ESD App Pool ahead of time on this new server as well, and then update the value of  Admin -> Site Management -> Settings -> Deployment -> ConfigMan -> Central Site Server to the new server once we fail over the site server role.   .   

Any concerns having the App Pool installed and ready/waiting ahead of time? 

Are there any other places (like .config files) that will need to be updated as well?   

Can the changes above be completed ahead of time, before we fail over the site server role to the passive server, as long as the provider and CM Admin Console is installed on the server when we make the change?  

Thanks!

[CharlesW · Accepted solution]

One thing you certainly would have to do would be to update the Server column WD_SiteToAdvert table, to reflect the new server. The ESD Service uses the Server column to determine where the ESD Web Service is (for collection inserts and cleans. 

One think that "might" cause problems, is if you have a SMS Provider that is showing as installed, but the provider is not responsive.. The ESD Web Service does not check to see if a provider is responsive, it just tries to use the provider it finds. It will use either the first, or the last provider (depending on the operation)  returned by the following WMI call:

get-wmiobject -Class "SMS_ProviderLocation"-namespace root\sms

More specifically, where ProviderForLocalSite = True

As long as these providers are responding, then you will have no problems. Where you run into problems is when there is a provider showing up which is not responsive, or having issues. Typically the only think you can do is to remove the provider which is not responding, or resolve the issue on the provider. We should be improving this (hopefully soon), where the provider will be tested prior to use.. If not responsive, then App Broker would move on to the next provider in the list.

Beyond that, all you should need to do is update the deployment settings under the admin site.

[Angersma]

Thank you!    

And thanks for the info about how it determines which provider to use.  We plan to remove the provider off our current Primary when we fail over, and before we decomm the server, so we should be good there.   These mechanics are helpful to know though, thanks!