FNMS Inventory Agent Deployment

[rclark0]

We deployed the Flexnet Inventory agent to 25k devices through a 3rd party push. The software push was successful but we are only seeing about 60% of the devices checking in. The push was to 11 geographical areas and all areas have some devices reporting. We are able to see on the logs that the devices failed to get its policy download but the device has failed to attempt a 2nd connection. Any ideas? Thank you.

[kclausen]

Which Beacon was referenced in the bootstrap configuration file in your agent installation package? For one of these devices where the Policy Download is failing, can you perform a successful NSLOOKUP of the referenced Beacon Server?

[rclark0]

Thank you, would it make sense that 60% of the assets are able to connect and 40% are not? Also it note, we are seeing more and more devices each day.

[rclark0]

We were able to successfully run NSlookup from device not reporting in and Beacon Server listed in bootstrap config

[BradAkers]

Are you running on HTTP or HTTPS? If HTTPS it is important to ensure the certificate was pushed to the UNIX machines correctly. The next troubleshooting would be to validate that the policy was downloaded for each agent. However, today that requires logging on to a machine which fro 40% of 25k is a lot.

[rclark0]

These were non UNIX devices. Also I can see that the policy wasn't downloaded on machines we looked at, not sure how to get the policy to download at this point.

[BradAkers · Accepted solution]

You can rerun the mgspolicy.exe with the -t machine flag. This will force a policy update. This will also help determine if the issue is network related. 

[rclark0]

Thank you,

This might be our best coarse of action.

[mfranz]

Also the "reference implementation" is something that can make the agent deployment more robust. It can create a standard schedule and more flexible beacon bootstrap addressing. As far as I am aware, this is currently not officially supported. Maybe @ChrisG can comment on this?

[ChrisG]

The FlexNet inventory agent bootstrapping technique for Windows that @mfranz  has alluded to is to use the MSI transform and associated files attached here.

The Word document contains details of what the MSI transform does, but a summary it will help with :

1. Installing a bootstrap schedule that is different from the default bootstrap schedule. For example, your bootstrap schedule may be configured to be more aggressive in how often it reattempts to make an initial connection to a beacon to download policy. This can be helpful to mitigate situations where the agent gets installed at a point in time when the agent cannot connect to a beacon.
2. Installing a failover settings package containing settings to use a number of beacons for agent bootstrapping (instead of just a single beacon).
3. Attempting to connect to a beacon to download policy settings to be applied as part of the agent installation process.
4. Gathering inventory and attempting to upload it immediately at agent installation time.

A sample msiexec command line to install the agent using this transform and associated files is:

msiexec.exe /i "FlexNet inventory agent.msi" TRANSFORMS="InstallFlexNetInvAgent.mst" GENERATEINVENTORY=YES APPLYPOLICY=YES BOOTSTRAPSCHEDULE="Bootstrap Machine Schedule" BOOTSTRAPFAILOVERSETTINGS="Bootstrap Failover Settings" REBOOT=ReallySuppress /l*v "%TEMP%\FlexNet inventory agent-install.log" /qb-

The attached sample Bootstrap Machine Schedule.nds file encodes event details that include:

1. Re-attempt to connect to a beacon and apply policy every 5 hours and upon a new network connection. Once policy has been successfully applied, the bootstrap schedule will be replaced with the regular operational schedule as per the agent policy settings.
2. Generate inventory daily.
3. Attempt to upload any files awaiting upload every 13 hours and upon a new network connection.

The attached Bootstrap Failover Settings.ndc file encodes details for a number of beacons to be used for bootstrapping. You will need to edit this file so that it contains beacon details appropriate for your environment.

All files should get placed in the same directory as the FlexNet inventory agent.msi file.

@rclark0  - that is a somewhat long and indirect answer to your original problem. From your description it sounds like many agents were installed at a time when they could not successfully connect to a beacon (for whatever reason - the reason may not be important if it is transient). However on subsequent reboots the agents are re-attempting and succeeding to connect to a beacon, and the backlog of unreported agents is slowly going down. Using a different bootstrap schedule that re-attempts connections at other times and not just upon reboot as described above may have sped up the process of getting agents reporting.

[wernerb]

Thank you, but we only have one Beacon in this environment, the connection is there but the Flex agent software cannot connect to the beacon 

[adrian_ritz1]

Hi @ChrisG ,

I tested your solution with the modified .nds file and is working fine, now I have only 1 package which I can distribute, regardless of which beacon is available. 

I wonder if such a solution exist for Linux/Unix packages, because for this I still need separate packages in BSA, to target specific beacons.

Thank you for your support and I wish you a nice day.

[ChrisG]

The files in the attached FlexNetInvAgentUNIXInstallFiles.zip archive can be used on UNIX-like operating systems to install and bootstrap the agent in a similar way to what I described earlier in this thread for Windows.

You can build a complete set of files for the installation by (1) extracting the contents of this .zip archive into a directory, and then (2) adding in the actual agent installers for the version you want to deploy with the following names in the same directory (you only need to include files for the operating system(s) you are targeting):

AIX/managesoft.<version>.0.bff
HP-UX/managesoft-<version>.depot
Linux (i386)/managesoft-<version>-1.i386.rpm
Linux (x86_64)/managesoft-<version>-1.x86_64.rpm
Mac OS X/managesoft-<version>.dmg
Solaris (sparc)/managesoft-<version>.sparc.pkg
Solaris (x86)/managesoft-<version>.x86.pkg

Once you've built your set of installation files in this way, install the agent by copying the files to a target computer running a UNIX-like operating system and running the flexia-setup.sh script with root privileges.

As with the Windows agent install steps described earlier, the Bootstrap Failover Settings.ndc file encodes details for a number of beacons to be used for bootstrapping. You will need to edit this file so that it contains beacon details appropriate for your environment.

The flexia-setup.sh script will:

1. Run appropriate commands to install the agent based on the operating system.
2. Apply agent configuration settings specified in the UNIXConfig.ini file
3. Configure beacons to be used for bootstrapping as specified in the Bootstrap Failover Settings.ndc file
4. Attempt to download and configure beacon failover settings from these bootstrap beacons
5. Attempt to generate and upload inventory
6. Install the bootstrap schedule settings specified in the Bootstrap Machine Schedule.nds file
7. Attempt to apply policy.

[adrian_ritz1]

Hi @ChrisG ,

Thank you for your answer and instructions, I will try and test this on unix/linux like platform.

[LeccyFez]

@ChrisG 

thanks fro all the work below its been a great help, looking at the options, for strange network reason is there a way to suppress policy updating on the unix devices that we are currently doing for the windows agent under the options of leaving APPLYPOLICY blank and also LIVEFAILOVERSETTINGS black as well, is there any way of replicating this so it stays with the NDC/ODS we have supplied at install?

[darren_haehnel]

It sounds like with that many agents attempting to connect to a single beacon your IIS server is likely indicating an overload condition when too many servers are trying to upload their inventory file at the same instant.  You should be able to identify this condition by reviewing the IIS logs for "503" errors.  By default IIS allows 1000 concurrent connections.  If you find there are "503" errors in the logs, you can try to increase the "Queue Length" on your application pool (it's in "advanced settings").  

I'm working through some tuning of this myself.  We have 30K+ agents reporting into 2 beacons.  My goal is to minimize the "503" errors in the logs and ultimately to receive all of the agent files every day without pushing the web server beyond its allocated capacity.  Both beacons are virtual but I'd rather not spin up additional beacons if there could be untapped capacity already available.  

[rlowery]

---

@rclark0 wrote:

These were non UNIX devices. Also I can see that the policy wasn't downloaded on machines we looked at, not sure how to get the policy to download at this point.

---

Unix devices will retry bootstrapping policy at least once per day.   Windows devices do not share this behavior and will only retry bootstrapping policy on device reboot assuming this was a transient issue that will correct on retry.

[SMC_CIT_Alex]

Hi,

This is a typical boring behavior of windows agent. If they are not able to join the beacon they stop trying.

Another point I already told, is to check for the log for what URLs are trying on the FNMP.

I've seen on a customer some agents sending the policy request with the "administrator.npl" instead of servername.npl.

Are you sure you're running as a system account or full admin ? 

For windows you can use the command sent before or restart the service, which could be pretty easier with tools like puppet.. 

Regards,

Alexandre

[SMC_CIT_Alex]

Hi,

Are you sure the port and url is reachable ? 

If you have certificate for theses computers try to setup the reg to disable servercertificate check.

HKLM\Software\ManageSoft Corp\ManageSoft\Common

key: CheckCertificateRevocation value: false

key: CheckServerCertificate value: False

You could also check your IIS log on the FNMP to see it the agent has reached it and what was the policy file requested (it must contains the servername).

Rgds

[rclark0]

The port and URL are reachable as 60% of the devices are checking in, its just the slow process of getting the remaining 40% in. Each day we get more assets checking in

[SMC_CIT_Alex]

Hi,

Have you check the folder of your beacon with the inventories ? (ProgramData\Flexera Software\Incoming\Inventories)

If there are many files and the number is not decreasing fast, it means your beacon take tome times to the FNMP (network issue, overload, ...).

Could try this 🙂

Rgds,

Alex