USMT のベスト プラクティス
この記事では、ユーザー状態移行ツール (USMT) を使用する場合の一般的なセキュリティ関連のベスト プラクティスについて説明します。
一般的なベスト プラクティス
LoadState ツールを実行する前に、アプリケーションをインストールします。
必ずしも重要であるとは限りませんが、ユーザーの状態を復元する前に、すべてのアプリケーションを移行先コンピューターにインストールすることをお勧めします。 ユーザー状態を復元する前にアプリケーションをインストールすると、移行された設定が確実に保持されます。
MigUser.xml と MigDocs.xml を一緒に使用しないでください。
と
MigDocs.xml
の両方MigUser.xml
が一緒に使用されている場合、移行されたファイルの一部は、ターゲットの場所に関して競合する手順が指定されている場合に重複する可能性があります。/genmigxml
コマンド ライン オプションを使用すると、移行に含まれるファイルを判断したり、変更が必要かどうかを判断したりできます。 詳細については、「 ファイルの種類、ファイル、およびフォルダーを識別する」を参照してください。移行エクスペリエンスを向上するために MigDocs.xml を使用します。
データ セットが不明な場合、または多数のファイルが標準のユーザー プロファイル フォルダーの外部に格納されている場合、
MigDocs.xml
ファイルはファイルより広い範囲のデータを収集するためMigDocs.xml
、ファイルよりもMigUser.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 ファイルと証明書の移行」を参照してください。
注
証明書も移行せずに暗号化されたファイルが移行された場合、エンド ユーザーは移行後にファイルにアクセスできません。
ストアを暗号化します。
コマンドで オプションを
/encrypt
使用し、ScanState.exe
コマンドで オプションを/decrypt
LoadState.exe
使用することを検討してください。 ただし、コマンド ライン スクリプトにアクセスできるユーザーは暗号化キーにもアクセス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 ファイルをモデルとして使用して、カスタマイズされたバージョンを作成できます。 ユーザー データ ファイルを移行する必要がある場合は、 でカスタム .xml ファイルをモデル化します
MigUser.xml
。 アプリケーション設定を移行するには、ファイル上のカスタム .xml ファイルをモデル化しますMigApp.xml
。コンテキスト> パラメーターを使用する場合は、パフォーマンスへの影響を<考慮してください。
コンテキスト要素がコンポーネント>要素と共に使用される場合、移行のパフォーマンスが影響を<受ける可能性があります。<> たとえば、ファイルベースまたはパスベース<の論理ユニットをカプセル化する場合は、インクルードルールと除外ルールが含まれます>。><
ユーザー コンテキストでは、システム上のユーザーごとにルールが 1 回処理されます。
システム コンテキストでは、ルールがシステムに対して 1 回処理されます。
UserAndSystem コンテキストでは、ルールはシステム上のユーザーごとに 1 回、システムに対して 1 回処理されます。
注
ルールが処理される回数は、ファイルが移行された回数には影響しません。 USMT 移行エンジンは、各ファイルが 1 回だけ移行されるようにします。
Microsoft では、既存の移行 .xml ファイルのいずれかにコード .xml 追加するのではなく、別の .xml ファイルを作成することをお勧めします。
たとえば、アプリケーションの設定を移行するコードの場合、コードをファイルに
MigApp.xml
追加するだけではありません。移行されるオペレーティング システムの設定を変更するために、カスタム .xml ファイルを作成しないでください。
マニフェスト ファイルは、移行される設定を決定します。 マニフェスト ファイルは変更できません。 マニフェスト ファイルは変更できないため、特定のオペレーティング システム設定を移行から除外するには、代わりにファイルを
Config.xml
作成して変更します。アスタリスク (*) ワイルドカード文字は、作成されるすべての移行 XML ファイルで使用できます。
注
疑問符は、USMT .xml ファイルのワイルドカード文字として有効ではありません。
関連記事
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示