私は現在、それがかなり単純なプロジェクトであるはずであるように思われるもので地獄の時間を過ごしています。
基本的に、$employer
には、実サーバーになりすました古いハードウェアを備えた多数のリモートサイトがあり、それらは実サーバーに置き換えられています。または、より正確には、彼らは新しいサーバーを購入し、私にそれらを交換する作業をさせています。サイトは一般的に小さいので、それほど複雑ではありません。基本的には、すべてのサイトにファイルサーバー、印刷サービス、およびドメインコントローラー/ DHCPサーバーを提供するだけです。
もちろん、問題はユーザープロファイルのリダイレクトを行うことから生じます。すべてのユーザーは、My Documents
ディレクトリをファイルサーバーにリダイレクトします(例:\\[crappy-old-server]\users\%username%
)。私たちは物事を正しく行おうとしているので、新しいサーバーにDFSをセットアップし、それを\\[not-crappy-DFS-root]\[sitename]\users\%username%
に変更しています。
その部分はかなりうまく機能しており、 Microsoftファイルサーバー移行ツールキット を使用してファイルサーバーを移行した後、 csccmd を実行して、クライアントマシン上の共有を新しい場所にポイントします。 Active Directoryとグループポリシー(マップされたドライブ、プリンターなど)のいくつかを変更し、それを1日と呼びます。
ただし、問題は、csccmdツールが古いサーバーへのレジストリ参照のsomeを移動している間、クライアントレジストリは依然として不良リンクでひどいことです。 (MRU、ビットバケットリサイクラーパス、プリンター、アプリケーションのデフォルト、マウントポイント、シェルフォルダー、ネットキャッシュなど)、その結果、一部の設定が表示されているため、ユーザーはネットワークタイムアウトを取得せずにスタートメニューを開くことさえできません。 \\[crappy-old-server]\users\%username%
ではなく\\[not-crappy-DFS-root]\[sitename]\users\%username%
にあるものの場合。ほとんど何でもするのに文字通り少なくとも30秒かかりますが、これは受け入れられません。
これを解決するために、各クライアントマシンで手動で、regeditを開き、古いサーバー文字列を検索し、見つかった場合は、キーを削除するか、古いサーバー名を新しいDFSパスに置き換えました。これは明らかにsucksであり、現在のソリューションはまったく拡張できないため、もっと良い方法が必要だと考えています。大規模なユーザー移行では、この問題に対してより自動化されたアプローチを使用している必要があります。
では、クライアントレジストリを手動で検索する必要がない、これを行うためのより良い方法は何でしょうか。
\\[crappy-old-server]\users
に応答するマシンをスタンドアロンのDFSルートとして各サイトに配置できます。users
は新しい\\[not-crappy-DFS-root]\[sitename]\users
フォルダーへのDFSリンクです。 OptionalNames
という名前の共有がまだない場合は、users
を使用して各サイトに展開しているサーバーを使用できる場合があります。