TruGrid RDS Manager Enterprise - Design Guide

Enterprise Implementation Design Guide

Applies to TruGrid RDS Manager Enterprise 2026.05 and later.

This document describes the recommended design for deploying TruGrid RDS Manager Enterprise in a large organization with many Remote Desktop hosts, and often many sites. It explains what the product is, the pieces that make it up and what each one does, where each piece should live, the network paths between them, and the server sizing we recommend. It is a design guide: it is not an installation walkthrough, a user guide, or an API reference.

1.  What TruGrid RDS Manager Enterprise is
TruGrid RDS Manager Enterprise is on-premises monitoring and management for Windows Remote Desktop environments. It watches every RDS session host and Windows computer you point it at - sessions, logons, performance, application usage, and user experience - and lets administrators act on what they see: message users, log off or shadow sessions, restart computers, and build and maintain pools of virtual desktops on VMware vSphere.

Everything runs inside your network, on your servers, against your Active Directory. The product does not depend on any cloud service: it works with no internet access at all, and no session or telemetry data ever leaves your environment.

A note on naming: throughout this document, "Data Collector" (or "DC") means the RDSM Data Collector service - the product's own server component. It is not an Active Directory domain controller, and it must not be installed on one.

2.  The pieces, and what each one does

3.  How the pieces talk - network requirements
The traffic model is deliberately simple. Agents make one outbound connection each to the Data Collector and keep it open - so monitored hosts need no new inbound firewall rules. Administrator consoles connect to the same two ports on the Data Collector. A few direct actions (restarting a computer, shadowing a session) go straight from the administrator's workstation to the host using standard Windows management paths. All of it is lightweight management traffic: user RDP sessions never touch the Data Collector.

4.  Where the Data Collector lives, and how big to make it
Give the Data Collector its own dedicated, domain-joined Windows Server (2019 or newer) - virtual or physical, either is fine. Install DC Config on that same server: it installs and administers the local Data Collector service, so the two belong together. Do not co-locate the Data Collector on an Active Directory domain controller or on a session host that users sign in to. For day-to-day user, do not co-locate the Enterprise Client on the Data Collector server.

• Keep steady-state CPU and memory under 70%. Headroom is what absorbs logon storms and large pool builds.
• The database looks after itself. The built-in database keeps detailed history for 45 days and compact long-range summaries beyond that, so it stays bounded - plan tens of GB at large scale, not hundreds. Back up the data volume like any other server.
• Disk speed matters more than disk size. Telemetry from a large fleet is a steady stream of small writes; give the database volume high IOPS.

5.  Enterprise topology - one Data Collector, or one per site?
Recommended: one central Data Collector
For most enterprises - including multi-site, multi-datacenter networks - one central Data Collector is the right design. Agent traffic is lightweight telemetry, and every agent connects outbound, so hosts at remote sites reach the central DC across the WAN without any inbound openings at the sites. Administrators get one console that sees the entire fleet.

Alternative: one Data Collector per site
Some organizations prefer each site to be self-contained: its own Data Collector, monitoring only its own hosts, with no monitoring traffic on the WAN at all. Administrators still use one Enterprise Client - they switch it between Data Collectors to view each site.

Be clear about what this design is: Data Collectors are fully independent installations. Each keeps its own database, its own settings, and its own access list. Nothing is shared or replicated between sites - and nothing needs to be, because each site's Data Collector monitors only that site's computers and therefore holds only that site's history. There is no cross-site roll-up and no combined reporting across Data Collectors.

Choosing between them

6.  Security design

• Who can administer is decided by Active Directory. Administrators sign in with their own AD accounts. Each listed person or group holds one role: Admin (everything), Image Operator (VM Pools and images, no configuration), or Help Desk (day-to-day session support, no pools, no configuration). If the access list is empty, all console connections are refused.
• Connections are encrypted and identity-checked. The Data Collector serves HTTPS with a certificate. Agents remember ("pin") that certificate and refuse to talk to an impostor; the Enterprise Client remembers it on first connect and warns loudly if it ever changes. Certificate updates are pushed to connected agents from DC Config in one click - no manual touch on each host.
• Credentials are protected at rest. vCenter and service-account credentials are encrypted on the Data Collector with Windows machine-bound encryption (DPAPI). They are never sent to Enterprise Clients.
• Everything is audited. Every administrative action and every VM Pool operation - including failures - is written to the Audit Log with who, what, when, and the outcome.
• The attack surface is small. No inbound internet exposure is required anywhere. Monitored hosts accept no new inbound connections for agent-based monitoring. The Data Collector listens on exactly two ports, reachable only from your management and host networks.
• Service accounts follow least privilege. The optional VM Pools AD account needs rights only over the organizational unit that holds pool computers - not domain admin, not anything wider.

7.  Designing for VM Pools (optional)
VM Pools turn the Data Collector into a builder and caretaker of virtual desktops on VMware vSphere. If you plan to use them, add these items to the design:

• One vCenter connection per Data Collector. Registered in DC Config with its own credentials (encrypted at rest). Large environments can allow parallel pool operations per vCenter; the default is one pool operation at a time.
• Placement is chosen, not guessed. When a pool is created, the administrator picks the compute resource (cluster or host) and the resource pool; the datastore and network lists are then filtered to what that compute resource can actually reach. In multi-cluster vCenters with cluster-local storage (such as vSAN), this filtering is what prevents a pool from being placed somewhere its storage cannot follow.
• Two kinds of pools. Persistent pools are full clones - each user keeps the same desktop and their changes survive. Non-persistent pools are linked clones that reset to a clean baseline when recycled - RESET, RESET on drain, or scheduled RESET discards all session changes.
• AD organizational unit. Pool desktops are created in, joined to, and removed from that OU automatically. For non-persistent pools, disable machine-account password changes by Group Policy on that OU so a desktop restored to its baseline can still authenticate to the domain.
• Master images stay yours. A pool is built from a template, VM, or snapshot you prepare and generalize. Keep master images on storage every target compute resource can reach.

8.  Quick reference

Planning a deployment?
If you are designing an enterprise deployment and want a second pair of eyes on your topology - site layout, fleet size, VM Pools placement, or anything in this document - contact TruGrid support and we will walk through it with you.

Updated on: 03/08/2026