Multi-site Remote Desktop Services platform

I designed, deployed, and documented a two-site Remote Desktop Services platform. The primary site runs a DMZ-isolated gateway in front of two session-host collections: a general-access collection and a dedicated host giving the line-of-business accounting application a stable, isolated home. A second, single-server deployment at a regional site adds an HTML5 web-client fallback for users on network paths that are hostile to persistent RDP tunnels, including remote contractors on constrained corporate network stacks who can reach a browser but not a stateful RDP tunnel. Two dedicated engineering workstations also tunnel through the primary gateway over RDP, outside the RDS session-host role entirely. The whole platform is fully written up so it can be operated and recovered from documentation.

Architecture

• Split-role deployment (primary site). The RDS roles (Gateway, Connection Broker, Web Access, and Licensing) run with the gateway isolated in a DMZ and two session-host collections on the internal network: a general-access collection and a dedicated host for the accounting line-of-business application.
• Single-server deployment (regional site). A consolidated deployment where the roles and session host are co-located on one server, right-sized for the smaller regional user base.
• Dual client access. Users connect through either the native Remote Desktop client or an HTML5 web client, the latter serving as a fallback at the regional site for remote contractors on network paths that block persistent RDP tunnels.
• Non-session-host access. Two dedicated engineering workstations tunnel through the primary gateway over RDP without consuming a session-host slot or an RDS CAL.

Security and certificates

• DMZ isolation. The gateway is isolated from the internal network, with a defense-in-depth posture and a deliberately minimized attack surface.
• Connection and resource authorization policies control who can reach the gateway and which internal resources they can then reach.
• Automated certificate lifecycle. Public TLS is fronted with certificates auto-renewed through Certify The Web using Let's Encrypt with Cloudflare DNS-01 validation, so the gateway and web client certificates rotate without manual intervention.

Operations

• Group Policy governs the session-host experience (profile handling, printing, storage, and update behavior).
• Capacity planning is documented per session host, with headroom and scaling options called out.
• Full runbook-grade documentation covers architecture, gateway and session-host configuration, client setup, user management, and a troubleshooting guide, including the regional single-server variant.

What this demonstrates

• End-to-end platform ownership from architecture and deployment through certificate automation, capacity planning, and operational documentation.
• Security-conscious design DMZ isolation, authorization policies, and attack-surface minimization on an internet-facing service.
• Right-sizing to context a split-role deployment where scale warrants it and a consolidated single-server deployment where it does not.