我想做的事情非常复杂，所以我想我会把它扔给更广泛的观众，看看是否有人能找到缺陷。我正在尝试做的（作为 MSP/VAR）是设计一个解决方案，该解决方案将仅使用少数服务器为多家公司提供基于会话的远程桌面（需要完全独立的公司）。这就是我现在的想象：
- 核心服务器 - Server 2012 Datacentre（以下均为 HyperV 服务器）
Server1：Cloud-DC01（mycloud.local 的 Active Directory 域服务）
Server2：Cloud-EX01（运行多租户模式的 Exchange Server 2010）
Server3：Cloud-SG01（远程桌面网关） - 核心服务器 2 - Server 2012 Datacentre（以下均为 HyperV 服务器）
Server1：Cloud-DC02（mycloud.local 的 Active Directory 域服务）
Server2：Cloud-TS01（公司 A 的远程桌面会话主机）
Server3：Cloud-TS02（远程B 公司的桌面会话主机
Server4：Cloud-TS03（C 公司的远程桌面会话主机）
我想做的是在他们自己的 OU 中设置每个组织（可能基于 Excahnge 2010 租户 OU 结构创建他们的 OU 结构，以便链接帐户）。每家公司都将获得一台远程桌面会话主机服务器，该服务器也可用作文件服务器。该服务器将在其自己的范围内与其他服务器分开。服务器 Cloud-SG01 可以访问所有这些网络，并在客户端连接并通过身份验证时将流量路由到适当的网络，以便将它们推送到正确的服务器上（基于 2012 年的会话收集）。
我不会撒谎，这是我很快想出的东西，所以很可能有一些非常明显的东西是我遗漏的。对于任何反馈，我们都表示感谢。
这与我们所做的非常相似。我们有一个所有客户都通过的 TS 网关。它具有控制哪些用户组可以登录到哪些服务器的连接和资源策略。
每个公司都有自己独立的终端服务器。大多数公司只能登录一个TS，但是对于一个特别大的客户，他们有两个。我们不对它们进行任何聚类，只有一半用户连接到 TS1，另一半连接到 TS2。
所有的服务器都位于同一个网段，我们有非常严格的 ACL 来定义谁可以去网络上的哪里（即没有人可以真正去任何地方）。我们的 RDS 服务器 GPO 也极大地限制了它们在服务器本身上的位置。
我们在这个设置中遇到的最大问题是为新客户自动部署服务器。大部分过程可以自动化（我们使用ESXi和vSphere，它有powershell集成。和Hyper-V一样），但我还没有找到如何自动化修改TS网关策略。
我们还有一个非常大的客户使用我们托管的终端服务器。因为我不想自己管理他们所有的密码重置和新帐户，所以我们授予他们对域中自己的 OU 的委派权限。当他们开始长大时，出于政治原因，我们在我们的森林下给了他们自己的领地。到目前为止，这一切都工作得很好，除了你不能使用它，
User must change their password on next logon因为它与 TS 网关不兼容。当他们的密码过期时也是如此，他们无法登录，需要有人手动重置密码。