Multi-site brokering - Pros and cons of multi-Sentry deployments

TruGrid offers two brokering paths for Remote Desktop access:

• Sentry: a server-installed broker running on or alongside a domain controller. Handles SSO and brokers RDP sessions for AD-joined machines reachable on its network.
• SecureConnect: an agent installed directly on the target Windows machine. Each agent brokers its own connection to the TruGrid cloud over outbound TLS, with no Sentry involvement.

This article explains how the two paths behave in multi-site deployments and which pattern to use when.

How Sentry selects a broker

When a user clicks Connect to a Sentry-brokered machine, the TruGrid web service issues a broker request. Every online Sentry registered to the user's domain is asked. The first Sentry to respond becomes the broker for that session.

Two behaviors follow from this:

• Sentries are not aware of each other across networks. Their coordination uses TCP broadcast, which does not cross routed boundaries.
• Sentry selection is not topology-aware. The winning Sentry is not necessarily the one closest to the target Remote Desktop.

For SecureConnect-brokered machines, no selection happens. The agent on the target machine is the broker.

The multi-site assumption: site-to-site VPN

If your sites share an Active Directory domain, a site-to-site VPN between them is required. Active Directory authentication, replication, DNS, and SMB depend on it. Once that VPN is in place, every Sentry can reach every Remote Desktop in the domain regardless of physical location. That is what makes the multi-site brokering question interesting.

Scenario A: Single site (recommended baseline)

One or two Sentries on the same network as your Remote Desktops. Sentries coordinate via broadcast, automatic failover works as designed, brokering latency is consistent. This is the deployment most organizations should start with.

Scenario B: Sentry at each site over S2S VPN

Both Sentries are online. A user at Site A clicks Connect to a Remote Desktop at Site A. The broker request reaches both Sentries. If Sentry B wins the race, the entire RDP session is brokered from Site B across the S2S VPN to the target at Site A, then relayed back to the user through the TruGrid cloud.

Worst-case cost of cross-site brokering:

• 2-3 additional network hops compared to the local-Sentry path
• RDP session traffic consumes S2S VPN bandwidth for the duration of the session
• Connection setup and session latency reflect the slower of the two Sentry paths

This works. Sessions are not broken. The trade-off is unpredictable performance and a VPN that is now carrying real-time session traffic it may not have been sized for. Acceptable for small deployments with light usage. Worth reconsidering as user counts grow.

Scenario C: SecureConnect at remote sites (recommended for distributed orgs)

Install the TruGrid SecureConnect agent on each Remote Desktop at the remote site. Once activated against your TruGrid domain, the machines broker their own connections directly to the TruGrid cloud over outbound TLS. The S2S VPN drops out of the RDP session path entirely.

Result:

• No cross-site brokering
• No RDP session traffic on the S2S VPN. The VPN continues to carry AD replication, DNS, and authentication only.
• Session latency reflects the local network path from each Remote Desktop to the TruGrid relay, not the path through a remote Sentry.
• The primary site keeps Sentry brokering for its local Remote Desktops, including the SSO experience and pooled assignments.

Trade-offs:

• SecureConnect does not provide SSO unless all the prerequisites for Microsoft 365 SSO are met. On first connection, the user is prompted for credentials to the target machine. The "Remember Me" option persists those credentials for future sessions.
• Each Remote Desktop runs its own agent. For larger remote sites, deploy the agent in bulk using silent install.

Scenario D: Sentry and SecureConnect on the same machine

A single Remote Desktop can be brokered through both Sentry and SecureConnect simultaneously. See Utilizing Sentry and SecureConnect brokering for accessing the same machine for use cases such as bypassing SSO with alternate credentials.

Quick reference

Roadmap note

TruGrid is evaluating topology-aware Sentry selection, which would factor the network path to the target Remote Desktop into the broker decision. Until that ships, the patterns above represent current best practice.

If you are unsure how your deployment maps to these scenarios, contact TruGrid support and we will review your topology with you.

Updated on: 12/05/2026