ADMT v3.2/PES v3.1 をダウンロードしようとすると Microsoft のページが 404(リンク切れ)になり入手できない――そんなときに役立つ、原因(SHA-1廃止)と公式の安全な入手先、再発時の対処、代替策までをまとめます。
結論:ADMT/PES は「Microsoft 公式の掲載先」から入手できる
まず結論から言うと、ADMT(Active Directory Migration Tool)と PES(Password Export Server)は、Microsoft の公式掲載ページから入手できます。過去に 404 になる期間がありましたが、現在は再公開され、ダウンロードセンター側でもリンクが整備されています。
特に重要なのは、古い直リンクを追いかけるのではなく、「サポート(KB)記事 → ダウンロードセンター」という導線で辿ることです。サポート記事側は更新されやすく、リンク切れ時の復旧もここが起点になりやすいからです。
| 対象 | 役割 | 公式入手先(推奨) | ページ上の公開日 | ファイル名の例 |
|---|---|---|---|---|
| ADMT v3.2 | ユーザー/グループ/コンピューターの移行、SIDHistory、セキュリティ変換など | Microsoft Download Center(id=56570) | 2024/07/15 | admtsetup32.exe |
| PES v3.1(x64) | パスワード移行(ADMT の「パスワード移行」を成立させるためのサービス) | Microsoft Download Center(id=1838) | 2024/07/15 | pwdmig.msi |
| PES v3.1(x86) | x86 OS 向けの PES | Microsoft Download Center(id=10370) | 2024/07/15 | pwdmig.msi |
| ADMT ガイド | 手順・設計の参照資料(公式ドキュメント) | Microsoft Download Center(id=19188) | 2024/07/15 | ADMTV32MigGuide.doc |
| サポート方針/既知の問題(KB 4089459) | 動作制約・既知の問題・サポートレベルを確認する起点 | Microsoft Learn(KB 4089459) | 最終更新 2025/01/15 | ― |
「どのリンクが正しいか分からない」「また 404 になったら困る」という場合は、上表のKB(既知の問題・サポート方針)ページをブックマークしておくと、復旧時の追従が楽になります。
なぜ 404 が起きたのか:SHA-1 廃止と再署名(SHA-2)
過去に ADMT/PES のダウンロードが 404 になった主因は、SHA-1 署名の廃止(業界全体の移行)に関連して、配布ファイルが一時的に取り下げられたり、再署名・再公開の作業が必要になったためです。
Microsoft のコミュニティでも、リンク切れ当時に「SHA-1 の非推奨に伴ってコンテンツが削除された」旨の案内があり、その後「ツールは再公開され、サポート記事から辿れるようになった」という流れが確認できます。加えて、ダウンロードセンター側の公開日が 2024/07/15 に更新されていることからも、再公開(再リリース)の動きが読み取れます。
- ポイント:404 が出たからといって「誰かの手元のインストーラー」を集め始めるのは危険です。
- 理由:改ざん・マルウェア混入のリスクがあり、移行用サーバーや DC に導入するには致命的になり得ます。
- 正攻法:Microsoft のサポートページ/ダウンロードセンターを起点に、公式の配布先から入手します。
安全にダウンロードする手順(公式リンクのみで完結)
ADMT v3.2 を入手する
- KB 4089459(サポート方針・既知の問題)を開き、ダウンロードセンターへのリンクを辿ります。
- ダウンロードセンターの ADMT v3.2(id=56570) を開きます。
- 「Download」から取得します(実ファイルは download.microsoft.com から配布されます)。
PES v3.1 を入手する(x64 / x86 を間違えない)
PES は ADMT に同梱されておらず、別ダウンロードです。ADMT のダウンロードページ内に「Related Resources / Related Downloads」として PES のリンクがあります。直接開く場合は以下です。
注意:PES は原則としてソース側ドメインの書き込み可能なドメインコントローラーに導入する構成が一般的です(設計によって変わります)。いきなり本番 DC に入れず、検証環境で手順・影響・ロールバックまで確認してから進めるのが安全です。
ダウンロード後に必ずやる「改ざん対策」
公式サイトから落としていても、運用上のミス(別ファイルを掴む、途中で破損、プロキシの置換など)をゼロにはできません。移行は高権限で実施するため、最小限の検証を習慣化します。
- ファイルのプロパティでデジタル署名(署名者が Microsoft であること、署名が有効であること)を確認する
- 可能なら、ダウンロード元がMicrosoft Download Centerであることを再確認する
- 不審なリダイレクトや、ブラウザ拡張での書き換えが疑われる場合は、別端末/別ネットワークで再取得する
それでも 404 になる/「利用できません」が出る時の対処チェックリスト
ダウンロードセンターは、言語や地域、認証状態、ネットワーク制御(プロキシ、SSL インスペクション)などで挙動が変わることがあります。以下を上から潰すと切り分けが早いです。
| 症状 | よくある原因 | 対処(効果が出やすい順) |
|---|---|---|
| 404(ページが見つからない) | 古い直リンク、地域別 URL、過去キャッシュ | KB 4089459 から辿り直す id=56570 / id=1838 の「en-us」ページで開く シークレット/InPrivate で開く(キャッシュ・Cookie の影響排除) |
| 「このダウンロードは利用できません」 | 地域・言語の切り替え、ブラウザ翻訳、企業プロキシの干渉 | ページ上部の言語選択をEnglishに戻す 別回線(テザリング等)で同 URL を開き、ネットワーク要因か確認 企業プロキシ配下なら、セキュリティ担当に「download.microsoft.com へのダウンロード許可」を確認 |
| ダウンロードはできるが実行時にエラー | サポート外 OS、セキュリティ機能の影響、前提不足 | KB 4089459 の既知の問題を確認 ADMT の対象 OS(後述)に合わせて専用の移行サーバーを用意 Credential Guard、LSA 保護、TLS 設定などの影響を切り分け |
「リンクが落ちているのか」「自分の環境だけがブロックしているのか」を最短で判断したいなら、別ネットワークから同じ URL を開くのが効果的です。これでサーバー側の問題か、社内ネットワーク要因かが一気に分かれます。
ADMT は終了したのか?今も使えるが、位置づけは「限定サポート」
ADMT は完全に消えたわけではなく、現在もダウンロードセンターから取得できます。ただし、Microsoft のサポート記事では ADMT の位置づけが明確で、重要な点は次のとおりです。
- 「ベストエフォート」でのサポート(必ず解決する保証はない)
- コードベースは deprecated(開発停止)で、セキュリティ修正・バグ修正・設計変更の対象外
- Windows 10/11 や Windows Server 2012 R2/2016/2019/2022 など、新しい OS では未検証・制約がある
つまり ADMT は「今すぐ使えないツール」ではありませんが、現代の標準的なセキュリティ設定と相性が悪い場面があり得るため、移行プロジェクトではリスクとして織り込む必要があります。
よく踏む落とし穴(事前に知っておくと強い)
| 論点 | 何が起きる? | 実務上の対策 |
|---|---|---|
| 最新 OS のクライアント/サーバー | ユーザープロファイル移行やセキュリティ変換が期待通りに動かないことがある | プロファイル移行を要件から外す/別手段を用意(新規プロファイル+データ移行など) |
| Credential Guard | ADMT がエラーになり、移行が進まない | 移行専用サーバーを用意し、必要な範囲で一時的に機能を無効化(戻し手順もセット) |
| 委任(unconstrained delegation) | ADMT の要件と現代のセキュリティベストプラクティスが衝突する | 構成・配置(どこで ADMT を動かすか)を見直す |
| SQL/TLS 設定 | SQL 側の TLS 設定によって ADMT が起動できないことがある | 検証で再現確認し、移行期間だけの暫定設定とロールバックを準備 |
| LSA 保護(PES) | PES によるパスワード移行が失敗することがある | 「パスワード移行をやる/やらない」を設計で決め、やるなら安全な手順で一時的に制御 |
ここまで読むと「じゃあ ADMT を今から使うべきじゃないのでは?」と思うかもしれませんが、移行対象が比較的レガシー寄りで、要件が明確(SIDHistory が必要、段階移行が必要など)であれば、今でも有効な場面はあります。重要なのは、ADMT を“魔法の移行ツール”だと思わないことです。
PES(Password Export Server)でパスワード移行をする時の実務ポイント
PES は「ADMT のパスワード移行」を成立させるための部品です。便利な反面、ソース側 DC にサービスを入れることや、セキュリティ機能との相性など、リスクの強い工程でもあります。だからこそ、次のように割り切ると事故が減ります。
- パスワード移行は必須要件かを最初に決める(必須でなければ「初回サインイン時に変更」で回避する)
- PES サービスは移行期間だけ起動し、完了後に停止・撤去まで行う
- 監査・承認(セキュリティ部門)を通して、一時的に緩める設定があるなら期限とロールバックを明確にする
暗号化キー作成(例)
ADMT でパスワード移行を行う場合、ADMT 側で暗号化キーを作成し、それをソース DC に持ち込み、PES セットアップで指定する流れが一般的です。コマンド例は次の形式です。
admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*}
運用上は、キーの保管場所・持ち運び方法(安全な共有やオフライン媒体)・作業者権限・作業ログの残し方までをセットで決めておくと、監査対応もスムーズです。
パスワード移行後に「ユーザーにパスワード変更を促す」考え方
パスワード移行は「ユーザー影響を減らせる」一方で、暗号方式やクライアント側の設定によっては認証トラブルの原因にもなり得ます。たとえば、移行後に Kerberos の暗号化タイプ設定によっては、ユーザーがパスワードを再設定するまで正常に認証できないケースがあり、実際に AWS 側の手順でも移行後のパスワードリセット推奨が明記されています。
このため、「移行の当日はパスワードを移すが、初回サインイン時に変更を必須化する」「一定期間内に変更を促す」といった運用は、トラブルを吸収しやすい現実解です。移行の目的が“ユーザー影響をゼロにすること”ではなく“安全に確実に完了させること”であるなら、検討に値します。
参考:AWS Security Blog(ADMT と PES を使った移行手順)
「ADMT が厳しい」場合の代替策
ADMT が終了しているかどうか以上に大事なのは、あなたの環境・要件に ADMT が適合するかです。合わない場合、次の代替パターンが現実的です。
要件を見直して、PES を使わない(パスワードはリセット運用)
パスワード移行が最大の難所になっているなら、思い切って「移行後にパスワード変更」「一時パスワード配布」「SSPR(セルフサービス)誘導」などで回避できます。これにより、ソース DC への PES 導入・設定変更・セキュリティ例外の議論を大幅に減らせます。
サードパーティ製の AD 移行ツールを使う
大規模環境、段階移行、長期共存、Exchange 連携、詳細なレポーティング、最新 OS 前提など、要件が増えるほどネイティブツールは苦しくなります。そういう場合は、AD 移行に特化した商用ツールを評価対象に入れるのが一般的です。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| ADMT(Microsoft) | シンプルなドメイン/フォレスト移行、要件が限定的、コストを抑えたい | 限定サポート・既知問題が多い。設計と検証が重要 |
| 商用 AD 移行ツール | 大規模、段階移行、共存期間が長い、最新 OS/複雑要件、手戻りを減らしたい | コスト・ライセンスが発生。PoC と要件定義が必須 |
| 設計で回避(パスワード移行しない等) | セキュリティ要件が厳しい、移行ウィンドウが限られる、運用で吸収できる | ヘルプデスク負荷(初回対応)を見込んでおく |
クラウド/マネージド AD への移行でも ADMT が使われることがある
「オンプレ AD を別の基盤に持っていく」ケースでも、移行の部品として ADMT/PES が登場することがあります(例:AWS Managed Microsoft AD への移行手順で ADMT+PES を使う案内など)。ただし、クラウド移行はネットワーク、信頼関係、認証方式、暗号化タイプなど論点が増えるため、ツール選定より前に移行方式の設計が重要です。
リンク切れに振り回されないための「情報の追い方」
ADMT/PES に限らず、古いツールほど「昔のブログの直リンク」が先に壊れます。リンク切れに時間を溶かさないために、次の運用がおすすめです。
- ブックマークは KB(既知の問題・サポート方針)を起点にする
- ダウンロードは Microsoft Download Center から行う
- 「入手できない」時ほど、非公式配布・誰かのファイルに手を出さない(移行環境は高権限)
- 移行専用サーバーで検証し、セキュリティ例外が必要なら期限・戻し手順まで作る
ADMT/PES の 404 は、あなたの操作ミスというより「配布の都合(署名移行など)」で起きた典型例です。だからこそ、公式の“正しい入口”を押さえておけば、次に同じことが起きても最短で復旧できます。

コメント