cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
x-dkshasau
Level 3

machine is not reporting

Jump to solution

I have checked the installation and policy logs and found that program successfully exited. So what could be cause of agent is not reporting to Flexera.

1 Solution
adrian_ritz1
Level 9

Hi @x-dkshasau ,

 

You need to check also the tracker.log and uploader.log to see if something is uploading to beacon server.

 

View solution in original post

This thread has been automatically locked due to inactivity.

To continue the discussion, please start a new thread.

3 Replies
adrian_ritz1
Level 9

Hi @x-dkshasau ,

 

You need to check also the tracker.log and uploader.log to see if something is uploading to beacon server.

 

jjensen
Flexera Alumni

Hello @x-dkshasau,

There are quite a few steps in the chain that need to succeed in order for a managed device to report into the Web UI. To summarise:

1) The agent must generate the inventory AND upload successfully to one of your beacon servers

You can check this within the tracker.log on the agent machine, available within C:\Windows\Temp\ManageSoft (Windows) OR /var/opt/managesoft/log (Unix). There is also a 'catch up' upload mechanism, which generates logging to the uploader.log file in the same folder.

2) The inventory (.NDI) file must be received by the beacon's web server and subsequently uploaded

You can check the IIS logs on the beacon server within %SystemDrive%\inetpub\logs\LogFiles\W3SVC1 to ensure that the PUT request from the agent machine has succeeded. Check for a HTTP response code of 200 (success). If that's fine, then you can check the uploader.log on the beacon, available within C:\Windows\Temp\ManageSoft.

A word of warning: this log file fills up very quickly, so it would be best to check in real-time, otherwise the log may get written past the time-frame where the file was uploaded.

If the beacon involved in step #2 was a child beacon, then you must repeat step #2 for the parent beacon which the child beacon reports to. If not, move on to step #3. Any steps below apply only to On-Premises customers.

3) The inventory (.NDI) file must be processed by the web resolvers on the inventory server, and the data brought in to the InventoryManager DB.

You can check the web resolver event logging by checking the dispatcher.log within C:\ProgramData\Flexera Software\Compliance\Logging\WebResolvers on the inventory server.

If that looks OK, you can check the InventoryManager DB with an SQL query like the following:

SELECT * FROM Computer c
JOIN InventoryReport ir ON ir.ComputerID = c.ComputerID
WHERE c.ComputerCN = 'computer name goes here'

4) The ManageSoft readers (run on your batch server as part of the nightly reconciliation job) will pull the data from the InventoryManager DB and process it into the staging tables in the Compliance DB.

You can check if this went OK, by checking the ImportedComputer staging table for your device. Example SQL query:

SELECT * FROM ImportedComputer
WHERE ComputerName = 'computer name goes here'

5) If you've gotten to this point without any problems, then one potential cause could be that the incoming device is being matched/merged into an unexpected existing Inventory Device. You can check the 'ComplianceComputerID' column of the ImportedComputer record to verify this.

The ComplianceComputer table in the Compliance DB is the final stage for your inventory device data. Anything that makes it in here should, in theory, be visible within the Web UI. You may find it easier to work backwards (i.e. start at the database level.)

There's a lot of nuances that I've missed out in the steps above, but hopefully it should serve as a high-level guide. I've also attached the schema reference PDF, which will serve you well in future if you should ever need to traverse the database.

HTH,
Joseph

If my response answered your question satisfactorily, please click "ACCEPT AS SOLUTION" to heighten visibility for future customers!

@x-dkshasau , you should take into consideration the following when installing an agent on a server.

1. Upload time window, every agent have an upload time window set in WebUI, for example if you have the upload window set as daily between 00:00 - 06:00, the agent will generate inventory and upload in a random time in this time window, if you install for the 1st time the agent outside this time window, he will wait and generate according his policy and schedule

2. Agent scheduler, you can check the scheduler running the ndschedag -t machine command, this will give you the machine scheduler and also you can check if the policy is downloaded correctly, you should see a window with the 4 scheduled tasks  for agent. In this window (only windows) you can force with right click on Generate Machine Inventory and Upload Inventory to generate and upload the inventory.

3. Replication time between beacon(s), as Joseph stated before, you should take into consideration this, if the replication is 1 min, 10 min, 30 min 1 hours, and you have multiple hops, then you do the math.

For example in my implementation I have a custom packet deployed with a custom policy that enforce the generation and upload of the inventory as son as possible, replication time between beacon on 1 min, and I activate on app server the catching of the .ndi file in IIS. So after a few minutes I can check if raw data are landing on the app server but also I can check with @jjensen  SQL command if indeed is imported in Inventory Manager database.

I hope this information will bring you some light about how agent is working.