I've noticed that all of our clients are registering directly through our relay defined as the x-bes-fallback-server. They do not check for the root server, or any of the internal relays, and instead reach out only to this one.
If I modify the hosts file on the device to point the x-bes-fallback-server to localhost, the agent is unable to enroll and never tries to connect to anything except the x-bes-fallback-server.
On one example device, I can successfully reach out to the root server using the registration URL, e.g.
so there should be no reason network-wise why the client doesn't reach out, it just never does.
What determines where clients will attempt to register, and how can we get them to try the root server, or another relay first, and then fall back to something else?
By design, the fallback Relay as defined in the masthead is meant to replace the Root Server as the last fallback option that Clients will try to register with if no other option is provided and/or available (see Editing the Masthead on Windows systems for reference). This can help in a number of ways, but primarily, it's meant to shield the BigFix Root Server in failure cases.
As to your question:
Are you asking about newly installed Clients or existing Clients? Are you leveraging Manual Selection, or Automatic Selection? This is a broad topic, but here's a link to related documentation: Assigning relays to clients
Thanks Aram. This is only in reference to new devices. For existing devices, we use automatic selection with relay affiliation, and that is all working fine.
I was just under the impression that defining an x-bes-fallback-server implied there was something to be tried first (during enrollment), before "falling back". I'm not seeing new clients attempt to reach out to anything other than the x-bes-fallback-server.
I think so, yes. Thank you. We're switching the server that was defined as our x-bes-fallback-server to authenticating, so we'll need to swap it out for one that isn't.
