(imported topic written by SystemAdmin)
Over the last patch cycle, we saw some of our 2008 servers take as long as 12 hours to complete patch deployment. The logs show no errors, and deployment was otherwise uneventful. Deployment usually takes about 20 minutes. Lots of time between each sub-action.
We’re at 7.1.1.315.
Are there known performance issues with server 2008?
(imported comment written by BenKus)
Hi Mike,
I bet the firewall is on, which blocks the UDP messages… So it isn’t that the agent is running slowly, but instead the agent didn’t know that there was anything new until it checked (daily)…
You can test by sending a refresh and seeing if you get an entry in the log files (if no entry is there, then it means UDP is blocked or in some way not working).
You can add an exception for inbound UDP port 52311 to address this.
Ben
(imported comment written by SystemAdmin)
Windows firewall is disabled on the device. I see forcedrefresh requests in the log.
(imported comment written by lepp91)
I had the same issue patching last night… it took a couple hours to install a handful of patches. Server 2008 SP2/SQL 2008 SP1. BES ports are open via AD policy.
(imported comment written by SystemAdmin)
A little more background…
This was a scheduled action with about 10 sub-actions.
The action started on time. Logs show that it would start and complete one of the sub-actions, then wait about an hour to start the next sub-action. The only other events in the log were “DownloadPing command received”. These would occur every few minutes until the next sub-action began.
(imported comment written by SystemAdmin)
So we are seeing the same type of behavior on Win Vista. We thought it was attributed to t0o many actions in a baseline, but perhaps the real issue is the actions themselves? Windows firewall is disbaled as well via Group Policy. We see the same thing in the logs. The clients pause so long they actually show greyed out in the console.
We are at 7.2.4.60.
(imported comment written by BenKus)
If you are using non-efficient mime (if you upgraded from version 6… more info at: http://support.bigfix.com/cgi-bin/kbdirect.pl?id=420) then you need to be careful about baseline size because the old baseline format and the old agent were very inefficient at handling large baseline actions. And if you repeatedly take actions from a big baseline, then the problem will get worse and worse.
I am speculating that since this was a big patch month, you might have baselines that are pretty big and it might be slowing the agents down… You might want to separate the components into a couple different baselines to get the number underneath 50 or so components per baseline for non-efficient-mime or 150 or so for efficient-mime.
You might also consider temporarily increasing the agent resource usage with the Tasks on the BES Support site, but that might be overkill for this issue.
Ben
(imported comment written by SystemAdmin)
What about my non-baseline issue?
(imported comment written by BenKus)
Hey Mike,
Which non-baseline issue are you referring to? For the purposes of this discussion, large multiple-action groups are effectively the same as an aciton from a large baseline.
Ben
(imported comment written by SystemAdmin)
In that case, my multiple-action group contained 10 sub-actions - Well below the numbers you indicated above.
(imported comment written by BenKus)
Hi Mike,
We can’t know for sure unless we examine the computer and try to reproduce the issue (probably with the emsg debug log enabled)… Support can help you with this if you want…
Do you have a lot of other large baseline actions from you or other operators?
Ben
(imported comment written by SystemAdmin)
No. And this particular issue only manifested on 2008 Servers.
(imported comment written by SystemAdmin)
Did your actions (fixlets or baselines - doesn’t matter) contain the “MS09-035: Vulnerabilities in Visual Studio Active Template Library Could Allow Remote Code Execution - Visual C++ 2005 SP1” fixlet? If so, see this thread - http://forum.bigfix.com/viewtopic.php?id=4065