If reconcile or other import tasks are stuck in progress for several days before timing out, or are not appearing in the System Task view, this is typically a symptom of FlexNet batch services not running correctly. Batch services rely on the connection to the FlexNet Manager Suite database, and reconcile tasks can get stuck when an interruption occurs in one or both service runs. The interruption can occur on the machine itself or due to connection issues with the FlexNet Manager Suite database if it's hosted on a separate server. Interruptions can also happen if the database goes down. Symptoms that may indicate you have this issue are: The scheduled tasks on the FlexNet Manager Suite batch server shows Import inventories and license reconcile tasks are running and completing daily but the reconcile is not running or not showing in the System Task view for several days. Certain tasks like SCCM or other third-party imports show in progress but never complete, eventually timing out. Expanding the task shows the Import into Staging step is pending, but it never starts. Clear the batch queue Before starting/restarting the services, it is best to clear the batch queue first so that multiple reconciles aren't queued and run consecutively. 1. Log on to the FlexNet Manager Suite batch server with the service account and open an elevated command prompt (right-click on Command Prompt > select Run as administrator). 2. In the command prompt, go to the FlexNet Manager Suite installation directory: Cd ‘C:\Program Files (x86)\Flexera Software\FlexNet Manager Platform\DotNet\bin\’ NOTE: You may need to change the path if FlexNet Manager Suite is installed on a different path or drive. 3. Check if there are queued tasks by entering the following command: BatchProcessTaskConsole list-tasks a. If the command returns no queued tasks, please proceed to step 5. b. If the command returns queued tasks, download and run the attached StopMultiTasksAuto.ps1 script to clear the queued tasks. 4. Run the command from step 3 again to verify that all tasks have cleared from the queue: BatchProcessTaskConsole.exe list-tasks NOTE: You may need to rerun the StopMultiTasksAuto.ps1 script a few times until all tasks have been cleared from the queue. 5. Once you have verified that all tasks are cleared from the queue, open Services.msc and start/restart the FlexNet Batch Processor and FlexNet Batch Scheduler services. 6. Trigger the reconcile manually from the UI or wait until the next scheduled reconcile run. ... View more

This article contains instructions and scripts that you can use to help mitigate the following known issue: Active Directory data may not be updated due to the import process for .actdir files timing out (or taking a long time) at the "Reconciling Computers" or "Reconciling Organizations" step (IOJ-2250105) Delete records of inactive computers in Active Directory Data pertaining to inactive computers in Active Directory should be deleted from the inventory database. Deleting a large number of computers can take a long time, potentially leading to database timeouts occurring while .actdir files containing Active Directory data are imported. Use the attached ManualComputerCleanupOnDN.sql script to manually delete computer data to mitigate this problem when it occurs. Ideally, pick a time to perform the following steps when no Active Directory data imports are running and when the inventory import process reading from the FlexNet Manager Suite inventory database is not running. Modify the distinguished name DC=x,DC=x,DC=x on line 2 in the ManualComputerCleanupOnDN.sql script to reflect the actual distinguished name of your domain. Execute the script using a tool such as SQL Management Studio. Be aware that this process can take a long time (hours or even days) to complete if there are many thousands of records to be deleted. The process can be safely canceled at any point and later restarted without losing work. Updated ReconcileComputers stored procedure The attached ReconcileComputers_NoBatch (2019R2 or later).sql file contains an update to the dbo.ReconcileComputers stored procedure that you can use with FlexNet Manager Suite 2019 R2 or later installations. This update can help reduce the chance of these issues occurring in the future once an initial manual cleanup is performed by changing the import process to delete records one at a time instead of in large batches. To apply the update: Take a backup of the dbo.ReconcileComputers stored procedure so that you can revert the changes if needed. Execute the ReconcileComputers_NoBatch (2019R2 or later).sql script against the inventory database. ... View more

Symptoms: You may start seeing Adobe Acrobat Reader DC freeware deployments being recognized as Adobe Acrobat DC Continuous or some form of commercial deployment in FNMS. Diagnosis: Recently, Adobe has made changes so that their Acrobat Reader DC (freeware) uses the same installer as the Acrobat DC (commercial) product, starting with the 64 bit installers.  This means that now the installer evidence is identical between the two products and the current evidence gathered is not enough to determine whether the installed product is the freeware or the commercial product. Because of this change by Adobe, FNMS is currently unable to differentiate between the freeware and commercial version of the product. Solution: Please refer to the following content blog post for the full details and remedy when using FNMS agent for inventory: https://community.flexera.com/t5/FlexNet-Manager-Content-Blog/Content-Change-Notification-Change-in-the-recognition-rules-for/ba-p/241358 Two recommendations have been provided in this scenario: If you do not have an Adobe Acrobat subscription, then it is ok to leave these installs as unlicensed in FNMS as the commercial component of the product cannot be used (Adobe enforces login to the portal to verify that the user has an active subscription to use the commercial version). Because of this, it should not be possible to be out of compliance as the commercial component of the product requires login. In order for FNMS to possibly be able to differentiate between the freeware and commercial version of the product again, enhancements need to be made on the FNMS agent to search for any other possible evidence on the device that can possibly identify the version (if such an evidence exist/is created by Adobe).  An idea has been opened in our Flexera Ideas system for this issue, which is linked below.  This is monitored directly by our product team, so please vote and comment with any additional details you may have: https://flexerasfdc.ideas.aha.io/ideas/FNMS-I-275   ... View more

Symptoms: The Batch processor relies on Microsoft MSMQ to function.  When FNMS is first configured, the private queues are created in MSMQ and the service account is provided full permission to these queues.  Therefore, if the service account changes at some point after, access to these queues could be lost.  This would then result in the Batch Processor not processing any queued tasks. Diagnosis: In order to check and verify if you are having permission issues with the private queues in MSMQ, logon as the FNMS service account to the FNMS batch server and check under private queue: Computer Management > Services and Applications > Message Queuing > Private Queues You should see 4 - 5 queues, if any or all of them show up as a red x symbol with an error message, and then please proceed to the Solution section to resolve the issue. Solution: If access has been lost due to a service account change, then you can logon as the old service account and provide permission to the new account by going to the view above and then right clicking each queue > Properties > Security tab to add the new account with full permission. If the old account is no longer accessible, there are two possible remedies: The powershell script attached will attempt to give full permission to the FNMS private queues to everyone in the Administrators group.  You can run the script as a local admin and ensure the service account is part of the group (or modify the script to give permission to another group that the service account belongs to). Alternatively, you can turn off the Windows MSMQ feature, reboot the machine, and then re-run the config.ps1 script, which will re-enable feature and assign full permission to service account provided to the script. ... View more

Symptoms: After performing a full applications export from FNMS to ServiceNow, there are missing installations in ServiceNow which exists in FNMS.  The applications do not exist in the staging table for ServiceNow, indicating that it was not brought in by the export from FNMS. Diagnosis: By default, the configuration for data transfers from FNMS to ServiceNow limits the number of records of each data type to be included in the transfer.  For applications export, this number is 10,000,000. The following Online Help article lists the default configured limit for data transfers between FNMS and ServiceNow https://docs.flexera.com/FlexNetManagerSuite2020R2/EN/InvAdapConn/index.html#adapters/ServiceNow/tasks/SNI-ConfigureFNMSExport.html To check whether you are running into this limit, the following query can be run against the FNMSCompliance database to get an estimate number of records to be exported: SELECT count(*) FROM( SELECT SoftwareTitleID, ComplianceComputerID, ComplianceHistoryTypeID, HistoryDate, ROW_NUMBER() OVER (PARTITION BY ComplianceComputerID, SoftwareTitleID ORDER BY HistoryDate DESC) AS RowRank FROM ComplianceHistory WHERE ComplianceComputerID IS NOT NULL AND SoftwareTitleID IS NOT NULL AND ComplianceHistoryTypeID IN (4, 5) ) AS hist WHERE hist.RowRank = 1 Solution: If it has been determined that you are running into the record limit, the value can be adjusted to allow additional rows to be exported.  The following steps will set the row limit for applications export to unlimited: 1.Navigate to the ServiceNow Export folder on the FNMS Application Server, which is by default at: C:\Program Files (x86)\Flexera Software\FlexNet Manager Platform\DotNet\bin\ServiceNowExport 2.Open the Export configuration file with notepad: fnmp_servicenow_export.exe.config 3.Change the maxRows limit to -1 for unlimited applications within the  <application /> node.   The following Online Help article discusses all the configuration options and defaults for fnmp_servicenow_export.exe.config file https://docs.flexera.com/FlexNetManagerSuite2020R2/EN/InvAdapConn/index.html#adapters/ServiceNow/tasks/SNI-ConfigureExport.html ... View more

Summary In the more recent versions of XenApp (7.9+), Citrix recommends using 3 separate databases including Logging, Monitoring, and Site. This article discusses support for this configuration. Symptoms In the more recent versions of XenApp/XenDesktop (7.9+), Citrix recommends using 3 separate databases including Logging, Monitoring, and Site. Support for this varies depending on the configuration and your version of FlexNet Manager Suite. FlexNet Manager Suite 2017 R1 and earlier The import on the beacon from the XenDesktop database(s) fails with the error ?Invalid object name ?chb_Config.Site?. You can workaround this problem by following the steps in the Resolution field to update the adapter XML files. FlexNet Manager Suite 2017 R2 and later This version has built-in support from importing from the XenDesktop database when all 3 databases are present on the same server. You should target the monitoring database when setting up the connection on the beacon. All versions If the 3 databases are being hosted on separate SQL Servers or separate instances, the import will fail. This is because the beacon needs to connect to the 'Site' database to retrieve the Citrix farm name, then the monitoring database to retrieve the data which is not currently supported. An enhancement is logged to add support for this which is being tracked with reference FNMS-63835. If you would like to request this feature please raise a support case and mention this reference number. In the meantime, it may be possible to workaround the issue using the steps in the Resolution field Cause Due to the update with the XenApp data storage the ?chb_Config.Site? table that is used in SQL queries is no longer in the same database that is used for retrieval of data needed by FNMS. Steps To Reproduce Install XenApp 7.12 with recommended 3 database configuration Open the Inventory Beacon and add a new inventory source with type 'Citrix XenApp (EdgeSight)' Specify connection information for XenApp database server and choose Citrix monitoring DB Try to run the import from this database Expected Result: Data imports successfully without any errors. Actual Result: In FNMS 2017 R1 and earlier, an error is received that states: "Invalid object name 'chb_Config.Site'. Resolution FlexNet Manager Suite 2017 R1 and earlier Updates are made to the SQL used in the 5 XML files included in the zip file attached to this article that allow the ComplianceReader to work in either the original single database solution or the new 3 separate database setup: \mgs\Compliance\Importer\Procedures\Reader\Citrix XenApp (EdgeSight)\InstallerEvidence.xml \mgs\Compliance\Importer\Procedures\Reader\Citrix XenApp (EdgeSight)\Setup_Computer.xml \mgs\Compliance\Importer\Procedures\Reader\Citrix XenApp (EdgeSight)\Setup_Evidence.xml \mgs\Compliance\Importer\Procedures\Reader\Citrix XenApp (EdgeSight)\Setup_Usage.xml \mgs\Compliance\Importer\Procedures\Reader\Citrix XenApp (EdgeSight)\Usage.xml Using separate SQL Servers or instances for each database In the Setup_Computer.xml, Setup_Evidence.xml, and Setup_Usage.xml files used by the "Citrix XenApp (EdgeSight)" adapter/reader there is a step at the bottom of each the files called "GetFarmName". Each of these steps are the same in the 3 files. It uses a query of the "Monitoring" database by doing a string "REPLACE" of the database name "Site" (which is setup using the "Citrix XenApp (EdgeSight)" adapter/reader as the database connection used in the adapter/reader). The first and simplest way around this is to hard code the value found in their "Monitoring" database and make sure to add it to the temporary table used elsewhere in the adapter/reader scripts (#FarmName is the temp table). The value could be retrieved by manually running the SQL found in the "GetFarmName" step against their "Monitoring" database to get the correct string value. The second way to accomplish this would be to add the server where the "Monitoring" database exists as a linked server (with the same user credentials and permissions) to the database server where the "Site" database lives. Then the same 3 xml files mentioned above would need to be modified to use the linked server to get at the "Monitoring" database to retrieve the required value. The Services team could also be engaged to implement the solution or to suggest and implement other solutions for this situation as well. Please be aware that linked database servers in SQL Server can present security risks. Additional Information The updated logic in 2017 R2 and newer will attempt to guess the site name of the XenApp environment based on the name in the chb_Config.Site table and if that fails, the database name. If the guessed site name does not match the actual site name in the XenApp environment, you can override the site name in the FnmpXenAppAgent.exe tool to force the site names to match. For example, to force a site name of XenAppSite123, you can invoke the FnmpXenAppAgent.exe tool like > FnmpXenAppAgent.exe -d "Server=172.168.38.83;Database=FNMP;Trusted_Connection=yes; " -t 600 -f XenAppSite123 ... View more

Summary When an install containing a .NET installer class component is built on a machine with a certain version of.NET 4.6, the resulting install fails with error 1001. Symptoms When an install containing a .NET installer class component is built on a machine with a certain version of.NET 4.6, the resulting install fails with error 1001. The log shows that the error occurred on the .install custom action used to perform the .NET installer class install actions Cause This behavior is caused by an issue with InstallShield 2015. Steps To Reproduce The easiest way to reproduce the issue is on a Windows 10 machine with .NET 4.6. Steps to Reproduce: Create a new Basic MSI project on the Windows 10 machine. Add a .NET installer class dll as a key file of a component. Set the .NET Installer Class setting to Yes. Build the project. Install the built install. Resolution This issue has been submitted as a bug and is pending review from our Engineering team. The issue is being tracked under issue #IOJ-1752933.. Engineering has released a hotfix that resolves this issue. In order to apply the hotfix, please do the following steps: Close InstallShield. Go to <PROGRAM_FILES>\InstallShield\2015\System. Find and rename ISWIBuild.dll to ISWIBuild.dll.bak Extract the ISWIBuild.dll from the downloaded zip to the InstallShield System folder. Open InstallShield and make sure that the path in Tools > Options > .NET tab correctly points to the v4 folder. Rebuild the project. ... View more