ネットワークドライブ文字割り当てのベストプラクティス
現在、NovellからActiveDirectoryへの移行に取り組んでいます。移行中、現在の標準に照らしてドライブマッピングを評価し、これまで行ってきたことがまだ適合しているか、ベストプラクティスに沿っているか、リソースの管理を簡素化しているかなどを確認します。現在、11の異なるマップされたドライブマッピング。これは、私には、数が多すぎてエンドユーザーを混乱させるように思われます。これらのドライブマッピングは、組織内に存在していた、次のような古い規則にも関連しているようです。
- K：\-Novellサーバーの物理CD-ROMドライブのマッピング
- N：\-IT管理スクリプトとユーティリティ
- S：\-必要に応じて、別のユーザーのホームフォルダ
- T：\-dBase IIIマッピング（これは移行後に消えることが期待されます）
- U：\-プロジェクトまたは他のグループ共有
- V：\-プロジェクトまたは他のグループ共有
- W：\-作業（部門またはユニットの作業分担）
- X：\-アプリケーション共有
- Y：\-ホームフォルダ
- Z：\-システムボリューム
これは、組織内のエンドユーザーとITの両方のユーザーにとって非常に紛らわしい構造です。業界のベストプラクティスと、他の人がドライブマッピングを設計する方法をお聞きしたいと思います。知っておくべきことは何ですか？また、それらの項目をどのように補償または管理しますか？管理と保守の観点から考慮すべきことは何ですか？
クライアントは、Windows XP、Windows Server 2003、Windows 7 Pro、およびWindows Server 2008になります。後で、LinuxおよびMacintosh OS X（10.6以降）クライアントもドライブマッピングに組み込みたいと考えています。
あなたが提供できるどんな助け、アイデア、リソース、またはリンクも大歓迎です。
私たちは1年半前にまったく同じ理由でこの正確な質問に直面しました。主な問題は3つあります。
- Novellネットワークは、歴史的にドライブ文字ベースです。 U：ドライブはユーザーのホームディレクトリ用であり、S：は共有用であることは誰もが知っています。等々。
- Microsoftネットワークはドライブ文字にあまり接続されておらず、MicrosoftはActiveDirectoryの登場以来UNCスタイルのアドレス指定を推進してきました。老舗のマイクロソフトの家は、ドライブ文字に手元にあるものを使用する傾向があり、ドライブ文字を必要とする古いアプリにはいくつかの標準的な家があります。
- ユーザーは、確立された手順を変更する必要があります。彼らは単にUNCを支持してドライブ文字を横に投げることはなく、「Y：ドライブがダウンしています」とヘルプデスクに電話をかけ続けます。
1と3のため、Microsoftの移行から1年経ってもドライブ文字を使用していました。ユーザーはいくつかの点でUNCアドレッシングに徐々に慣れていますが、SANのサイズ上の理由から、共有ボリュームである大規模なモノリシックボリュームを分割する必要がありました。全員にUNCの処理を強制するのではなく、クラスター内でディレクトリマウントボリュームを実行する方法を考え出しました。
オプションがある場合（Macユーザーが非常に少ない場合など）、MicrosoftDFSを使用するとここで作業がはるかに簡単になります。単一のドライブ文字を作成します。最上位のディレクトリは、基本的に古いドライブ文字のマッピングです。純粋なWindows環境では、これはうまく機能します。ただし、Sambaを使用するものはすべて使用できません。ユーザーは1つのドライブ文字しか持っておらず、14のドライブ文字から「S：\ K-Drive \」のようなパスを持つ1つのドライブ文字への移行は非常に簡単です。 Macユーザーが多いので、このルートに行けませんでした。
ログインスクリプトで標準化したドライブ文字（Novell時代からのもう1つのホールドオーバー）：
- P：=モノリシック共有ボリューム
- S：=生徒の授業量（すべてがBlackboardに移行するにつれて使用量は徐々に減少します）
- U：=ホームディレクトリ
- W：=エンドユーザーソフトウェアリポジトリ
- X：=ネットワークにインストールされた特定のソフトウェアパッケージ。主にERPシステム
- Y：=管理スクリプトなど
また、Windows管理者グループでドライブ文字レジストリを運用しました。ドライブがログインスクリプトにマップされると、誰がそれを実行しているかが文書化されます。これにより、2つの部門がT：ドライブを別の場所にマッピングし、たまたまスタッフを共有したい場合に、多くの悲しみを軽減できます。
私が推奨できる基準は次のとおりです。
- 中央で義務付けられているドライブ文字を最小限に抑えます。
- 管理者調整グループ全体でドライブ文字レジストリを操作する
- 必要に応じて、ドライブマッピングメソッドを予想どおりに定期的に監査します。
私自身の謙虚な意見では、「ドライブ文字」の概念を乗り越えることができれば...それらを完全に忘れてください。 UNCパスを使用すると、さらに多くのことができ、名前の衝突に遭遇することはありません。また、さまざまなサーバー名と共有を1つ（またはいくつか）のDFSルートに統合することもできます。これにより、ユーザーに関連するすべての共有を見つけるために使用できる単一のUNCパスが提供され、レプリケーション、フェイルオーバー、およびスケーラビリティをセットアップするためのオプションが提供されます。
C：をシステムボリュームとして保持します。それがまだ起こるとは信じられませんが、ソフトウェアがC：にインストールするようにハードコードされている場合でも起こります（これらの開発者は撃たれるべきです）。
C：（E：、F：、G :)の後の次の数個は、物理デバイス（CD/DVD、リムーバブルメディアなど）用に予約しておいてください。
それを超えて、私は物事をそれらが始めたものと一致させようとします（明らかに、ドライブマッピングの数が増えるにつれて成功の程度は限られます）。
H：=ホームドライブ
P：=プロジェクトドライブまたはパーソナルドライブ
等...
NETWORKにはN：を使用しています。これは、ユーザーの透過的なフォルダー構造でマルチペルサーバーにまたがるDFS階層にマップされます。
サーバーでは必要に応じて他の文字を使用します（X：= dataa、S = Sql、T = Temp、L = logs-これはサーバー用であるため、TEMPは一時データベースのドライブです）。
通常、ユーザーには常に1つのツリーしか表示されません。技術的な理由で他に2つあります（マップされていません）。
ユーザーのパーソナルドライブには主にP：ドライブを使用します。そしてS：会社の分け前のためのドライブ。これらは、私たちが使用する2つの主要なドライブ文字です。
Active Directoryを使用するための1つの優れた方法は、グループポリシーオブジェクトを使用して、ドライブ文字を受け取るユーザーと受け取らないユーザーを決定することです。ログインスクリプトを設定して、セキュリティグループフィルターに基づいて共有ドライブをマップできます。
たとえば、Q：ドライブにアクセスする必要がある請求部門があります。 Qドライブをマップするためのログインスクリプトを持ち、Billing_security_groupにセキュリティフィルターを適用する新しいGPOをセットアップするので、Qドライブを取得するのはそれらだけになります。
セキュリティグループフィルタリングの詳細については、こちらをご覧ください： http://technet.Microsoft.com/en-us/library/cc781988（WS.10）.aspx
Squillmansの投稿に関する私のコメントを参照してください。
私がサポートする1つの環境では：
- H：ホームドライブ
- G：共通ドライブ（各部門のフォルダーに分割）
- I：ITドライブ
などなど。
また、Windowsに移行するときに、アクセスベースの列挙を実装することをお勧めします。 Novellはこれをネイティブに処理しますが、これにより、ユーザーはアクセスできないファイルやフォルダを見ることができなくなります。
ユーザー固有のディレクトリをマップしないでください。 GPOを使用して、「マイドキュメント」フォルダをネットワーク共有にリダイレクトします。
次に、会社にいくつかのビジネス上の質問をします。人々の働き方、共有/グループレベルでどのような情報を扱っているか。大きなもの（部門、クライアント、プロジェクト）をいくつか選び、ドライブをそれらの各ディレクトリの最上位にマップします。