This section will go over what files are transferred from the beacon to the inventory component and the inventory component. Your diagram should look like this.  Minus any load balancers or proxies, as this will be covered separately to this document. Regardless of which server setup type you choose; the beacon will still have to connect to the Inventory component.   Outgoing (To Inventory) – To ManageSoftRL Within the Inventory Component Logs Location: C:\ProgramData\Flexera Software\Incoming\Logs There are a few additional files such as vdi, and security service logs that get sent to the beacon Inventory (.ndi) Local Location: C:\ProgramData\Flexera Software\Incoming\Inventories These are the inventory files that the agent passes up to the beacon. Again there can be multiple different versions compared to the agent ndi files. These include oracle, and VMware NDI files Discovery Files (.disco) Local Location: C:\ProgramData\Flexera Software\Incoming\Discovery These logs show what devices are discovered during the discovery process of the rule. Active Directory (actdir.gz) Local Location: C:\ProgramData\Flexera Software\Incoming\Active Directory These files contains details from your Active directory import. The kind of data is user, subnets, sites and devices. Beacon Status (.bstat) Local Location: C:\ProgramData\Flexera Software\Incoming\BeaconStatus These files are the status files generated by the beacon engine. These files contain data of the “oldest” files to be uploaded such as inventory files, this also shows whether the beacon has the correct policy. If these are failing to upload you might see them within the UI that the beacon is showing as not connected. Activity Status files (.activity) Local Location: C:\ProgramData\Flexera Software\Incoming\ActivityStatus These files contain information on any rules/schedule that the beacon runs. These normally create a few files for the start and end of the task that it has stated. Again, these are shown within the UI under system tasks as rules not running or failed. Intermediate Data Local Location: C:\ProgramData\Flexera Software\Incoming\IntermediateData These files are created when the rules and schedules run, normally these are the third party connectors like SCCM and vmware integrations data is created and then uploaded. Incoming (To Beacon) – From ManageSoftDL Within the Inventory Component Adoption/Upgrade Packages (.OSD + .NDS + .NDC) Local Location: C:\ProgramData\Flexera Software\Warehouse\Staging\Common These packages are there if you wish to upgrade the agent/beacon to a newer version than what it is currently on. These are usually Version Number\OS type.ndc This is also the location that keeps the adoption files, so if you choose to remote install the agent then these files will be used to push the install to those devices. ... View more

This part will go over what files are transferred from the agent to the beacon and the beacon to the agent.. Your diagram should look like this. Minus any load balancers or proxies, as this will be covered separately to this document. Incoming (To agent) from ManageSoftDL on the Beacon  Outgoing (To Beacon) – To ManageSoftRL on the beacon        Note : This communication will be over port 80 or 443 by default.  Both directions need to be open for communication to happen. Incoming (To agent) from ManageSoftDL on the Beacon These will be the files that will be generated by the beacon, based on the beacon policy file that will be discussed later. There are several files that will be transferred from the beacon to the agent. These Files include Policy(.npl): Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Policy Client\Policies\Merged\Machine This is the initial file that an agent will download. This contains the locations for the client files listed below. Note : If during a fresh installation, this file fails to download it will not retry. To resolve this, you will need to either restart the agent service, or restart the device. Schedule (.osd + .nds) As the name describes this is the file that controls when the agent will update machine policy, client settings and client files. This is also where the setting is held to generate the inventory of the device that has the agent installed. This is controlled by the settings within Discovery & Inventory> Settings> Agent Schedule. Settings (.osd + .nds) These files control what is being inventoried, such as including/excluding folders, file types. This is controlled by the settings within Discovery & Inventory> Settings> File Evidence. Failover (.osd + .nds) These settings are if you have additional beacons setup, so that if the agent cannot communicate to one of the beacons it can try to send or receive packages from another beacon on your estate. These beacons can be seen from the Discovery & Inventory> Beacons page. You can also view these within regedit under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft \Common\ DownloadSettings And HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Common\UploadSettings Upgrade Packages (.OSD + .NDS + .NDC) These upgrade packages are there if you wish to upgrade the agent to a newer version than what it is currently on. Outgoing (To Beacon) – To ManageSoftRL on the beacon These are the files that are needed to inventory the machine, these come from the locations listed in each subsection. Logs Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Logs There are a few additional files such as vdi, and security service logs that get sent to the beacon Inventory (.ndi) Local Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories These Files are the generated inventory of the device in question. There are different kinds of .ndi file dependent on what is being run. i.e Oracle. These files contain the hardware and software data from the device, and if file evidence is installed it will also grab applications. For oracle .ndi files this will contain what option packs are installed on what oracle instance. Usage (.mmi) Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\UsageData Captures events from the usage agent which captures application usage information. The usage agent runs under the  'Flexera Inventory Manager security service' Windows Service.   Outgoing (To Beacon) – To ManageSoftRL on the beacon These are the files that are needed to inventory the machine, these come from the locations listed in each subsection. Logs Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Logs There are a few additional files such as vdi, and security service logs that get sent to the beacon Inventory (.ndi) Local Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\Inventories These Files are the generated inventory of the device in question. There are different kinds of .ndi file dependent on what is being run. i.e Oracle. These files contain the hardware and software data from the device, and if file evidence is installed it will also grab applications. For oracle .ndi files this will contain what option packs are installed on what oracle instance. Usage (.mmi) Location: C:\ProgramData\ManageSoft Corp\ManageSoft\Common\Uploads\UsageData Captures events from the usage agent which captures application usage information. The usage agent runs under the  'Flexera Inventory Manager security service' Windows Service. ... View more

This is a follow on to Part 1: FNMS-Data-Flow-Introduction  So this part will cover some of the considerations i have been asked when setting up FNMS. I know there are more considerations, and i will add to them in due time.  Two Way Communication  Port Numbers  Setup Types  Setting up a Child Beacon:  Setting up a DMZ:    Two Way Communication Since all components communicate to each other, there needs to be two-way communication between each component. Especially Agent to Beacon, and Beacon to inventory/batch server. This means that you will need to configure your firewall to all incoming and outgoing communication between components over which ever port you choose. Port Numbers This is a consideration you will have to undertake, whether you use the regular ports of 80 and 443 or whether you use noncommon ports is up to you. As stated above you will need to make sure that whatever port you choose needs to be opened both directions. For additional Port numbers used check the online help here: https://docs.flexera.com/fnms2019r1/EN/WebHelp/index.html#topics/FIB-PortsAndURLs.html Setup Types There are multiple different layouts when configuring an FNMS environment. A few of these would look like the following: Single Server Setup : Inventory, batch, and application installed on single device   This is the most common setup, as it requires less servers to be configured, and is the easiest to configure. Since all the components are installed on a single server. This however request the most amount of processing power and resources on a single machine. You could change this setup to have the database on a separate server than on the server with the FNMS components on. That way would be more optimal and not that hard to configure.   2 Server Setup :  batch, inventory installed on 1 and application server installed on another   This setup sees that the batch and inventory are sitting on the same server, and the application is on its own. This configuration is the second easiest way to setup FNMS, and probably the most optimal in that it requires less servers to be setup than the 3 server setup and is less complicated to setup.  3 Server Setup : components installed on separate servers   As you can see from the image above, each component sits on its own server. This setup carries the best performance but can be a little tricky to setup. If not configured correctly during installation.   Multi-level beacon setup   This setup is where you have multiple beacons in a parent – child setup. This is for customers that have complex environments, that need different beacons in different regions around the world. It can also be used as sort of a load balancing or in some instances a DMZ setup. Setting up a Child Beacon: Setting up a child beacon is similar to setting up a normal beacon, however when configuring the beacon from within the FNMS UI, you would select the beacon that it would report to as the parent beacon.  See https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/Beacon-Configuration-Child-to-Parent/ta-p/120193 for more details Setting up a DMZ: Although we cannot tell you what you need to secure your DMZ, we can advise on how to set up FNMS. There are a few approaches you can take, two of them are similar in the steps you take to configure the beacon. However, depending on what you have setup within your estate will alter which approach to take. Reverse Proxy This approach would be to setup a proxy in which your users laptops would access that would forward to your beacon https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/How-to-enable-Beacon-Reverse-Proxy-Setup/ta-p/152864   Beacon Network Name (Alias) This would be to setup your beacon to have an alias which would have an outside name that would be handled by our DNS https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/How-to-configure-the-beacon-to-use-a-different-name-or-alias/ta-p/2064   Dummy Beacon Records This would be to create records within the beacon table, however this would not be practical as this would show the beacons within the UI, that would show as never connected.   ... View more

This document will show where different data elements are obtained and how they are mapped into FlexNet Manager Suite software. Note that we do not specify the FNMS version as this document is meant to reflect the latest environment. This will also include the different server layouts that you can choose as well as recommendations when standing up an environment. It will also include a lower level overview of how and what files get transferred during the data flow. This Blog will be Broken down into parts,  Part 1: Introduction To The Components Part 2: Data Flow Considerations  Part 3: Data Flow: Agent <-> Beacon Communication Part 4: Data Flow: Beacon <-> Application Communication Part 5: Data Flow: Beacon to Database Part 6: Data Flow: Complete Diagram Part 7: Reconcile Processes Definition of FNMS components This section will cover the components of FNMS. these components differ between on premise and cloud customers. The core components are: Batch Inventory Application Agent Beacon Although each setup has these core components, as well as the database components, for cloud customers you will not be able to access the core component servers. However, with a on premise customer these core components will be accessible, but there are different layouts that you can configure depending on your environment. Agent There are four three types of agent that are used under different circumstances: FlexNet Inventory Agent Zero Footprint (FlexNet inventory core components on inventory beacons) FlexNet Inventory Scanner Note : These are covered more in the Deployment Overview within the GatheringFlexNetInventory.pdf The agent component itself, will gather inventory from the agent. Some of the above utilization methods will alter what is brought back. With the full agent you can configure to inventory hardware data, and installation data. If you enable within the FNMS UI you will be able to import file evidence which will bring back your applications. Beacon An inventory beacon is a computer with FlexNet Beacon software installed. It gathers hardware and software inventory and other information from your network and uploads the resulting files in date/time order from oldest to most recent to FlexNet Manager Suite. After installation, the inventory beacon is registered with FlexNet Manager Suite. A beacon also handles connectors such as SCCM, ADDM, O365, etc. adapters, this is also where the agents (Listed below) sends their inventory data to. Note : We do not recommend that you install a beacon on any of the core component servers Application Component This is where the application front end is stored, for cloud you will not have access to this server, but for on premise this will usually just be the web application combined with IIS. This web front end of FNMS that users will connect to. This handles the GUI and presents the data for use. This also houses the configuration settings, rules, and license information for your inventoried estate. Inventory Component An Inventory component is the location that the incoming inventory from different data sources will eventually arrive at down their FNMS journey. This is also where the batch server will take the data from the inventory and import the data from those NDI files into your database. Batch Component A batch component houses the tasks that the web front (application server) handles. This will be where you configure reconciliation tasks. This also handles the download of packages and policies that both your beacon server and agents use. The batch server also handles the readers and writers when importing data into your FNMS system. Note : Readers and writers will not be covered in detail within this document Database Component The database component has all the data that is imported into the system, it also holds configuration settings, and saved reports. This is what the application component pulls from to present the data within the GUI. The database component can be flexible where its installed, it can be installed on any of the servers with a component on or can be installed separately. ... View more

Symptoms: There is a problem with upgrading to 2020 R2.2 beacon. Agents will get a 500 error when attempting to upload and download from the beacon       Diagnosis: When trying to navigate to managesoftDL     You will also see within the devices event viewer.  Process information: Process ID: 5428 Process name: w3wp.exe Account name: IIS APPPOOL\Flexera Beacon Exception information: Exception type: HttpException Exception message: Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at System.Net.Http.Formatting.BaseJsonMediaTypeFormatter..ctor() at System.Net.Http.Formatting.JsonMediaTypeFormatter..ctor() at System.Net.Http.Formatting.MediaTypeFormatterCollection.CreateDefaultFormatters() at System.Web.Http.HttpConfiguration.DefaultFormatters(HttpConfiguration config) at System.Web.Http.HttpConfiguration..ctor(HttpRouteCollection routes) at System.Web.Http.GlobalConfiguration.<CreateConfiguration>b__0() at System.Lazy`1.CreateValue() at System.Lazy`1.LazyInitValue() at System.Lazy`1.get_Value() at System.Web.Http.GlobalConfiguration.get_Configuration() at Flexera.Beacon.IISWeb.Global.Application_Start(Object sender, EventArgs e) Solution: modify the C:\Program Files (x86)\Flexera Software\Inventory Beacon\DotNet\Web.config on the beacon for a customer and replace the lines within the <assemblyBinding> </assemblyBinding> with the following: <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31BF3856AD364E35" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31BF3856AD364E35" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Autofac" publicKeyToken="17863af14b0044da" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-5.2.0.0" newVersion="5.2.0.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" /> </dependentAssembly> After editing this file please restart iis and the beaconengine.exe service. ... View more

Has FNMS been tested on: 1:XMl exploide 2:Buffer over run exploid based on an NDI  3: Is there an pentest report availlable? Also why is there no secure authentication possible from the agents towards the beacon when they upload their NDI?  Are there plans to make this more secure? Altough basic authentication is possible it is not secure.  With a beacon on the internet (DMZ) there is an potential risk in having an indirect opening towards the Application and SQL server. From their information around what software is installed can be collected from all servers. What is very usefull information from hacking. What are the current plans to make the agent to BEacon communications more secure?  ... View more

Summary: After upgrading from version x to a newer version. You might choose to upgrade your beacon or agent manually. Once this has been done, there is a chance, or you noticed that the agent or beacon downgrade from the most recent version to an older version. There are multiple scenarios this might be happening: Beacons are set to stay at that level through automatic deployment Unable to select the most recent version to deploy Scenario 1 Within Discovery & inventory > Settings Agents Under Inventory Agent for Automatic Deployment         Beacons Beacons have two places that control what version they are running: 1. Discovery & Inventory > Settings> Beacon Settings 2. Discovery & Inventory > Beacons If you press the edit button next to the beacon in question   These drop downs are controlled by your adoption table within your database, if these are not showing the most recent version then this will be why your beacons and agents are downgrading. If this is the case, then move over to scenario 2.   Scenario 2 This scenario follows on from scenario 1, when the options that you can select does not include the most recent update. The problem stems from the adoption table not having the most recent version stored within it. This usually is caused by either the config.ps1 not being ran or not completed fully. To rectify this issue. Re-run the config.ps1 and allow it complete. If you notice any errors check where it errored out. ... View more

Summary This KB article will cover the configuration and collection of trace files within FNMS. For additional logging of what is being collected during the inventory, It will cover the different types of trace files including details on lite agents.   Synopsis Trace level logging can be performed on the batch, application, beacon, and agent and is used primarily when the normal logging solutions do not provide enough information, even with debug settings enabled. By generating a trace log you can track much more activity although tracking everything can result in very large files so be warned to only use this when necessary and do not forget to turn it off when you're done.   Trace file location per component The location of the trace files is dependent on what you are looking to trace. Each component has a different location, see the below table for reference Component File Name Windows File Location Unix File Location Full Agent ETCP.trace C:\Program Files (x86)\ManageSoft /opt/managesoft Lite Agent (remote execution) ndtrack.trace Wherever the ndtrack.exe is located (i.e. C:\Temp\) root /etc  Beacon ETDP.Trace C:\Program Files (x86)\Flexera Software\Inventory Beacon N/a Inventory/Batch ETAP.trace C:\Program Files (x86)\Flexera Software\FlexNet Manager Platform N/A Note: that the Lite Agent (remote execution) trace file should be called ndtrack.trace   How to run the trace files Go to the component that you want to run a trace on (see Trace file location per component) Navigate to the directory (see Trace File location per component) Take a backup copy if you require to revert back to the original Open the relevant Trace file (be aware you may need to first disable the relevant Flexera service via services.msc before this file can be opened or saved) Once opened find the following line and define a valid file-path (Please note the location must exist otherwise the trace will not work)   Usually, the technical support member will inform you of what you will need to uncomment, to do so remove the ‘#’ from the beginning of the line   Once done, save the document and attempt to perform the problem action again, i.e. Agents run the following commands For Windows Agents and Lite Agents: ndtrack.exe -t Machine -o LogFile=C:\Temp\tracker.log -o Upload=false -o MachineInventoryDirectory=C:\Temp For Unix Agents: ./ndtrack -t Machine -o LogFile=/tmp/log/managesoft/tracker.log -o Upload=false -o MachineInventoryDirectory=/tmp/log/managesoft For Unix Lite Agents: ./ndtrack.sh -t Machine -o LogFile=/tmp/log/managesoft/tracker.log -o Upload=false -o MachineInventoryDirectory=/tmp/log/managesoft Beacons execute a discovery rule or scheduled task etc. Batch execute a license or full reconcile, one-off import, etc. Note: It might be quite large prior to compressing, and might take a while to generate the relevant files Navigate to the location set within the trace.log file The directory should include Managesoft_#_Date.log (if kept default file name) Compress the files and attach to the case if needed Note: remember to repeat steps 1 - 6 and to comment the code out using '#' or to restore to your backed-up copy.   References Options Definitions (ETCP) For the full guide see “Adopted: Troubleshooting Inventory” within the GatheringFlexnetInventory.pdf Category Option Notes Networking +Communication/Network Traces all low-level upload and download actions (whether HTTP or HTTPS). It includes HTTPS certificate checking and related areas. Covers actions by the ndtrack, ndupload, and ndlaunch components. All inventory +Inventory Traces all inventory operations, which on large inventory tasks, could result in a sizable trace file. All tracker +Inventory/Tracker This traces almost all operations of the ndtrack executable. Preferences +Inventory/Tracker/ Environment Shows active preferences, whether set in the registry (on Windows platforms) or in the config.ini file (on UNIXlike platforms), or inbuilt default values. Hardware inventory +Inventory/Tracker/Hardware Traces all hardware inventory classes visible in the <Hardware> node in the .ndi inventory file, including CPU information and virtualization. Software inventory +Inventory/Tracker/Package Traces the inventory operations that populate the <Package> nodes in the .ndi inventory file. Software inventory +Inventory/Tracker/Software Tracing mainly for file inventory gathering (such as the <Content> and MD5 nodes of the .ndi file). Oracle inventory +Inventory/Tracker/Oracle When the inventory device hosts Oracle Database, this is the tracing for local Oracle inventory. Operations +Inventory/Tracker/Generate Traces the preparation of the .ndi inventory file(s), keeping in mind that on an Oracle Database server, there may be multiple files generated. Operations +Inventory/Tracker/Compress Traces the compression of the .ndi file into a .gz archive. Operations +Inventory/Tracker/Upload Traces the upload of the .ndi.gz archive to an inventory beacon by the tracker. Tip: If the immediate upload by the tracker fails for some temporary reason, the upload is attempted again later by the ndupload component. While this component does not provide this same level of operations tracing as the tracker does, you can enable +Communication/ Network for low-level tracing of each step in the upload interaction.     ... View more