Action Processing Issue

Usage and Config
1

Hey Guys,

Anyone have any idea on what would cause BigFix agents to only process actions when you restart the agent, and not when they are reporting in?

Clients are reporting in to a relay.

In the example, the action was deployed at 11:40 … the client reports in many times… doesn’t process the action until i restart the agent… when the client does its register… then it processes…

Anyone have an idea why?

At 11:31:41 -0300 -
RegisterOnce: Attempting secure registration with 'https://THEroot.company.ca:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.1.48&Body=11657004&SequenceNumber=112&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&MinHops=14&Root=http://THEroot.company.ca%3A52311&AdapterInfo=00-0c-29-cc-11-51_192.168.203.0%2F24_192.168.203.246_0&AdapterIpv6=00-0c-29-cc-11-51^fe80%3A%3A4556%3A9493%3Ae4e6%3Ab2c%2F64_0’
Unrestricted mode
Configuring listener without wake-on-lan
Registered with url 'https://THEroot.company.ca:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.1.48&Body=11657004&SequenceNumber=112&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&MinHops=14&Root=http://THEroot.company.ca%3A52311&AdapterInfo=00-0c-29-cc-11-51_192.168.203.0%2F24_192.168.203.246_0&AdapterIpv6=00-0c-29-cc-11-51^fe80%3A%3A4556%3A9493%3Ae4e6%3Ab2c%2F64_0’
Registration Server version 9.2.2.21 , Relay version 9.2.1.48
Relay does not require authentication.
Client has an AuthenticationCertificate
Relay selected: THEroot.company.ca. at: 111.222.333.444:52311 on: IPV4
ShutdownListener
SetupListener success: IPV4/6
At 11:36:10 -0300 -
Report posted successfully
At 11:42:34 -0300 -
Report posted successfully
At 11:54:58 -0300 -
Report posted successfully
At 12:14:45 -0300 -
Report posted successfully
At 12:27:37 -0300 -
Report posted successfully
At 12:39:19 -0300 -
Report posted successfully
At 12:57:50 -0300 -
Report posted successfully
At 13:10:49 -0300 -
Report posted successfully
At 13:12:11 -0300 -
Client shutdown (Service manager stop request)
Current Date: July 14, 2015
Client version 9.2.1.48 built for Windows 5.0 i386 running on WinVer 6.1.7601
Current Balance Settings: Use CPU: True Entitlement: 0 WorkIdle: 10 SleepIdle: 480
ICU data directory: 'C:\Program Files (x86)\BigFix Enterprise\BES Client’
ICU init status: SUCCESS
ICU report character set: windows-1252
ICU fxf character set: windows-1252
ICU local character set: windows-1252
ICU transcoding between fxf and local character sets: DISABLED
ICU transcoding between report and local character sets: DISABLED
At 13:12:11 -0300 -
Starting client version 9.2.1.48
FIPS mode disabled by default.
Cryptographic module initialized successfully.
Using crypto library libBEScrypto - OpenSSL 1.0.1j-fips 15 Oct 2014
Restricted mode
Initializing Site: BES Asset Discovery
At 13:12:12 -0300 -
Initializing Site: BES Inventory and License
Initializing Site: BES Support
Initializing Site: BigFix Labs
Initializing Site: CustomSite_ACME
Initializing Site: CustomSite_companyManagementSite
Initializing Site: CustomSite_company
Initializing Site: Enterprise Security
Initializing Site: IBM Endpoint Manager for Software Use Analysis
Initializing Site: IBM License Reporting
Initializing Site: Patching Support
Initializing Site: Software Distribution
Initializing Site: Updates for Windows Applications
Initializing Site: mailboxsite
Initializing Site: opsite8
Beginning Relay Select
RegisterOnce: Attempting secure registration with 'https://THEroot.company.ca:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.1.48&Body=11657004&SequenceNumber=113&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://THEroot.company.ca%3A52311&AdapterInfo=00-0c-29-cc-11-51_192.168.203.0%2F24_192.168.203.246_0&AdapterIpv6=00-0c-29-cc-11-51^fe80%3A%3A4556%3A9493%3Ae4e6%3Ab2c%2F64_0’
At 13:12:15 -0300 -
Unrestricted mode
Configuring listener without wake-on-lan
Registered with url 'https://THEroot.company.ca:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.1.48&Body=11657004&SequenceNumber=113&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://THEroot.company.ca%3A52311&AdapterInfo=00-0c-29-cc-11-51_192.168.203.0%2F24_192.168.203.246_0&AdapterIpv6=00-0c-29-cc-11-51^fe80%3A%3A4556%3A9493%3Ae4e6%3Ab2c%2F64_0’
Registration Server version 9.2.2.21 , Relay version 9.2.1.48
Relay does not require authentication.
Client has an AuthenticationCertificate
Relay selected: THEroot.company.ca. at: 111.222.333.444:52311 on: IPV4
At 13:12:16 -0300 -
PollForCommands: Requesting commands
PollForCommands: commands to process: 3
Entering service loop
At 13:12:17 -0300 -
SetupListener success: IPV4/6
At 13:12:17 -0300 - actionsite (http://THEroot.company.ca:52311/cgi-bin/bfgather.exe/actionsite)
Downloaded ‘http://THEroot.company.ca:52311/bfmirror/bfsites/manydirlists_1/__diffsite_2064bb658055413362da3577dc8c8541aa9814fd_to_4aadb443b1d8cc4c84a6ca1dd348c599396c7c17’ as '__TempUpdateFilename’
Gather::SyncSiteByFile adding files - count: 1
At 13:12:17 -0300 -
Successful Synchronization with site ‘actionsite’ (version 2772) - 'http://THEroot.company.ca:52311/cgi-bin/bfgather.exe/actionsite’
At 13:12:18 -0300 - mailboxsite (http://THEroot.company.ca:52311/cgi-bin/bfgather.exe/mailboxsite11657004)
Downloaded ‘http://THEroot.company.ca:52311/mailbox/files/e0/3f/e03f3be95ee237e1215f257856954339eefd4714’ as 'Action 1956.fxf’
At 13:12:20 -0300 - mailboxsite (http://THEroot.company.ca:52311/cgi-bin/bfgather.exe/mailboxsite11657004)
Downloaded ‘http://THEroot.company.ca:52311/mailbox/files/bf/33/bf331b2af0c362f5df48f510e87c3e1912ebefbe’ as 'Action 1966.fxf’
Gather::SyncSiteByFile adding files - count: 2
At 13:12:20 -0300 -
Successful Synchronization with site ‘mailboxsite’ (version 22) - 'http://THEroot.company.ca:52311/cgi-bin/bfgather.exe/mailboxsite11657004’
ActiveDirectory: Refreshed Computer Information - Domain: (N/A)
User interface process started for user 'admin’
GatherHashMV command received.
Already have this version of site.
At 13:12:20 -0300 - mailboxsite (http://THEroot.company.ca:52311/cgi-bin/bfgather.exe/mailboxsite11657004)
Relevant - Custom Action (fixlet:1966)
Relevant - Custom Action (fixlet:1956)
At 13:12:20 -0300 -
ActionLogMessage: (action:1956) Action signature verified for Execution
ActionLogMessage: (action:1956) starting action
ActionLogMessage: (action:1956) ending action

2

Can your clients receive a UDP message on port 52311?

If the client never receives the UDP message from its Relay, it will not know to check for new Actions. By default, the client SHOULD check for new Actions once a day.

You could try enabling “Command Polling” to force the clients to check for new Actions … http://www-01.ibm.com/support/docview.wss?uid=swg21505846

By default, the BES Client process will only check for new actions when it receives a UDP ping on port 52311(or whichever port you are using in your environment). This UDP message is sent whenever a Console Operator submits an action in the Console.

1 Like
3

@TimRice has the answer, but here are some related posts that go into some extra details:

Related Posts:

Related content:

Example clientsettings.cfg file to enable command polling at EXE install time:

4

Hey Guys,

So the command poll is enabled and set to 900. The issue is, that clients on the internal network are reporting in, and processing actions. It’s the external clients that are pointing to the public IP that are not processing commands.

The situation: port 52311 TCP is allowed on the firewall. Does UDP also need to be enabled for external?

5

The root & relays need to be able to send UDP commands outgoing and the external clients need to be able to receive UDP from them, but even so if command polling is enabled on the external clients for 900, then that should mean that it should take at most 900 seconds for an action to be found and processed on external clients. It could be that 900 seconds is too aggressive and you need to back that off to something higher.

I have seen cases where the command polling is too aggressive and it interrupts the client too often so it never actually finishes processing the sites.

6

Yah - I do not think that’s the case here as im not seeing anything in the logs - and the envrionment is greenfield, with very little sites - it takes less than two minutes when i restart the client and force the processing.

The root server is not accessible externally - the IP for root/relay on public DNS points to our relay which only allows TCP port 52311. I changed my client to 20 minutes for polling as well, and that didnt work externally.

Everything internally works, when they are not pointing at to the public IP… so it’s something to do with networking I am sure of it… just not sure what?

Kinda lost as to what to try next.

7

Check that the Publicly addressed clients can communicate with a DMZ Relay.

My Server is not externally addressable, but when a client is “outside” and cannot Auto Select a Relay (trace route usually fails), I have a FailOver defined so that a Relay in the DMZ is selected and Command Polling is enabled based on an Open Ended Action. When they return to the internal network, the Command Polling is turned off.

1 Like
8

Also, make sure that your DMZ relays can receive the UDP message otherwise they will never pull it into their cache.

9

Tim,

If you see the logs above, the client is registering with root when the service starts (which is actually the relay IP in DNS)… then the client checks in… but is not processing actions?

The client is reporting the correct “last checked in” time - but will not process open actions… states “Not Reported” for any open action… despite having checked in.

That’s what’s not making sense. Is the client is actually reporting into the DMZ relay… but NOT processing actions… unless i restart the client.

The port TCP 52311 is open to/from the relay… but the DMZ relay does not receive UDP messages externally… shouldn’t the command poll process actions instead?

10

UDP messages do not go from client to relay, only relay to client.

What Tim is saying is that your relay that is pretending to be the root through DNS might not be getting the actions itself. This would be an indication of issues of UDP notifications going from Root to Relay. I bet you need to enable command polling on your relay as well or make sure that the relay is able to get the UDP notifications from it’s parent relay or root.

11

Perfect. Thanks guys. Will give this a shot.

12

There’s a Relay-specific setting similar to the client’s Command Polling setting. See https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings

You may need to configure a value for

_BESRelay_GatherMirror_UpstreamCheckPeriodMinutes

I needed that in a case where the relay could not receive the UDP pings from its upstream relay. Not sure whether this is the case for you - if so I really wouldn’t expect the client to pick up the action when you restart the client service, but it might be worth checking whether it helps.

2 Likes