500ユーザー未満、4か所のActive Directory OU設計

（Win 2003）AD階層に論理構造を追加しようとしています。単一のドメインと約500人のユーザーがいます。現在、すべてのユーザーとコンピュータは1つのOUに編成されています。すべてのセキュリティグループと配布グループは2番目のOUにあります。グループメンバーシップは基本的に、グループのネストを持たない個々のユーザーベースです。

私の質問：

1. このサイズの組織では、部門、地理、オブジェクトクラス（つまり、コンピューター、ユーザー、グループ）に基づいてOUの階層を設計し、ユーザー、コンピューター、グループを関連するOUに移動する価値はありますか？
2. もしそうなら、どのように階層を構造化しますか？たとえば、department-> location-> object class？
3. エンタープライズアプリケーションロールとExchangeアドレスエントリへのより適切なマッピングのために、必要に応じてグループをネストする必要がありますか？

以下は、ADの論理設計に関するMicrosoftの推奨事項の中核となる原則です。

• 制御の委任のために最初に設計します。これは、AD権限に基づいており、変更が最も柔軟性のない軸であるためです。制御の委任を行わない場合は、これについて心配する必要はありません（ただし、とにかく計画を立てます。小規模な組織であっても、ブランチオフィスの指定されたユーザーがパスワードをリセットできる必要がある場合があります。等）。

• グループポリシーを適用するための2番目の設計。セキュリティグループメンバーシップによってグループポリシーアプリケーションをフィルタリングすると、GPOは、ディレクトリでリンクされているポイントの下のユーザーオブジェクトまたはコンピューターオブジェクトのサブセットのみに適用できるため、この軸はADアクセス許可よりも柔軟性があります。

• 最後に、整理と使いやすさを考慮して設計します。自分や他の管理者が簡単に見つけられるようにします。

設計時にこれらの考慮事項のそれぞれについて検討し、推奨事項に優先順位を付けます。後で（比較的）変更するのは簡単で、最初の試行で "正しく理解"することはできません。最初のドメインコントローラーをDCPROMOする前に、通常、提案された構造を紙またはホワイトボードに描画し、潜在的な使用シナリオをウォークスルーして、設計が「遅れる」かどうかを確認します。これは、デザインの問題を取り除くための優れた方法です。

（サイトオブジェクトのグループポリシーアプリケーションについても忘れないでください。サイトでGPOをリンクするときは、クロスドメインGPOアプリケーションに注意する必要がありますが、単一ドメイン環境の場合、多くの優れた機能を利用できます。 GPOをサイトにリンクしない機能。それを使用していくつかのサンプルシナリオを実行します。「サイト固有の」設定が含まれているソフトウェアをロードしたり、特定のコンピューターにログオンするときにユーザーに特定のログオンスクリプトを提供したりするのに最適です。ループバックグループポリシー処理による物理的な場所。）

管理が容易になるという単純な理由から、ユーザー、コンピューター、グループは常に別々のOUに分割しました。

特定のAD構造に説得力のある理由がない場合は、管理の観点からADを設計します。ポリシーを適用する場所について考えます。

ほとんどのポリシーを部門レベルで適用する場合は、Department \ Location \ Objectを使用します

ほとんどのポリシーを場所レベルで適用する場合は、Location \ Department \ Objectを使用します

逆の場合は、複数のOUでポリシーをリンクする必要があり、不要な作業が必要になります。

グループのネストは完全に問題なく、ADの管理がはるかに簡単になります。

私は、物理的な企業構造を反映するのではなく、「管理を容易にする」ことを念頭に置いてAD構造を設計する傾向がありますが、どちらも同じであることがよくあります。

ADを再設計する必要がある場合、私は別の方法でいくつかのことを行う必要があると思いますが、次のことがわかりました。

ユーザー-論文を部門に分割しますが、臨時または代理店のスタッフ用のエリアも用意します。これらの場所は、間違いなく人々が移動するほど重要ではありません。

コンピュータ-これらを場所とサブ場所に分割します。つまり、OfficeComputers / LondonOffice / Room103（ファイナンス）です。つまり、1つの場所またはオフィスに設定を適用できます。たとえば、別のプロキシサーバーや別のアンチウイルス設定（もちろん、AV管理プログラムがADを使用している場合のみ）で、再編成する必要はありません。ループバック処理であるワームの缶。

また、組み込みのユーザーグループやコンピューターグループを使用しないこと、技術的な問題ではなく、本来あるべきでない場所を簡単に確認できるようにすることも役立ちました。

最後に、サーバーも分割します。非常にうまく機能しているように見える場所/役割を探しました。

それはすでに答えられているので、ここに小さな例の私の見解を示します。あなたがそれがすべてニーズに依存する正しいか間違っているというわけではないことを覚えておいてください-つまり、最初に組織か場所か？コンピューター/サーバーの役割でも、最初に組織の役割を優先します。また、単一のOUを指摘してすべての従業員を取得し、イントラネットの従業員リストを作成するためにゴミを出さないようにする機能も気に入っています。自由に編集してください！

• People（users / type = person）
  • 内部
    • 部門A
      • 場所X
      • 場所Y
    • 部門B
    • 部門C
  • 外部
    • 会社1
    • 会社2
• マシン（ユーザー/タイプ=コンピューターを含むすべて）
  • クライアント
    • ラップトップ
    • デスクトップ
  • サーバ
    • 応用
      • 場所T
      • ロケーションV
    • インフラ
    • データベース
  • サービス
  • 管理アカウント（使用する場合）
• リスト（グループと連絡先）
  • 連絡先
  • 分布
  • 安全保障

この場合は、場所でそれらを分割します。結果のOU構造は次のようになります。

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

等

ここでは、たとえば部門などでさらに分割する必要はないと思います。実際に多くの見返りを与えることなく追加の管理オーバーヘッドを生成するためです。ただし、場所で分割すると、各サイトで委任を実装できます。

私が使用するガイドラインは次のとおりです。ユーザー。HRチャートフローグループに従って整理します。ワークフローコンピュータに従って整理します。地理的な場所に従って整理する

このスレッドの他の答えも非常に良いです。