これらが全部当てはまるなら、原因はSID（セキュリティ識別子）の衝突かもしれません。
SIDとはWindowsがコンピューターやユーザーを識別するための一意のIDです。
例: S-1-5-21-3344124752-3884463202-4209043644-500Windows同士がネットワーク認証（NTLM）を行う際、このSIDを使って「相手が誰か」を判断します。
ここが罠のポイント： 仮想マシンをクローン（コピー）すると、OSごとコピーされるためSIDも完全に同じになります。
クローン元VM（SID: S-1-5-21-XXXX-500）
クローン先VM（SID: S-1-5-21-XXXX-500）← 同じ！
↓
NTLMで認証しようとすると
「相手は自分自身と同じSID」と判断
→ 認証が正常に完了しない
→ 「パスワードが間違っています」と表示されるパスワードは正しいのに弾かれるという、非常にわかりにくい症状が出ます。
両方のVMでこのコマンドを実行してください：
powershell
whoami /user# VM-A の結果
S-1-5-21-3344124752-3884463202-4209043644-500
# VM-B の結果
S-1-5-21-3344124752-3884463202-4209043644-500
← 同じ！これが原因S-1-5-21- の後ろの数字が両方同じならSID衝突が確定です。
SIDを変えるにはMicrosoft公式ツールのSysprepを使います。
cmd
C:\Windows\System32\Sysprep\sysprep.exe /generalize /reboot /oobeこれでSIDが新しく生成され、再起動後に初期設定画面（OOBE）が表示されます。
/generalize オプションはOSを初期状態にリセットします。
具体的には：
Sysprepを実行する前に必ずスナップショットを取るか、重要ファイルをバックアップしてください。
Windows Server 2025ではWinGetアプリが原因でSysprepが失敗することがあります。
powershell
# 事前にWinGetを削除
Get-AppxPackage -Name "Microsoft.Winget.Source" | Remove-AppxPackage -ErrorAction SilentlyContinue削除後に再度Sysprepを実行してください。
Sysprepは「回避策」として紹介しましたが、実際にやってみると：
| 新規VM作成 | Sysprep | |
|---|---|---|
| 所要時間 | 約30分 | 数時間（トラブル対応含む） |
| ファイル消失リスク | なし | あり（全消去） |
| 手間 | OSインストールのみ | 事前準備・失敗対応が必要 |
| 確実性 | 高い | 環境によって失敗する |
クローンVMのSID問題に直面したら、素直に新規VMを作り直す方が時間もリスクも少ないです。
何台もVMを量産する場合は、最初に正しいテンプレートを作っておくと以降の作業が楽になります。
1. ベースVMを作成・必要な設定を行う
2. Sysprepを実行（/generalize）
3. シャットダウン
4. vSphereで「テンプレートに変換」こうしておくと：
テンプレートからデプロイ
→ 初回起動時にOOBE画面が自動起動
→ SIDが自動で新規生成される ✅
→ コンピュータ名・パスワードを設定
→ 即使える状態に ✅vSphereのカスタマイズ仕様と組み合わせればOOBE画面すら省略でき、デプロイするだけでコンピュータ名・IP・SIDが全て自動設定されます。
| ポイント | 内容 |
|---|---|
| 症状 | パスワードが正しいのに共有フォルダに接続できない |
| 原因 | クローンVMのSID重複によるNTLM認証失敗 |
| 確認方法 | whoami /user で両VMのSIDを比較 |
| 回避策 | Sysprepでリセット（ファイル全消去に注意） |
| 現実解 | 新規VMを作り直す方が早くて確実 |
| 恒久対策 | Sysprep済みテンプレートからデプロイする |
Windowsのエラーメッセージが「パスワードが間違っています」としか出ないため非常にわかりにくいですが、クローンVMを使っている場合はまずSIDを疑ってみてください。
この記事は実際のトラブルシューティング経験をもとに書いています。同じ症状で悩んでいる方の参考になれば幸いです。