Note: This is a long post.
BI Platform 4.2 Support Pack 9 Patch 3.
What is being used to get an existing MS SQLserver CMS database from its original location to a new empty MS SQLserver database so that old clustered Windows servers can stop being used and new Windows servers can be used in a cluster going forward? Is the tool being used for the CMS part just doing a copy of the database from one location to another or is additional processing and modification of the database occurring when being placed in the new location? So, what is being used and what is it doing?
In addition to that, would adding the new Windows servers (each with their new server names) to the "copied" CMS database be a process of doing an expanded install and using the existing encrypted cluster key during the install process? It seems like the result would be a CMS database that had some old Windows server names in it (but aren't being used anymore) and also containing the new Windows server names that are going to be used. Is there a problem with having those old Windows server names (that were originally in the cluster) in the CMS database if those servers are never going to be used again? Along the same lines, is it ok for the new Windows servers to run as a part of that cluster if they are going to be the only Windows servers used going forward?
The reason I have the two paragraphs above is this:
I need to get my BOE cluster off of Windows 2012 R2 and on to Windows 2019 server. I've opted to use an unconventional but simple approach: attach Windows 2019 BOE servers to the existing Windows 2012 cluster by using an expanded install and run *only* long enough to get them attached to the cluster and then stop the Win 2019 SIAs. (Please read this: I know running Windows 2012 CMS servers and Windows 2019 CMS servers at the same time does not work well together and the cms.exe's will interfere with one another). I added 2 Win 2019 CMS servers, 3 Win 2019 Job Servers and have a new Win 2019 server for the default tomcat web tier install.
The Windows 2019 servers are now attached to the cluster but not actively running. Only the Win 2012 servers are running. I configure the FRS Input and Output on my Win 2019 CMS servers to point to the correct directory share which will take place after they are started. I also configure the destination info for the Win 2019 Job Servers (which are also stopped and not running while the Win 2012 servers are running). I have the SIA on all Win 2019 servers set to disable so that nothing will try to run if the server is rebooted when I don't want it to be rebooted. I have the BOE components on those 2019 servers set to not auto start on SIA start as well. I will change this when I need to exclusively run the Win 2019 servers going forward.
When it's time to use the Win 2019 BOE servers and never use the Win 2012 servers anymore, I:
Stop the SIAs on all Win 2012 servers.
Start the SIAs on all Win 2019 servers.
Starting using the URL for the new Win 2019 tomcat server going forward.
To me, I feel that I'm basically done now except:
1. Should I just leave the CMS database alone at this point and let the CMS db think that there are Win 2012 servers in a cluster (that will never be running again)?
Or
2. Should I follow the process of removing the old Win 2012 nodes through each 2012 server's CCM? (I believe I should be able to do so since their SIA's are stopped and I now have a cms.exe running on two other Win 2019 servers).
Does anyone see any reason why this unconventional process wouldn't work? I keep thinking about it and can't think of any reasons yet. I've added servers to a cluster. Will stop some of the servers (permanently) and only use the others going forward. Servers running in the cluster will all be of the same OS version. The last time I did a migration (many years ago) I had to use a command line LCM_CLI tool because other migration methods wouldn't work and it was a struggle to get it completed. This seems like it should work. Please let me know.
Constructive input appreciated! Thanks!