In our environment, we have all clients(desktops and servers) configured for manual relay selection. But over the course of time, many started reporting to main server. I am manually taking them back to where they belong…
But one doubt - is there anyway, we can restrict client reporting to the main server directly?
Dilu,
In our environment we just have an open policy that reconfigures incorrectly configured clients.
The issue with restricting clients access to report directly to the server (Which you could do via the firewall by blocking 52311 from client networks) is that if a client does fall back to reporting to the server for whatever reason it won’t be able to report at all and it will fall off the map.
The next step might be to figure out why the clients are resetting their relay values and fix that first!
What does the policy do? Just a “relay select”?
I have tried forcing a relay select, sometimes it will still report to main server. (but I do not doubt any issue on the low level relays).
Would it be a good idea to configure any of the top level relay as “fail over relay”? Currently we have 2 relays (primary and secondary) set uped in same subnet.
We have an open policy, like what strawgate mentioned, that keeps our clients configured. They are configured during a baseline when a new system comes online and maintain those settings. We currently have our non-relay clients pointed to a local relay, with a top level relay as it’s secondary and our relays load balanced across 2 top level relays with a backup. Maybe check your open tasks and see if something is there you aren’t aware of.
Also, I will mention that we are on a closed network with various levels of segmentation. Our top level relays I have configured in our DC and they are the only 2 that talk with the root server. We noticed a pretty significant increase in the performance of the product (though your mileage may vary) by setting up our throttling, gather times, heartbeat setting, and not allowing it to hop around our network looking for a relay by forcing the manual selection. Just mentioning mentioning all of this to paint you a clearer picture.
Are you saying that you have a relay configured but your clients are reporting to your BES Root Server? Or are you saying that you configure a relay on the client and you come back later and on some of the clients the relay is no longer configured?
The best option to prevent this is called “fake root” or “hidden root”
I don’t know all the specifics and caveats, but basically you create a “Super Top Level Relay” and you give it the FQDN of what the root server has and then point that same domain at the actual IP of the root server in the “Super Top Level Relay”'s hosts file.
- Move content downloading to a Relay
- Interconnect 2015: Stanford University - Securing your IEM infrastructure
This approach has a few security and performance benefits by shifting load to a single “Top Level Relay” which can be swapped out or upgraded much more easily than the root server itself.
I would recommend 10gig (or better) networking between the “Super Top Level Relay” / “fake root” and the actual root server.
2 Likes
We have relay configured. But still it is reporting to main server. I have seen with so many clients. Troubleshooting individual workstations would be a tedious task.
Earlier we had just one local (same location/subnet) relay and secondary pointing to main or a top level relay. I am planning to have 2 relays at each location and primary and secondary. May be configuring failover relay as Top layer relay(?). So that the chance of failing back to root server is less.