Question About Upgrading

[mfeinman]

Hi all ...

My company is planning an upgrade of FNMS from 2019R1 to 2022R1.

The plan is to spin up all new servers for FNMS 2022 (application server, database server, beacons) to get onto a more recent version of Windows Server and to also get faster hardware.

Since mistakes "on paper" are cheap, we’d like to get the upgrade plan as accurate as possible “on paper” before we begin the process.

The high level plan goes something like this:

• Create new database server
• Spin up new beacon servers and ready them for installing beacon services
• Spin up application server and ensure all pre-reqs for FNMS are met
• Take a backup of all FNMS databases
• Restore the FNMS databases to the new database server
• Check database constraints
• Upgrade the databases on the new database server using the Flexera PowerShell scripts
• Install FNMS on application server
• Check FNMS for proper operation and that existing data from the upgraded databases can be seen, including the old Beacon configurations
• Deploy new beacon servers
• Tell existing agents to use the new beacon servers instead of the old ones

I've read the Upgrade On Prem guide from cover to cover.  I still have questions regarding the deployment of the new beacon servers and the transfer of inventory data from existing agents to the new beacon servers.

For my questions, let's assume my FNMS infrastructure is a single application server W, a database server X, and 2 inventory beacons Y and Z.

Let's further assume that my new FNMS infrastructure will be also be a single application server A, a database server B and 2 inventory beacons C & D.

Q1:  After I copy and migrate the databases onto new server B, what part of the upgrade process changes the migrated data to point to the new infrastructure?  Is it the running of .\Config.ps1 "Config\FNMS Windows Authentication Config.xml" forceUpdateConfig?

Q2:  When the new infrastructure is up, the old beacon servers Y and Z will still have the subnets assigned to them, but beacons Y and Z are not going to report into the new application server A.  To reassign the subnets to the new beacons C & D, is it “simply” a matter of going to an old beacon in the list, removing all the subnets on the old beacon (making them unassigned), then assigning these unassigned subnets to the new beacon?  Then we would delete the old beacon from the list?

Q3:  We also have FNMS agents already deployed using "third party inventory".  Up until this migration, they would have received updated policy from inventory beacons Y and Z.  How are these agents told that they are to report into one of the new beacons C & D; that is, how do they get a new policy with the new beacon details?  Would I have to push a new agent to these servers with a new initialization file?   (I'd eventually be pushing a new agent to these servers anyway as a later step in the upgrade, but I presume there's a way for the existing agent to be told to report to the new beacon servers without having to update the agent.)  Also, does the agent installer support an upgrade in place or do I have to delete the old agent first and then install the new one?

I'm fairly new at this so I hope my questions are clear.

Appreciate any and all advice you can provide.  Thank you!

[mag00_75]

For an easy switch for all agents, I recommend to create DNS alias for all beacons. In the beacon configuration xml file you can also set that the beacons should use the dns alias instead of a-record.

For this to work with https in a good manor, then the certificates also need to have the alias.

Then wait until agents update their policy.
Then you can easily switch all agents towards the new infrastructure pointing the aliases to the new servers

[mfeinman]

Your reply got me thinking - maybe I should better leverage what I already have.

Using my example scenario above, what if I temporarily kept my existing beacons while I spun up new ones.  The flow would be like this after the new FNMS server was stood up:

• Open the Beacon UI on beacons Y and Z and modify the parent connections to point to the new FNMS server and test the connection. This would add the existing beacons to the new FNMS server.
• Spin up new Beacon servers C & D, so temporarily, I'd have 4 beacon servers.  The new ones would be added to the failover list, and this would flow down to all the agents through a policy change (because I added 2 beacons).  Allow some time to pass to make sure a majority of the agents get the new policy / failover list.  Some agents will connect to the new Beacons and some to the old ones, but at this point, that's fine.
• Delete old Beacon servers Y & Z from the FNMS configuration.  The failover list would change once again to have only the new Beacon servers C & D.  This policy change would also flow down to the agents.
• Agents that originally made their last connection to the older Beacon servers Y & Z would no longer see them in the available Beacons list and try to connect to the new Beacons C & D.

What are your thoughts about this approach?  I think it avoids the need to alter SSL certificates to include the DNS alias, right?

[mfranz]

A1: Yes, you'll need to run the config (forceUpdateConfig) and enter all the new variables in the process. Be aware that Compliance Connection details are not automatically updated, you'll have to do this for the FNMPDataWarehouse & FlexNet Manager Suite connections.

A2: I guess you could try that. Maybe you can just delete the old Beacons and assign the subnets to the new ones? Not sure if the WebUI will let you do that.

A3: Migrating agents to a new environment, I believe, has repeatedly been discussed in the forum. Typical approaches are:

• Promoting new Beacons in the old environment while it still runs, giving it enough time so that all clients have that information by the time the new env is up and old Beacons go down.
• DNS alias, as mentioned
• Registering the old Beacons in the new environment, so they become part of the new architecture, at least until all clients have communicated once and have all the details. Then later remove the old Beacons.
• Re-deploy agents with new beacon details. Makes sense if you have a well-working deployment tool.

[mfeinman]

@mfranz , @mag00_75  thank you both for your responses!