while deploying patches to the desktop client maximum systems shows not reported in the console. Please suggest what can be done.
Can you provide a little more information about the problem you are seeing?
1 Like
Please see this OpenMic:
when we deploy ms patches to the client endpoints it shows in status not reported. but most of systems getting deployed and status shows Fixed or completed.
You still aren’t providing many details. It is a bit confusing trying to figure out what you want to know, or what the issue is.
When you first deploy an action dynamically, no computers will have a status.
Then computers will have the action, but not actually run it yet, and they will report that fact and show up as not reported which just means they don’t have an official status of the action yet. This could mean they are in the middle of prefetching files or something else.
Then eventually the status of the action for the endpoint will switch to running, and then completed or fixed.
Not all systems will show up with a status right away once an action is created. It could take a day or so for systems that are offline and/or not getting UDP notifications.
Yes this is correct. We deploy patches on group of computers. 60 to 70 percent gets fixed in status but 20 to 30 percent systems shows “not reported” and when we checked with send refresh its showing the status with current date and time. We check the client logs and accordingly we try to fix the issue. But in maximum cases even in the client logs we are unable to get the status.
If you are not seeing anything in the client logs you may want to look at the logs on the relays from the client to the server and make sure there isn’t a relay issue
1 Like
on the same relay other clients are reporting and patches getting installed.
Start with one client and figure out what is happening. Follow the content from the server to the client and figure out where it’s failing.
If it’s happening across large volumes of clients then it’s probably a relay or network issue
ok. We have doubt on network but we unable to convince network team as what is the exact issue.
more over some times we found information in the client logs that GTS failure or winsock error 3. in that cases we understand that system not reported while deploying the patches this is also reason.
Using Send Refresh will not actually tell the client to gather the new action and run it. It will only tell the client to send in a full report. Clients that do not get UDP notifications will still send in reports periodically on their own.
If these clients get the action after 24 or more hours, then that would suggest that they are not being told to gather the new action and are waiting until the gather interval before realizing there is a new action.
It sounds like command polling or similar would help these clients, because it would lower the 24 hour wait time, but it could also be some other issue.
If the issue is these clients are not getting UDP notifications, then that is definitely network related.
last command times of client
1 Like
If it is not a Network Isues, check the Local Firewall setting to ensure that UDP port 52311 is open to the BES Client.
@ TimRice, could provide the steps to check firewall settings locally on the client system. that would help me.
Instead of checking the client right away, make an analysis with this relevance in it:
This will tell you if your clients are getting UDP pings. As James indicated if the result of this property is “None” then you can only expect clients to look for new content once a day. If the result of this property is a recent date and time then it means the client is getting notifications of new content availability and will thus respond much more quickly than once every 24 hours.
1 Like
Also note, if you make an analysis with that property, it may take the clients more than 24 hours to report in to it if they are having this issue.
I would make this property ASAP to help with all future troubleshooting for this reason.