‎Apr 15, 2019 07:29 AM
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.
‎Apr 15, 2019 02:54 PM
‎Apr 15, 2019 08:05 AM
‎Apr 15, 2019 08:16 AM
‎Apr 15, 2019 09:36 AM
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.
‎Apr 15, 2019 01:02 PM
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.
‎Apr 15, 2019 02:14 PM
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.
‎Apr 15, 2019 02:54 PM
Thank you,
This might be our best coarse of action.
‎Apr 16, 2019 07:34 AM
‎Apr 16, 2019 11:48 AM
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 :
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:
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.
‎Apr 22, 2019 03:02 AM
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
‎Aug 14, 2019 07:06 AM
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.
‎Sep 12, 2019 02:55 AM
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:
‎Sep 16, 2019 01:06 AM
Hi @ChrisG ,
Thank you for your answer and instructions, I will try and test this on unix/linux like platform.
‎Sep 16, 2019 01:40 AM
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?
‎Oct 28, 2020 09:13 AM
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.
‎Dec 11, 2019 09:43 AM
@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.
‎Apr 15, 2019 06:34 PM
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
‎Apr 16, 2019 02:37 AM
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
‎Apr 15, 2019 08:08 AM
‎Apr 15, 2019 08:18 AM
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
‎Apr 15, 2019 08:26 AM