Every so often I’ll create an action that will change a relay setting or something similar. This action will go against one or more computers I see in the console. I run the action independently of user presence and with no constraints on scheduling. Yet I’ll see the action take an hour or more to run, even if the target is one computer and that target has been online all day.
I’ve checked to make sure the target computer is running (which it is) and that the main server and relays are running without performance issue (they’re running perfectly fine). Any ideas on what I may be doing wrong, or something I need to due to tune up the running of the action?
Its possible that the UDP message which lets the BES Client know there is an update occasionally isn’t delivered because of network traffic collisions or something else. Its also possible its having temporary communication problems. After getting the action, you should see the client evaluate it, run it and then post a report on the final status.
What you should do is check the BES Client log at the time your action was issued. You should see something like this if the client gets the udp, successfully gathers the data, runs the action and reports the status.
At 11:35:07 -0700 -
GatherAction command received
GatherAction: Version difference, gathering action site
I’ve tried to open some of the client’s log files and get this error: Not all of the selected computers were able to run the selected action.
I can map a drive to the workstations and can ping these systems too. Where can I find the log file, locally, on the workstation after I map a drive to it?
Thanks. I’m looking through a workstation’s log and do not see any note of a “GatherAction command received”. Is this a UDP packet going out on port 52311?
Ok, so if you don’t see “GatherAction command received” that indicates that the UDP message never arrived at the BES Client. You might try taking a few more actions, in you still don’t see this line that indicates UDP is blocked and you’ll likely want to start checking firewalls. If you do get the message, then you are likely looking at temporary network issues that are causing some UDP messages to be lost but not others.
It looks like Windows Firewall was the culprit. After shutting down that service on a workstation actions moved rather quickly. We’ll work to see how we can get Windows Firewall to get out of Bigfix’s way.
There are a number of Fixlets in the BES Support site that will open the Firewall ports necessary for BigFix to function properly. It is recommend that you take these as policy actions. Initial installs of the client will take the policy action on the first action site gather attempt and you will not have any delay when taking actions. In cases where the client is installed and the firewall is blocking action notifications from getting through to the client, the client will initiate a gather within 24 hours (by default), at which point it will gather the action to open up the firewall ports and communication will then work normally.
To find the Fixlets, do a search in your console for Fixlets in the BES Support site that have “Firewall” in the name.
You should take these actions as a master operator.
I am trying to add all these Windows Firewall fixlets that Jesse mentioned in post #9 into a baseline. Then I take the baseline as policy action. The problem is that if I take the individual fixlet as a policy action it works fine, but it fails if part of a baseline. On Windows XP machines the status says Failed and on Vista it stays Evaluating indefinitely. Is this a bug… or maybe an ant?
Is there any particular reason to take these actions as a master operator, as Jesse stated? Even taken as master operator, the action fails the same way.
Taking the action as a master vs. non-master shouldn’t cause an issue… also you shouldn’t have an issue with baselines vs. standard actions and so I am not sure what is going wrong…
You can start a support case if you want someone to specifically look at it…
The issue that you guys found was that the Runquiet.exe wasn’t refered to by the full pathname. Here is an easy fix:
Right-click on the Fixlet and create a custom copy.
In the actionscript, change the line “wait runquiet.exe” to “waithidden”.
The resulting action is:
waithidden “{pathname of system folder}\netsh.exe” firewall add portopening protocol=UDP port={value “ListenPort” of key “HKLM\SOFTWARE\BigFix\EnterpriseClient\GlobalOptions” of registry} name=“BES
Client” mode=ENABLE profile=ALL
Then you can put this Fixlet in a baseline with no problems.
Your fix above works well on XP, thanks for posting it.
As I mentioned earlier, same issue exists with the fixlet for Vista, named “Windows Firewall is Blocking BES Traffic - Windows Vista/2008 - BES Client >= 7.0”
To make it work, I followed your advice and created a custom copy. In the Action script I replaced the below line
wait “{pathname of client folder of site “BESSupport” & “\RunQuiet.exe”}” restart_services.bat
with this one:
wait “{location of regapp “BESClient.exe”}__BESData\BES Support\RunQuiet.exe” restart_services.bat
Even though my policy action now unblocks the Windows firewall as expected, I still see issues. On Vista, if I uncheck the BES Client (only uncheck, not Delete) under the Exception tab in Windows Firewall Settings, the next time my policy action runs, there is another entry ‘BES Client’ that appears in the list with programs, which is basically creating duplicates (the newest one is checked and the old ones stay unchecked). I would expect it to only show one entry for bes client.
Why is the duplicates happen and how it can be fixed?