Migrate Data from FNMS 2017R3 to new FNMS 2019 (not upgrade)

[ImIronMan]

Hello Experts,

We have an instance of FNMS 2017 R3 with 1500+ licenses created and 9500+ purchases already being managed.

Customer doesn't want to upgrade the existing 2017 R3 but wants to implement FNMS 2019 R1 as a fresh installation on a new server setup with new hostnames.

In this case, how can we get all the licenses (with PURs configured), purchases, contracts..etc., imported to new FNMS 2019 R1 with out any issues and with out recreating licenses and reprocessing PO's ? What is the best way to achieve this?

I'm guessing that the "database migration" may be crucial in this case, so first install new FNMS 2017 R3 using restored existing FNMS 2017 R3 database on whole new setup and then upgrade this to 2019 R1, but I'm not sure if it can bring all licenses/PO's..etc., in GUI with out any issues.

Regards

Rajesh Ponnala

[mgunnels1]

Good Morning,

I would …

1. Back up the existing datawarehouse and fnmscompliance databases and restore to the new SQL environment.
2. Build out the remaining databases fresh. (contentstore, fnmsinventory , snapshot)
3. Upgrade the restored databases to 2019 R1.
4. Update the complianceconnection table to point to the correct FNMSinventory and Datawarehouse databases)
5. Update the compliancesettings table and change the batchschedulerhostname to the correct server.
6. Install the required software
7. Run the configuration scripts

Optionally to remove old inventory

1. Delete the 3^rd party inventory sources from data inputs. This will delete the associated inventory.

[ImIronMan]

@mgunnels1 

Thanks for your response. Can you please guide me how to do the following.  Can you please share any SQL query or steps to achieve

1. Update the complianceconnection table to point to the correct FNMSinventory and Datawarehouse databases)
2. Update the compliancesettings table and change the batchschedulerhostname to the correct server.

I'm hoping that if we follow the above all steps as you mentioned, all the licenses (including custom metrics), PO's (processed & unprocessed) will be imported to FNMS GUI with out any additional work. Agree ?

[mgunnels]

Good Morning,

Attached is a sample script for updating the FNMScompliance database when moving to a new location.

(Always test a script on a development environment prior to running in production.)

This process will not modify the configuration of purchase orders or licenses.

[ImIronMan]

@mgunnels,

Does this script works for both below points
1. Update the complianceconnection table to point to the correct FNMSinventory and Datawarehouse databases)
2. Update the compliancesettings table and change the batchschedulerhostname to the correct server.

[mfranz]

This is exactly how I would proceed in this case. @ImIronMan please consider marking the original answer as solution.
Another thing to consider: If FNMS agents are used widely, you may want to plan ahead to let them know about the new beacon/server in time. Some options would be:

• Manually inserting the new beacon location to the beacon table to have it automatically pushed to all agents.
• Or leave a beacon in the old location, pointing to the new environment until all agents are aware, then removing it.

[ImIronMan]

Thank you @mfranz,
Final question can you give me some details on the point mentioned - "Manually inserting the new beacon location to the beacon table to have it automatically pushed to all agents."
I'm guessing to push the new config file with updated beacon server URL through sccm for windows, and manual uninstall/install new agents for non-windows. But its painful. Can you please let me know whats the best way to direct all the existing agents to new environment/new beacons

[DAWN]

Before you perform the "upgrade" - turn off the scheduled tasks on your beacon and stop all services and IIS on your existing app server (this should "keep" the files on your beacon for agents reporting in during the mean time). Once the new environment is configured, reconfigure you EXISTING beacon to point to the new App Server. As agents check in, they will get the new policy, including the new beacon. Once you're sure the policy has been captured, you can take down the old beacon server if desired. This means you don't need to re-deploy any agents on the clients.

[mfranz]

The table "Beacon" contains all registered beacons. From it the download an reporting locations are regularly upddated to the config files on the beacons. Once the info is on the beacon, agents polling new settings will receive the data as well. What you could do, is manually insert beacon details, although the new beacon isn't operational yet. Once it goes live, agents should already know it. It definitely is a process and you should plan some time for it, possibly do a test beforehand.

[ImIronMan]

@mgunnels 

@ChrisG @mfranz  @mgunnels1 @DAWN 

Hi All,

We have migrated succesfully from FNMS 2017R3 (tier 1)to 2019R1 (tier 3)as discussed in this post.

After the migration, every thing looked good and as expected on day 1.

However, on day 2 - We observed below issues

1. Inventory import task is failing with error “Failed to import inventory devices with error message 'Conversion failed when converting the nvarchar value 'cpuPackage' to data type int.'    
2. Since above inventory import failing, recon is not working.
3. “VMWare Inventory” page is not loading at all.
4.  CLusters count got reduced from 200+ to 66 and hence the VM Host, VMs as well
5. “Oracle instances” report showing 0 instances, down from around 200 records
6. Subnets got unassigned from beacon automatically. On day 1, we have assigned around 3500 subnets from old beacon new beacon and all VCenter rules, SCCM integration ran perfectly. But on day 2,    1100 subnets got unassinged and over all subnet count got reduced to 2000 only.

We have raised a case (Case #01934832), however, the issue is very critical , need your urgent support/guidence

[winvarma]

Hi @ rajeshponnala,
Hope all your issues were sorted and could you please share your experiences and hurdles you came across during upgrade from 2017 R3 to 2019 and the approach you took as we are planning to upgrade 2018R2 to 2019R2.3/2020 R1 onprem in the next 3 months I have to start planning for the same.
Will have to take Ur steps as well from the procedures suggested by other forum members, to avoid the issues you faced.

Regards

[ChrisG]

For cross referencing, some of the discussion here about how to work with the database and update details it contains is similar to discussion in the following thread: FNMS 2018 R1 - Cloning Prod to Dev