craig_moore asked a question.
Craig,
Make sure you back up the FNMSCompliance, FNMSInventory, FNMSDataWarehouse databases from your production. Restore to your Dev SQL server.
Populate your server information in this script. Run the .\config.ps1 "config\FNMS Windows Authentication" forceupdateconfig script that came with your install files.
After that double check your Registry on the App server that has the batch processor. See if this has your Dev server information. HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Reporter\CurrentVersion
I have personally used the exact document @steven_donovan1 has attached in his reply to do just that. The same process can also be applied if you're migrating your FNMS Production system to a completely new environment / servers with different hostnames.
A few other points to consider in addition to @steven_donovan1 's comments about running the Config.ps1 script (and more) are:
I know this is a crazy idea, but wouldn't it be awesome to build an adapter that will be able to periodically copy all of the key tables from one environment to another, without overwriting the configuration data and beacons - kind of make it seemless. Just sayin.
Hello @ChrisG (Flexera Software) ,
Regaridng the update -
If Prod operator accounts cannot be used in the Dev environment (for example, because operator's user accounts are from different domains), you can force an operator account to be created for a user and granted FlexNet Administrator rights by connecting to the compliance database in SQL Management Studio as that user and executing the following SQL statement:
EXEC dbo.GrantCurrentOperatorFullAccess
when I am trying to give access to that user from FNMS UI, user is not able to login and getting stuck in loop (login popup), however when I logged in to SQL server with that user and executed -
EXEC dbo.GrantCurrentOperatorFullAccess on compliance DB, that user was able to access FNMS UI.
How can we fix this FNMS UI issue ? as only the service account used in application deployment (during migration process) can access the FNMS UI any other account to which access was provisioned from FNMS UI is not able to login.
Thanks,
Awadh
You Delete the beacons from the old Environment and load the new ones for that environment.
A few other points to consider in addition to @steven_donovan1 's comments about running the Config.ps1 script (and more) are:
- Review other inventory source connection details for anything which may be inappropriate to keep in place after cloning the database to a new environment. For example, you may have a Dev SCCM database to import from instead of the Prod SCCM database. In this case, delete the existing Prod inventory source connection and create a new connection to the Dev source. In particular, do not change the details of the existing connection to point to a different database: FlexNet assumes that the existing connection details will always point to the same source data which may change over time but will not gracefully handle things if you change the connection details to point to entirely different source data.
- If you are using a different FlexNet service account in Dev compared to Prod, ensure the Dev service account has db_owner rights on all the databases.
- If you have any beacons running in the Dev environment you will need to download and apply fresh configuration for them. You may also wish to use the FlexNet UI to delete information about any Prod beacons that are configured in the database.
- If Prod operator accounts cannot be used in the Dev environment (for example, because operator's user accounts are from different domains), you can force an operator account to be created for a user and granted FlexNet Administrator rights by connecting to the compliance database in SQL Management Studio as that user and executing the following SQL statement:
EXEC dbo.GrantCurrentOperatorFullAccess