I have set up a new instance of Bigfix and am starting the testing process. In the past I have had various problems with responsiveness and really hoped to escape those with this new instance, but that doesn’t seem to be the case.
I am testing some basic actions against a few lab test PCs. In the action status, it shows that the PCs are in a not reported state even though they are regularly reporting. It is taking anywhere from 30 minutes to 1 hour to get an action to complete. The client logs simply show “Report posted successfully” over and over in the mean time.
I am using a False Root server so I wonder if that is part of the problem. I have the endpoint set up to use a Top Level Relay server and have changed the DNS entry for the actual root server to point to the IP of the false root. I have played with some of the settings such as Resource Work/Sleep, Download CheckAvail, Report Interval, etc. I’m sure I have something configured wrong and would appreciate some help.
Based on your description, it sounds like the Clients are not receiving notifications of new content or actions. This typically occurs as a result of firewalls (hardware or software) blocking downstream traffic on the BigFix port for either TCP between Relays, or UDP between Relays and Clients. See https://support.hcltechsw.com/csm?sys_kb_id=730339d71bfec8dcc13e748edc4bcbd1&id=kb_article_view for additional information.
Allowing for notifications to be received by the endpoints by configuring firewall rules is generally best, but there are other options as well such as command polling, and more recently persistent connections.
If it were a firewall issue, would the clients still be receiving the actions eventually? I ask because the actions do eventually go through, just after a long time. Our networking guys often times leave off UDP when making firewall rules so I will definitely check that. Thanks for those links as well.
Yes, the Clients do poll on their own (by default every 24 hours, but configurable as a masthead option), so, they should still be able to run actions eventually.
Try configuring command polling on a few of the clients to see if that resolves the issue. If it does, then start digging into why the systems might not be receiving the UDP messages that alert them to new content on their Relay.
I second Tim’s suggestion on command polling. Additionally, if you are on 9.5.11 or later, it’s woth looking at the new features for Persistent Connections.