USMT のベスト プラクティス
この記事では、ユーザー状態移行ツール (USMT) を使用する場合の一般的なセキュリティ関連のベスト プラクティスについて説明します。
一般的なベスト プラクティス
LoadState ツールを実行する前に、アプリケーションをインストールします。
必ずしも重要であるとは限りませんが、ユーザーの状態を復元する前に、すべてのアプリケーションを移行先コンピューターにインストールすることをお勧めします。 ユーザー状態を復元する前にアプリケーションをインストールすると、移行された設定が確実に保持されます。
MigUser.xml と MigDocs.xml を一緒に使用しないでください。
MigUser.xmlとMigDocs.xmlの両方を同時に使用する場合、ターゲットの場所に関して競合する手順が指定されている場合、移行されたファイルの一部を複製できます。/genmigxmlコマンド ライン オプションを使用すると、移行に含まれるファイルを判断したり、変更が必要かどうかを判断したりできます。 詳細については、「 ファイルの種類、ファイル、およびフォルダーを識別する」を参照してください。移行エクスペリエンスを向上するために MigDocs.xml を使用します。
データ セットが不明な場合、または多数のファイルが標準のユーザー プロファイル フォルダーの外部に格納されている場合、
MigDocs.xmlファイルはデータの範囲を広く収集するため、MigUser.xmlファイルよりもMigDocs.xmlファイルの方が適しています。MigDocs.xmlファイルは、登録されたアプリケーション拡張機能についてレジストリにクエリを実行することで、場所と登録されたファイルの種類に基づいてデータのフォルダーを移行します。MigUser.xmlファイルは、指定されたファイル拡張子を持つファイルのみを移行します。ScanState ツールまたは LoadState ツールを実行する前に、すべてのアプリケーションを閉じます。
/vscスイッチを使用すると、別のアプリケーションで開いている多くのファイルを移行できますが、すべてのファイルと設定を確実に移行するには、すべてのアプリケーションを閉じるのがベスト プラクティスです。/vscまたは/cスイッチがないと、ファイルまたは設定を移行できない場合、USMT は失敗します。/cオプションを使用すると、USMT は、移行できないファイルまたは設定を無視し、毎回エラーをログに記録します。LoadState を実行した後にログオフします。
フォント、壁紙、スクリーンセーバーの設定など、一部の設定は、ユーザーが次回ログオンするまで有効になりません。 このため、 LoadState ツールを実行した後にサインアウトします。
マネージド環境。
マネージド環境を作成するには、エンド ユーザーのすべてのドキュメントを Documents フォルダー (%CSIDL_PERSONAL%) に移動できます。 Microsoft では、ファイルを移行先のコンピューター上の最小数のフォルダーに移行することをお勧めします。 フォルダーを最小化すると、完了前に
LoadState.exeコマンドが失敗した場合に、コピー先コンピューター上のファイルをクリーンアップするのに役立ちます。Chkdsk.exe。
Microsoft では、ScanState ツールと LoadState ツールを実行する前に、Chkdsk.exe を実行することをお勧めします。 Chkdsk.exe は、ハード ディスク ドライブの状態レポートを作成し、一般的なエラーを一覧表示して修正します。 Chkdsk.exe ツールの詳細については、「Chkdsk」を参照してください。
グループで移行します。
ユーザーがネットワークを使用しているときに移行を実行する場合は、グループ内のユーザー アカウントを移行することをお勧めします。 ネットワーク パフォーマンスへの影響を最小限に抑えるには、各ユーザー アカウントのサイズに基づいてグループのサイズを決定します。 フェーズで移行すると、次のフェーズを開始する前に各フェーズが成功することを確認することもできます。 この方法の場合は、グループ間のプランに必要な変更を加えることができます。
セキュリティのベスト プラクティス
承認された管理者は、移行中と移行後にユーザーのプライバシーを保護し、セキュリティを維持する責任があります。 特に、次の問題を考慮する必要があります。
ファイル システム (EFS) の暗号化。
暗号化されたファイルを移行するときは、エンド ユーザーがユーザーの状態をキャプチャするためにログオンする必要がないため、細心の注意を払ってください。 既定では、暗号化されたファイルが見つかった場合、USMT は失敗します。 EFS のベスト プラクティスに関する具体的な手順については、「 EFS ファイルと証明書の移行」を参照してください。
注
証明書も移行せずに暗号化されたファイルが移行された場合、エンド ユーザーは移行後にファイルにアクセスできません。
ストアを暗号化します。
ScanState.exeコマンドで/encryptオプションを使用し、LoadState.exeコマンドで/decryptオプションを使用することを検討してください。 ただし、ScanState.exeコマンド ライン スクリプトにアクセスできるユーザーも暗号化キーにアクセスできるため、このオプションのセットには細心の注意を払ってください。ウイルス スキャン。
MICROSOFT では、USMT を実行する前に、ソース コンピューターと移行先コンピューターの両方でウイルスをスキャンすることをお勧めします。 さらに、対象のコンピューター イメージをスキャンする必要があります。 ウイルスからデータを保護するために、移行前にウイルス対策ユーティリティを実行することを強くお勧めします。
ファイル サーバーとデプロイ サーバーのセキュリティを維持します。
Microsoft では、ファイル サーバーとデプロイ サーバーのセキュリティを管理することをお勧めします。 ストアが保存されているファイル サーバーが安全であることを確認することが重要です。 また、ログ ファイル内のユーザー データが公開されないように、デプロイ サーバーもセキュリティで保護する必要があります。 また、Microsoft では、仮想プライベート ネットワークなどのセキュリティで保護されたネットワーク接続経由でのみデータを送信することをお勧めします。 ネットワーク セキュリティの詳細については、「 Microsoft Security Compliance Manager」を参照してください。
パスワードの移行。
エンド ユーザーのプライバシーを確保するために、USMT は、アプリケーションやマップされたネットワーク ドライブのパスワードなど、パスワードを移行しません。 エンド ユーザーが自分のパスワードを認識していることを確認することが重要です。
ローカル アカウントの作成。
ローカル アカウントを移行する前に、 ユーザーの識別 に関する記事の「ローカル アカウントの移行」セクションを参照してください。
XML ファイルのベスト プラクティス
ScanState ツールと LoadState ツールの両方で、同じ mig*.xml ファイルのセットを指定します。
特定の mig*.xml ファイルのセットを ScanState ツールで使用する場合は、
/autoオプションを使用するか、/iオプションを使用して個別に呼び出す場合は、同じオプションを使用して LoadState ツール内のまったく同じ mig*.xml ファイルを呼び出す必要があります。移行 urlid の <CustomFileName> は、ファイルの名前と一致する必要があります。
要件ではありませんが、 <CustomFileName> ファイルの名前と一致することをお勧めします。 たとえば、次の例は、
MigApp.xmlファイルの例です。<?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp">.xml ファイルを作成するときに XML スキーマ (MigXML.xsd) を使用して構文を検証します。
MigXML.xsdスキーマ ファイルは、コマンド ラインや .xml ファイルには含めてはいけません。既定の移行 XML ファイルをモデルとして使用します。
カスタム .xml ファイルを作成するには、移行 .xml ファイルをモデルとして使用して、カスタマイズされたバージョンを作成できます。 ユーザー データ ファイルを移行する必要がある場合は、
MigUser.xmlでカスタム .xml ファイルをモデル化します。 アプリケーション設定を移行するには、MigApp.xmlファイルのカスタム .xml ファイルをモデル化します。<context> パラメーターを使用する場合は、パフォーマンスへの影響を考慮してください。
<context> 要素を <component> 要素と共に使用すると、移行のパフォーマンスが影響を受ける可能性があります。 たとえば、ファイルベースまたはパスベースの<>および<exclude>ルールの論理ユニットをカプセル化する場合です。
ユーザー コンテキストでは、システム上のユーザーごとにルールが 1 回処理されます。
システム コンテキストでは、ルールがシステムに対して 1 回処理されます。
UserAndSystem コンテキストでは、ルールはシステム上のユーザーごとに 1 回、システムに対して 1 回処理されます。
注
ルールが処理される回数は、ファイルが移行された回数には影響しません。 USMT 移行エンジンは、各ファイルが 1 回だけ移行されるようにします。
Microsoft では、既存の移行 .xml ファイルのいずれかにコード .xml 追加するのではなく、別の .xml ファイルを作成することをお勧めします。
たとえば、アプリケーションの設定を移行するコードの場合、コードを
MigApp.xmlファイルに追加する必要があります。移行されるオペレーティング システムの設定を変更するために、カスタム .xml ファイルを作成しないでください。
マニフェスト ファイルは、移行される設定を決定します。 マニフェスト ファイルは変更できません。 マニフェスト ファイルは変更できないため、移行から特定のオペレーティング システム設定を除外するには、代わりに
Config.xmlファイルを作成して変更します。アスタリスク (*) ワイルドカード文字は、作成されるすべての移行 XML ファイルで使用できます。
注
疑問符は、USMT .xml ファイルのワイルドカード文字として有効ではありません。