1つのActiveDirectory、複数のリモートデスクトップサービス（Server 2012ソリューション）
私がやろうとしていることは非常に複雑なので、誰かが欠陥を見つけることができるかどうかを確認するために、それをより多くの聴衆に投げ出すと思いました。私が（MSP/VARとして）やろうとしているのは、少数のサーバーのみを使用して、複数の企業にセッションベースのリモートデスクトップ（完全に分離しておく必要のある企業）を提供するソリューションを設計することです。これは私が現時点でそれを想像する方法です：
- コアサーバー-サーバー2012データセンター（以下はすべてHyperVサーバーです）
Server1：Cloud-DC01（mycloud.localのActive Directoryドメインサービス）
Server2：Cloud-EX01（マルチテナントモードを実行しているExchange Server 2010）
Server3：Cloud-SG01（リモートデスクトップゲートウェイ） - コアサーバー2-サーバー2012データセンター（以下はすべて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年のセッションコレクションに基づく）。
私はこれが私が非常に迅速に思いついたものであると嘘をつかないので、私が欠けていることは明らかに明白な何かがあるかもしれません。フィードバックをいただければ幸いです。
これは私たちがしていることと非常に似ています。 allクライアントが通過する単一のTSゲートウェイがあります。これには、どのユーザーグループがどのサーバーにログオンできるかを制御する接続ポリシーとリソースポリシーがあります。
各企業には、独自の自己完結型ターミナルサーバーがあります。ほとんどの企業は1つのTSにしかログオンできませんが、特に大規模なクライアントの場合、2つあります。それらのクラスタリングは行いません。ユーザーの半分だけがTS1に接続し、残りの半分はTS2に接続します。
すべてのサーバーは同じネットワークセグメント上にあり、ネットワーク上のどこに誰が行くことができるかを定義するための非常に厳密なACLがあります（つまり、誰も実際にはどこにも行くことができません）。 RDSサーバーのGPO）も、サーバー自体のどこに移動できるかを大幅に制限します。
このセットアップで発生する最大の問題は、新しいクライアント用のサーバーの自動展開です。ほとんどのプロセスは自動化できますが（PowerShellと統合されたESXiとvSphereを使用します。Hyper-Vと同じです）、TSゲートウェイポリシーの変更を自動化する方法をまだ見つけていません。
また、ホストされているターミナルサーバーを使用する非常に大規模なクライアントが1つあります。パスワードのリセットと新しいアカウントをすべて自分で管理する必要がなかったため、ドメイン上の自分のOUに対する委任権限を付与しました。彼らがそれを超え始めたとき、政治的な理由で、私たちは彼らに私たちの森の下に彼ら自身のドメインを与えました。これはTSゲートウェイと互換性がないため、User must change their password on next logonを使用できないことを除いて、これまでのところすべてうまく機能しています。パスワードの有効期限が切れると、同じ取引が行われ、ログオンできなくなり、誰かがパスワードを手動でリセットする必要があります。