SAP BusinessObjects Migrating from Windows 2012 to Windows 2019 Unconventional Method

[former_member294032]

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!

[Joe_Peters]

I have done this in the past successfully, except that we did not move the CMS database. So you really are doing two independent things (moving the CMS and moving BO); moving the database is a more typical operation, but your approach to adding the new nodes should not be problematic.

One thing to be aware of, though. If you have clients that connect to your cluster by cluster name (ex., IDT or UDT), then they will need to become aware of the the new servers. There's a couple of ways this can happen. Once the new servers have been installed and connected to the CMS, a successful connection to the cluster will return the new servers' info to the client, even if the new servers are stopped. Subsequent connections to the cluster from the client will go to any of the live servers. For example:

1. BO software installed on new Win19 server
2. New BO CMS connects to CMS database, adds its info
3. New server is shut down
4. UDT client connects to cluster (old server)
5. Old server provides updated CMS node list to client, including new server
6. Old server is stopped, new server is started
7. UDT client is started. UDT is aware of both old and new servers. It chooses a node at random. If it chooses the old server, which is stopped, then it will connect to the new server instead.
8. SIA on old server is uninstalled; during uninstallation, installer connects to CMS database and removes references to node
9. UDT connects to cluster (new server), and downloads updated node list, which does not include old server.

Here's where you can have a problem:

1. BO software installed on new Win19 server
2. New BO CMS connects to CMS database, adds its info
3. New server is shut down
4. SIA on old server is uninstalled, and node is removed from CMS database. CMS database now only contains a reference to the new server
5. New server is started
6. UDT attempts to connect to cluster. It's only aware of the old server, and so the connection fails.
7. To rectify: Instead of using cluster name in UDT, you use the host name of the new server
8. UDT connects to new host, finds that it is a member of a known cluster, downloads and updates the node list
9. On next connection with UDT, using cluster name, UDT successfully connects to new server

[former_member294032]

Thank you for responding to my post. Yes, I will need to get all of our developers that use the IDT and/or UDT to login to the new copied environment by using the new system name of one of our new CMS servers. As far as BI Launchpad goes: I have the various .properties files (BIlaunchpad.properties, PlatformServices.properties etc.) in the D:\SAP BusinessObjects\tomcat\webapps\BOE\WEB-INF\config\custom directory set to reflect the new server/system names for the default CMS entry (I also have the .properties in the warfiles directories). Thanks!

[JohnClark]

We did something very similar a couple of years ago except that our server OS was the same. I think this is much less critical than making sure that the version of Business Objects is the same for all installs.

In our case we were moving our installation from one data center to another. I built out the new system in the remote data center, this included a re-architecture of the Business Objects environment from four single stack servers to a eight node distributed installation. Ours was a little different in that we had to move our database and file store directory as well but that was handled very well with replication.

We shut down our old servers, waited for the replication to get caught up and the environment URL to be updated and then brought up the new servers. Took about 30 minutes of down time.

I removed the old nodes. I did this from the new environment. I think you should be able to remove your old 2012 nodes from the CCM on the 2019 servers.

[former_member294032]

I'm thinking it should work as well. Thanks for answering my post. I'll have to weigh some options.

[DellSC]

You'll want to do this in several steps.

1. Move the CMS and Audit databases. You'll have to manually move the Audit db, but you can use the CCM to copy the CMS data over.

2. Install the BOBJ software on the new Windows 2019 servers, joining the same cluster as your existing servers. Once you have everything installed and the servers configured, you can configure the cluster on Tomcat to include only the new servers. TEST!

3. Go to each of the old servers and run the CCM. Stop the SIA on the server and remove it through the CCM. Once the SIA is removed, the server can be stopped.

-Dell

[former_member294032]

Thank you very much for taking the time to answer my post. However, I'm wondering why my method won't work. I already have the Win 2019 servers attached to the existing cluster They're just not running right now. Although, I did have a report successfully run on a 2019 server in the cluster and had a CMC session hosted by a 2019 server in the cluster as well. Not thorough testing but I did see that it worked. Is using the CCM to copy the CMS doing something differently than just performing a manual copy? It seems like in the end I'm using the CCM to remove the old Win 2012 servers in both cases. Also, either way I'm adding new servers to an existing cluster and then not using the old servers anymore. I'll also need to copy the FRS Input and Output directories (2.7 GB and 270 GB).

If I decide to use the CCM to copy the CMS: Do you think it will be okay to remove the 2019 servers via the CCM, perform the CCM CMS copy and then add those same Win 2019 servers that I just removed via the CCM? Or, do I need to get new servers created with different names?

[DellSC]

Sorry, I didn't catch that the servers were already installed. At this point you can either use the CCM and copy the database over then remove the W2012 servers or remove the servers and then copy the database. Either way will work.

-Dell