Upgrading 2018 R1 to 2019 R2

[patrick_quinla]

We are planning to upgrade FNMS from 2018 R1 to 2019 R2. In reading the 'Upgrading FlexNet Manager Suite to 2019 R2 On-Premises' manual, a lot of it seems to refer to migrating the databases. 

Is this a necessary step in order to upgrade? I feel like the manual is very difficult to follow the way that it is written. Does there happen to be a step-by-step guide anywhere?

[ChrisG]

Upgrading the database is indeed a necessary step during the upgrade.

There are a number of steps needed to complete an upgrade, and a wide range of possible considerations–the Upgrade Guide that you have found seeks to be comprehensive enough to cover most possible considerations, but it does mean that you need to know your scenario and environment well enough to work out how to apply the guidance to your situation.

I would always recommend that you look to work with somebody who is familiar with installing and upgrading FlexNet Manager Suite when going through an upgrade to help the process go as smoothly as possible. If you are really keen to do it yourself, some tips would be:

• Complete appropriate training. Some possible content in the Flexera Learning Center that may be useful is:
• FlexNet Manager Suite Technical Install & Admin Class (be confident you are competent at installing FlexNet Manager Suite before attempting an upgrade)
• Upgrading FlexNet Manager Suite On-Premises learning lab
• Upgrading FlexNet Manager Suite On-Premises slide deck (this is content about upgrading to old releases, but much of it is still pertinent)

NB. You will need to be logged in to Flexera Community as an active customer or partner to have access to this content.

• Learn about the upgrade process by doing a comprehensive upgrade in a dev/test environment before touching production.
  
  
• Do a dry run of migrating your production database to identify and work through resolution of any problems before doing the live migration. If there are problems, it can take some time to work through them, and you likely won’t want to do that during your live production outage window.

Also see the following current thread which is also discussing upgrade matters: Upgrading from 2017 R3 to 2019 R2

[adrian_ritz1]

Hi @patrick_quinla ,

I did a lot of upgrade from version to version, here are the steps that I take:

Announce the customer and block a few hours to perform the tasks, to upgrade from 2018 R2 to 2019 R2 can take some time, depend on how big is your implementation.

All installations that I do are under service account and logged on server as local admin

I will try to put here the upgrade procedure step by step.

Check if you don't have some running tasks with BatchProcessTaskConsole.exe list-tasks

If you have running tasks there please wait till it's finished

Stop all flexera services on app server

Stop IIS

Stop all scheduled tasks from schedule task manager

Now you need to perform database migration:

Go to SQL server and run the following command:

mgsDatabaseupdate.exe -i ComplianceMigration.xml -nsu -s SQL_server\SQL_instance -d FNMP

mgsDatabaseupdate.exe -i InventoryManagerMigration.xml -nsu -s SQL_server\SQL_instance -d IM

mgsDatabaseupdate.exe -i DataWarehouseMigration.xml -nsu -s SQL_server\SQL_instance -d FNMPDataWarehouse​

If you have other database name, please modify them accordingly 

After you finished with database migration, go to app server and run the setup.exe from the flexera installation package, configure to fit your deployment, please be sure to check where is the actual installation on your server, if it's in standard location or not

Copy the powershell config file from  FlexNet Manager Suite Installer\FlexNet Manager Suite Installer\Support

to a folder like d:\temp\support 

Having a too long path name will generate errors during the installation.

After you copy the files:

open powershell and run following commands:

set-executionpolicy AllSigned

.\Config.ps1 "Config\FNMS Windows Authentication Config.xml"

Now if every thing had gone smooth you should have the new version installed.

Check if all scheduled tasks are enabled and check flexera services if they are started and running. 

I hope I didn't forget some steps in the upgrade process.

Before you start is advisable to do a full database back-up

[patrick_quinla]

Thank your for your reply. The upgrade manual mentions the need to configure .NET and IIS. Is that necessary? I only ask because I didn't see it in your list.

[adrian_ritz1]

Hi @patrick_quinla ,

Configuring the IIS and .NET is needed only when you install the application, but as you want to perform an upgrade from 2018 R2 to 2019 R2 this steps are no longer needed. 

[jasonlu]

From memory, I think IIS needs to be on for part of the upgrade.
To block users from accessing the application, consider putting a firewall rule in place blocking all http/https, except for the FNMS instructure servers.

j

[adrian_ritz1]

Hi @jasonlu ,

To stop users accessing application, you simply stop the IIS, this of course if you don't have any other web application running on the same server. Using firewall rules to block communication is to much hustle. 

[jasonlu]

@adrian_ritz1, hi. But if the upgrade requires changing or setting something in IIS, then the web server needs to be on, therefore you can't do that.
Firewall rules inside in the Windows Server control panel are fairly easy (certainly don't mean putting in firewall rules on routers).

j

[adrian_ritz1]

Hi @jasonlu ,

You are right but the change to IIS if take place is done by powershell script, and this is the last task to be run.

1. Update database

2. Update application running setup.exe

3. Running powershell script

The powershell script is smart enough to check if IIS is running, and if it's not running he will start it, also he will start all services that are stopped during migration.

I personally prefer to not mess with OS around as in our environment the OS is managed by other teams. 

[FrankvH]

Hello,

Yesterday we executed these steps in our productive environement we went from  2018R1 to 2019R2. Only problems we have seen where around:

• Rights on DB level in principal you need DBO rights
• And our DB logfile run full. We set the DB to simple mode and enlarged the logfile

The good thing is you can rerun the script if something goes wrong.

Afterwards everything went well it just takes time.

Regards

Frank