Better understand of x-bes-fallback-server

[mperretta_gosecure]

Hello,

We’ve configured x-bes-fallback-server to equal something other than the actual root server.
It now equals the TOP relay’s FQDN.

We are in the process of a bigfix migration, migrating endpoints to a new platform via masthead migration.
One specific location is wan bound and has limited access.

After sending the masthead migration job we’ve noticed in the logs that these wan bound machines never speak with the configured x-bes-fallback-server parameter (relay) and are only trying the FDQN of the actual bigfix server.

This leads me to believe that x-bes-fallback-server is not what i think it is?
Should I not see attempts to the value of x-bes-fallback-server?

Please let me know where I’ve gone wrong here, thank you.

[JasonWalker]

I think your understanding is correct, it should work as you expect.

What are the client versions involved? Any chance the existing clients have FailoverRelay or FailoverRelayList client settings in place already that point at your real root name?

[mperretta_gosecure]

Hi Jason, majority of endpoints would be running 9.5.8.38

I can confirm that there is no FailoverRelay or FailoverRelayList client settings in place on these machines, thanks!

[JasonWalker]

Hm. The “Last Fallback Relay” masthead setting was introduced in 9.5.11, I’d have to check whether earlier version clients supported the option.
Would it be possible to upgrade one of those clients and see if it then respects the option? I can check my lab as well but it’ll be some time before I can get to that

[mperretta_gosecure]

Hi Jason, I’ll give it a go and get back to you, thanks!

[mesee2]

Hi Jason - do the updates made via BesAdmin tool to the Masthead only exist in the Masthead that is subsequently exported from the BestAdmin tool?

aka other clients may learn of the setting real time but their local masthead is not going to have the fallback to leverage on startup, unless a manual copy of the recent exported Masthead is copied to the clients?

[mperretta_gosecure]

When making the change via besadmin tool you would then run the syncmasthead action, this should force clients to get the new masthead on the next check-in.

[mesee2]

Where is that “syncmasthead action” is it a task or function in Besadmin tool?

[mperretta_gosecure]

it’s a subset of the besadmin tool.
https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Installation/c_besadmin_linux_cli.html
This is specific to linux deployments and does not need to be run on Windows.

Going over the documentation I was however incorrect it seems when editing the masthead, machines already on the platform will not request a new version nor will bigfix send it out.
See: https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/c_editing_the_masthead.html#c_editing_the_masthead

The last paragraph:
Note: The masthead changes do NOT affect clients that are already deployed, but you can export the masthead using the Administration Tool (Masthead Management tab) and replace the masthead in the BES Installers directory of the BigFix server (default directory: :\Program Files\BigFix Enterprise\BES Installers) so that newly deployed or installed clients use these changes.

[mesee2]

And that is how i understood it, which is why i asked - if the existing clients dont get the new masthead then how do they know on startup of a fall back configuration that was not in their original masthead file when they were installed.

[mperretta_gosecure]

Gotcha, that is a sticky one.

In my case, considering the bigfix migration from platform A to platform B, the masthead provided in the source bigfix instance included the setting, so my issue still remains.

@JasonWalker, the tech who handles these endpoints did not have remote access-in to upgrade the version of bigfix so I don’t have a straight answer for you.

We did DNS masquerading to point the name of the bf host to the wan reachable relay and were able to cut over the missing endpoints.