A customer plans to have FNMS implemented to an Azure VM. While I have talked to some people having tested this successfully, I am not so sure about the Database as a Service thing.
Does anyone have experience with this? Has anyone implemented FNMS using such databases? Are there additional things to consider, compared to a locally managed MS SQL DB?
Jun 05, 2019 09:21 AM
You can absolutely run FlexNet Manager in a public cloud environment Like AWS or Azure; Flexera has in fact a number of customers doing so.
Just note that the integrated database services like AWS RDS are currently not supported - think of the cloud based installation as something that uses the cloud infrastructure in the same way it would use a virtual data centre.
The only thing that is important is connectivity and access to the relevant infrastructure within the client's local networks.
Jun 05, 2019 09:29 AM
Hi @mfranz ,
The most tangible blocker (that I've encountered anyway) to a Flexera recognising support for SQL aaS environments is the requirement for Common Language Runtime (CLR) support which by default is disabled for such environments.
As of FNMS 2019 R1 - the feedback I received from Flexera was that it was not a supported configuration and that they did not have access to such environments within QA cycles to properly conduct full testing so it's not something that they can claim support (yet) for FNMS.
Having said that - I am aware of some successes (in POC's for example) that have made it work by using cloud provider configuration to enable CLR integration - but understandably Flexera cannot claim full product support until they complete their due diligence/QA.
Jun 05, 2019 10:20 AM
Very good point, I totally missed CLR. From what I found online, CLR is supported, but only from Binary, not from file.
The FNMS CLR assemblies comming in a file (SqlProceduresClr.dll), makes me think this is not gonna work.
Maybe a Flexera engineer can comment on this.
Jun 06, 2019 02:27 AM
Hi @mfranz ,
I personally have not tried this with Azure, however the way the FNMS database creation/migration tool works is by turning the DLL into a SQL command with binary blob and running that on the SQL Server you point it towards. It does not write this SQL to a file - while it could easily do this, the file could possibly get out of sync with the source DLL and you could be unsure whether the correct version was applied. This way you just replace the DLL, run the creation/migration tool and can be sure it worked.
Now if for some reason it isn't a typical database creation or migration scenario (I'm guessing that this is the case here) then if you take out all the steps everything except the CLR step from ComplianceMigration.xml....
<?xml version="1.0" encoding="utf-8"?> <UpdateSteps productname="FlexNet Manager Platform" requiredclr="true"> <SQL stepname="Update SqlProceduresClr.dll" stepnumber="100" requiredversion="13.2" mindbcompatabilitylevel="100" testobjectowners="true"> <VersionSQL><![CDATA[ SELECT (SELECT Value FROM dbo.DatabaseConfiguration WHERE Property = 'CMSchemaVersion') AS MajorVersion, (SELECT Value FROM dbo.DatabaseConfiguration WHERE Property = 'CMSchemaVersionMinor') AS MinorVersion, (SELECT Value FROM dbo.DatabaseConfiguration WHERE Property = 'MigrationStep') AS MigrationStep ]]></VersionSQL> <SQLFiles> <file stepnumber="1" filename="SqlProceduresClr.dll" assemblyname="SqlProceduresClr" /> </SQLFiles> </SQL> </UpdateSteps>
...and fix the version check to whatever your current version of FNMS is, then in theory this should work. Please be aware this hasn't been tested on Azure - there may be further obstacles - but would be good to hear about the outcome.
Sep 19, 2019 06:59 AM