How do you respond to a support case via email? When responding to a support case via email, there are two things to remember, to ensure that your replies are going to the right place: The email should be directed to support@flexera.com The reply should be sent as a response to one of the emails previously generated by the support case, above the line starting with three octothorpe (#) symbols See below for an example email response to a support case: If the reply follows this pattern, then it will be readily visible to the support engineer in their case view: If the above steps are not followed then any emails to support@flexera.com will create a new case, using the subject line of the email as the subject of the new case. This creation of new duplicate cases can cause confusion and delays in our responses to the original case. Keeping everything contained within a single case allows us to avoid this problem and focus entirely on the issue at hand. Note: try to avoid CC-ing in support@flexera.com, as this will create a support case as a result (unless this is intentional!) ... View more

Scenario: You may wish to remove the current software usage data that is present within FlexNet Manager Suite – whether that is the raw usage displayed on Discovery & Inventory -> Raw Software Usage, or the ‘Last used date’ data that is present on some of your application records. As the approach described below involves direct database updates, we STRONGLY recommend that a full backup of the associated databases is taken before making any of the changes described below. Solution: Data that is displayed on the Raw Software Usage page in FNMS is a result of querying the SoftwareUsagePerWeek_MT table in the InventoryManager database. This contains all of the usage data that is collected by the FlexNet agent only. To start from a clean slate, this data can be completely removed by executing the SoftwareUsagePerWeekRemoveAll stored procedure as follows: EXEC dbo.SoftwareUsagePerWeekRemoveAll Note: by default, the Raw Software Usage page reports on the last 3 months of usage data. This data is considered obsolete when its age exceeds the number of weeks defined in the UsageDataObseletePeriod column in the DatabaseConfiguration table (default = 26) You may also wish to remove the usage data (‘Last used date’) from the Compliance database too. For example, if you are importing usage data from SCCM’s v_GS_CCM_RECENTLY_USED_APPS view via the SCCM connector, then this will bypass the InventoryManager database and go straight to the Compliance database. Usage data in the Compliance database is stored in the InstalledSoftwareUsageData_MT table. A similar stored procedure exists for removing all rows of data from this table. As always, take a full backup of the Compliance DB and consider the potential impact upon your license compliance position before executing the following SQL: EXEC dbo.InstalledSoftwareUsageDataRemoveAll Further information regarding all FNMS tables covered in this article can be found at the below Online Help links: https://docs.flexera.com/FlexNetManagerSuite2020R1/EN/Schema/index.html#SysRef/schema/InventoryManagerSchema/UsageTables/reference/SoftwareUsagePerWeek.html https://docs.flexera.com/FlexNetManagerSuite2020R1/EN/Schema/index.html#SysRef/schema/ComplianceSchema/Compliance.Logic.LicensingTables/reference/InstalledSoftwareUsageData.html (Note: this approach only applies to On-Premises implementations of FlexNet Manager Suite) ... View more

Problem: When attempting to launch the FlexNet Beacon UI, an ERROR similar to the following is presented both in the UI and within the BeaconEngine.log: [ERROR] Failed to load schedule summary from 'C:\ProgramData\Flexera Software\Beacon\schedule.xml' In the log, this is also typically followed by a WARN message similar to the following: [WARN] “Handling error that occurred during an IPC request: There is an error in XML document” Solution: These errors can occur as a result of intermittent network failures when the inventory beacon requests and downloads the relevant XML from the application server. For files that display a similar error, initiating a re-download of the impacted file will typically resolve the issue. Taking schedule.xml as an example: Rename the current schedule.xml file to schedule.xml.old Run services.msc Initiate a restart of the FlexNet Beacon Engine service Attempt to reopen the FlexNet Beacon UI This will initiate another download attempt of the schedule.xml, which should arrive without errors if the download goes uninterrupted. ... View more

When configuring an Action for a Discovery & Inventory Rule (under Discovery & Inventory Rules -> Actions tab), the default behaviour is for MgsIPScan to use a ping-sweep for gathering discovery data through a network scan. For clarity, this setting is pictured below:               However, we acknowledge that some customer environments may have ICMP disabled, which will naturally result in a failure for the ping-sweep. Please note the following optional registry key that can be created on the beacon server: Hive: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ManageSoft Corp\ManageSoft\Discovery\CurrentVersion] Name: DefaultPingSweepOptions Type: REG_SZ (String) Value: -PS The default value is -PI, which is not visible in the registry by default. Adding the key with value '-PS' will amend the network scan behaviour from a ping-sweep, to a TCP SYN/ACK scan. Please take note of the following: 1) Adding this registry key and changing the value will affect ALL rules that utilise a network scan that are being executed from this beacon. 2) The modified TCP SYN/ACK approach will slow down the port scanning process as a result Further information on the 'DefaultPingSweepOptions' registry key is available at the following link: https://docs.flexera.com/fnms/EN/WebHelp/index.html#reference/FIB-Registry.html ... View more