ADMT(ActiveDirectory移行ツール)で、ユーザープロファイル変換エラーが消えない

すべての返信

• 

  

  0

  サインインして投票

  チャブーンです。

  この件ですが、「ERR2:7646 '<ユーザ名>' のクラス ハイブを変換できません。」エラーに関しては、FAQ的な情報はないので、右から左に簡単にわかる、という話しではありません(少なくとも私にはわかりません)。

  まず、クライアント側のログはどうなっていますか？C:\Windows\ADMT\Logs\AgentsにあるMigrationTaskID.logの該当箇所はどうなっているでしょうか？

  それと、クライアント側の操作ですが、もし[XXXXXでログオン]→[常駐ソフトを終了]→[ログオフしてADMTを実行]という流れてやっておられるならばですが、そうではなく[管理者権限でログオン]→[「再起動後も動作しないよう」常駐ソフトが起動しないように設定/アンインストール]→[クライアントを再起動後ADMTを実行]で問題が改善しないか、確認してみてください。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  • 回答の候補に設定 佐伯玲 2015年9月2日 0:36

  2015年9月1日 8:02

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  チャブーン様

  コメント有難うございます。

  そうですね。該当箇所はログから判るのですが、意味が特定できないため、手探りで行うしかないのがつらいところです。

  クライアントの操作は、基本的にターゲット機を管理者権限でログオンし、常駐ソフトを閉じた状態でログオフ、他機からリモートでADMTを操作という手順で行っています。クライアントを再起動してしまうと、常駐ソフトが動いてしまいますが、ログインする前に止めておいた状態で処理すればよいのですね？

  どうも有り難うございました。

  2015年9月2日 0:56

  返信

  |

  引用
• 

  

  0

  サインインして投票

  チャブーンです。

  クライアントの操作は、基本的にターゲット機を管理者権限でログオンし、常駐ソフトを閉じた状態でログオフ、他機からリモートでADMTを操作という手順で行っています。クライアントを再起動してしまうと、常駐ソフトが動いてしまいますが、ログインする前に止めておいた状態で処理すればよいのですね？

  こちらに対するコメントですが、状況として「クラスハイブ(ユーザレジストリの一部)が、該当ユーザがログオフしてもプロファイルからアンロードされない」ためにロックされて移行に失敗している、可能性を疑っています。これに対する最善の策は「最初からユーザログオンしない」ことで、これを担保するには、常駐ソフト類が「コンピュータ起動時から動作しない」ように設定いただく必要があります。

  ADMTのセキュリティ変換はコンピュータアカウントやユーザアカウントが利用する部分だけが対象になりますので、逆を言うと、ムリに常駐ソフトを停止させなくても大丈夫な可能性もあります。これはやってみなければわからないので、可能であれば、常駐ソフトはひとまずそのままの状況で試されてみる(繰り返しますが、だれもログオンさせない=ユーザレジストリに触らせないことが重要です)ことも視野に入れると、よいかもしれません。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  2015年9月2日 1:28

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  チャブーン様

  再度のコメント有難うございました。

  ログオンをしていない状態（起動直後のログオン画面の状態）で、再度ADMTを実行してみましたが、同じ結果に終わりました。

  エラーの発生した箇所もエラーメッセージも同じでした。

  再度別のレジストリクリーナーで、消去はせずに不要なゴミを調べてみましたが、別のものがうようよと出ていますが、エラーの発生しているHKEY_USERS以下のものは見当たりません。

  知らぬ間にスパイウェアの類が常駐しているのかも、とも思ったのですが、起動前の状態でもNGなので、ちょっと考えにくいですね。
  

  2015年9月3日 3:49

  返信

  |

  引用
• 

  

  0

  サインインして投票

  チャブーンです。

  うまくいかなかったとのことで、この点は了解しました。

  HKEY_USERS\<SID>_Classes配下の情報ですが、実際にはHKEY_CURRENT_USER\Software\Classesにマウントしていますので、そちらを確認いただくといいのかもしれません。

  別ユーザ'YYYYY'の移行はうまくいっている、とのことですので、YYYYYでログオンしたうえ、そちらの同じキー内で差異がないか、確認される方法もあるかもしれません。この際、念のためですが、対象レジストリキーのアクセス許可や、実際のハイブファイルの構成(%UserProfile%直下のNTUSER.DAT関連のファイルという認識です)についても確認いただくといいかもしれません。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  • 回答の候補に設定 佐伯玲 2015年9月11日 4:53

  2015年9月3日 10:26

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  こんにちは、hatsujiro さん
  フォーラムオペレータの佐伯 玲 です。
  
  その後さらにチャブーンさんから返信が寄せられておりますのでご確認くださいね。
  解決に至ったりご参考になった際には「回答としてマーク」いただくようお願いいたします。
  
  宜しくお願い致します。

  ---

  TechNet Community Support 佐伯 玲

  2015年9月15日 4:51

  返信

  |

  引用
• 

  

  0

  サインインして投票

  チャブーン様

  コメント有難うございました。

  当該PCについて、元に戻そうとしたのですが、復元が失敗し、中途半端な状態になってしまいました。

  元々のユーザーアカウントでログインしたところ、元々のアカウントの配下にあるMydoocumentがアクセスできない状態に陥ってしまったので、ローカルの管理者権限でログインしてみたところ、元のアカウント.001というようなフォルダが出来ており、そこをアクセスしているようでした。

  元のアカウント.001というフォルダを削除したところ、元のアカウントでログインし、Mydocumentもアクセスできるようになりました。

  レジストリのゴミ（HKEY_USERS\<SID>以下）はフォルダを消せば一緒に消えるということも判りました。が、肝心のターゲットになるアカウントのレジストリのエラーとなる原因は解決していません。

  ご指摘の内容について、もう一度見直してみます。

  2015年9月16日 9:29

  返信

  |

  引用
• 

  

  0

  サインインして投票

  チャブーンです。

  この件ですが、実機を直接見ていない以上、はっきりとしたことはわかりません。ですが、OS上のプロファイルリストに問題があるように思いますので、これを修正すると良いかもしれません。

  ユーザープロファイルの状態について、[システムのプロパティ]-[ユーザープロファイル]から確認してみてください。「不明なアカウント」が存在する場合、この画面で削除できますが、(システム上は不要でも)質問者さんに必要なファイルが失われないよう、C:\Usersフォルダ内部はバックアップを取っておいた方がいいでしょう。

  あとは、以下のレジストリとサブキー内容をチェックします。存在しないプロファイル情報があれば、レジストリサブキーごと削除する必要があります。Well Known SID(よく知られたSID)のキーは削除しないようにしてください。レジストリ情報も、事前バックアップは忘れずに。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  • 回答としてマーク 佐伯玲 2015年9月29日 6:51

  2015年9月17日 6:00

  返信

  |

  引用

  モデレータ