本記事でも手順をご紹介しましたが、ハイブリッドAzureAD参加を構成したにもかかわらず、正しく構成できない場合のトラブルシューティングを簡単にまとめてみました。
ここでのトラブルシューティングはクライアント目線ではなく、構築した環境が正しく構成されているかを確認するためのものですので、参考までに見ていただけますと幸いでございます。
参考サイト
https://jpazureid.github.io/blog/azure-active-directory/troubleshoot-hybrid-azure-ad-join-managed/
目次
トラブルシューティングフロー
以下トラブルシューティングをまとめてみました。
このフローをもとに順番に対応していきます。
■トラブルシューティングフロー
AzureADにデバイスが存在するか
まず初めに確認することとしては、AzureADにオンプレミスADのコンピューターオブジェクトが同期されているかを確認します。
Azureポータルの[デバイス]から登録されているデバイスを確認しましょう。
正しく構成されていれば、結合の種類が"HybridAzureADJoined"として登録されているはずです。
デバイスが登録されている場合、対象のクライアント端末上でタスクスケジューラを起動し、 「WorkPlaceJoin」-「Automatic-Device-Join」の実行結果が”この操作を正しく終了しました”となっているかを確認します。
もし、AzureADにデバイスが同期されていなければ、AADCからAzureADへ対象のコンピューターオブジェクトが同期されていない可能性があります。
UserCertificate属性値がコンピューターオブジェクトにセットされているか
AADCの「Out to AAD - Device Join SOAInAD」ルールの「Scoping filter」を確認すると、 userCertificate が ISNOTNULL に設定してあります。つまり、 userCertificate に値が入っている コンピューターオブジェクトのみが同期されるようにルールが設定されているため、 userCertificate に値が入っていないコンピューターオブジェクトはAzureADに同期されません。
値が入っているかどうかは直接コンピューターオブジェクトの属性値を確認します。
もし、属性値が入っているにも関わらず、同期できていない場合はそもそも同期対象OUに対象のコンピューターオブジェクトが属しているかを確認しましょう。
対象端末でタスクが実行されているか
ハイブリッドAzureAD参加の対象端末でタスクスケジューラーを起動します。「WorkPlaceJoin」-「Automatic-Device-Join」の状態が”無効”となっていないことを確認します。
タスクが有効化となっていない場合、クライアント端末側の問題の可能性もあるため、この時点でメーカー（Microsoft社）さんに問い合わせしましょう。
SCPが正しく構成されているか
タスクが”実行中”（無効となっていない）となっている場合でも、SCPの構成が正しく設定されていない場合、タスク処理は失敗に終わっている可能性があります。SCPが正しく構成されているかどうかを以下手順で確認しましょう。
ADにログインし、Powershellを起動します。
”DC=xxxx,DC=xxxx”はご利用されているドメインを指定します。
$scp = New-Object System.DirectoryServices.DirectoryEntry $scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=xxxx,DC=xxxx" $scp.Keywords
以下、属性値が設定されていることを確認します。
■設定されている場合
■設定されていない場合
設定されていない場合は何も表示されないことがわかります。
前回、ご紹介したハイブリッドAzureAD参加の構成手順では、AADCの構成ウィザードから設定する手順でしたのでここでは、オフライン環境のADでも設定できる”ConfigureSCP.ps1”を利用してSCPの設定をやってみます。
SCCM共同管理によるHybridAzureADJoinの構成
https://jin-kuro.com/sccm-hybridazureadjoined/
AADCの構成ウィザードを起動し、「デバイスオプションの構成」を選択します。
「ハイブリッドAzureAD参加の構成」にチェックを入れます。
「Windows10以降のドメインに参加しているデバイス」にチェックを入れ、「次へ」を選択します。
「ConfigureSCP.PS1のダウンロード」を選択します。
テキストで生成されたファイルを任意の場所に保存します。
ファイルの種類は”すべてのファイル”を選択し、PS1形式で保存します。
Powershellを右クリックし、「管理者として実行」を選択して実行します。
※実行するアカウントですが、AADCウィザードで実行する手順と同様に、エンタープライズ権限を保有した管理者アカウントで実行する必要があります。
保存した””ConfigureSCP.PS1”ファイルをpowershellにドラッグし、以下パラメーターを指定します。
-domain Office365カスタムドメイン名
実行すると”Configuration complete!”と表示されます。
再度、以下コマンドで確認すると、正しく構成されていることがわかります。
$scp = New-Object System.DirectoryServices.DirectoryEntry $scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=xxxx,DC=xxxx" $scp.Keywords
ADSIエディターからも設定されていることが確認できました。
AzureAD DRSエンドポイントに接続できる環境か
クライアント上で実行されたタスクは、SCPに指定しているAzureADテナント情報が存在するか、以下エンドポイントにアクセスしようとします。
https://enterpriseregistration.windows.net
https://login.microsoftonline.com
https://device.login.microsoftonline.com
プロキシの設定によってブロックされている場合、以下コマンドにて、上記をプロキシに経由しないように設定をしましょう。
netsh winhttp set proxy proxy-server="<プロキシー サーバー>:<ポート>" bypass-list=".enterpriseregistration.windows.net;.login.microsoftonline.com;*.device.login.microsoftonline.com"
また、下記コマンドにて、名前解決ができているかを確認します。
以下、ハイブリッドAzureAD参加を構成する手順の中で設定したCNAMEレコードの値が返ってくるかを確認します。
enterpriseenrollment.manage.microsoft.com enterpriseregistration.windows.net
nslookup -type=cname enterpriseenrollment.マネージドドメイン nslookup -type=cname enterpriseregistration.マネージドドメイン
タスクを実行してみる
これまでの確認事項が問題ないことを確認したら、対象のクライアント端末上で以下タスクを実行しましょう。
「WorkPlaceJoin」-「Automatic-Device-Join」を右クリックし、”実行する”をクリックします。
実行後、クライアント端末上で[dsregcmd /status]コマンドを実行し、下記ステータスが”YES”なっていることを確認します。
dsregcmd /status
＜ステータス＞
AzureADJoined：YES
DomainJoined：YES
AzureADPrt：YES
もし、上記のステータスが”No”となっている場合、正しくハイブリッドAzureAD参加が構成されていないことになります。
ざっくりとハイブリッドAzureAD参加のトラブルシューティング手順を記載しましたが、本確認手順は、あくまで参考程度にしていただき、早急な解決となれば、やはり メーカー（Microsoft社）へ問い合わせし、しっかりクリアにすることをご検討ください。
本記事が少しでもお役に立てれば 幸いでございます。
