はじめに
Windows 10 コンピューターを Hybrid Azure AD Join デバイスとして Intune に管理する方法としてはグループ ポリシーを対象の Windows コンピューターに配布する方法や SCCM (現 Microsoft Endpoint Manager ブランド) を利用して自動登録する方法があるかと思います。
今回は Intune (Microsoft Endpoint Manager) から対象のデバイスをリタイヤさせてしまった場合、Intune に再登録した場合を想定して、対象の Windows コンピューターから明示的に「dsregcmd /leave」コマンドレットでクライアント側のデバイス情報を削除しなくても Intune に自動再登録できるかどうか確認してみました。
検証環境
今回検証を行った環境は以下のとおりです。
- AD DS 兼 AADC サーバー 1 台 Windows Server 2016 バージョン 1607
- AADC バージョン 1.5.29.0
- AD FS なしのマネージド ドメイン環境
- Windows 10 バージョン 1909
- Intune ライセンスあり
結論および一覧表およびハマりポイントまとめ
一番見てほしい内容はここに集約します。
結論だけ知りたい方はこちらの一覧と検証を行った際のエラー内容を参考にしていただけると幸いです。
結論としては Intune のリタイヤのみで Hybrid Azure AD Join + Intune 自動再登録がうまく動作しました。
検証したパターンの一覧表です。
| No. | オペレーション | Azure AD デバイス ID 変更有無 | Intune デバイス ID 変更有無 |
|---|---|---|---|
| 1 | Intune リタイヤのみ | 変更されない | 新しい ID に変更される |
| 2 | Intune リタイヤ ＋ dsregcmd /leave | 変更されない | 新しい ID に変更される |
| 3 | Intune リタイヤ ＋ dsregcmd /leave + Azure ポータルからデバイス削除 | 変更されない | 新しい ID に変更される |
No.2 についてはクライアント側で「dsregcmd /leave」を実行しタスク スケジューラーの「Automatic-Device-Join」のタスクで Azure AD にデバイスが登録されます。
No. 3 については Azure AD 側でデバイスを削除しているので「Automatic-Device-Join」が該当するデバイス オブジェクトがないとエラーが出ます。つまり Azure AD Connect から明示的に差分同期でデバイス情報をオンプレミス AD から Azure AD に同期してあげる必要があります。
(No.3 の Azure AD Connect にデバイス同期をしないで「Automatic-Device-Join」のタスクを実行したときのエラー内容抜粋)
Previous Registration : 2020-09-21 16:43:20.000 UTC
Registration Type : sync
Error Phase : join
Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (82acd062-e8c2-40be-8fd5-f54709e7e79f) is not found.
Https Status : 400
Request Id : a79d14cd-be6c-4107-be06-ec7e4d705476
Windows コンピューター側で Intune への自動登録が完了したかどうかを確認するためには、イベント ビューアーの「アプリケーションとサービスのログ」→「Microsoft」→「Windows」→「DeviceManagement-Enterprise-Diagnostic-Provider」→「Admin」のログを確認します。
イベント ID 75 が正常に MDM (Intune) 登録されたときに記録される番号でイベント ID 76 が MDM 自動登録に失敗したときに記録されるログです。
同じイベント ID 76 でもエラーコードによって MDM 登録できない原因が異なってきます。
今回下記 MS の公開情報に乗っていないエラーコードでハマってしまったのでその内容と対処方法の概要を一覧表にしました。
-参考情報
Microsoft Intune での Windows デバイスの登録に関する問題のトラブルシューティング
https://docs.microsoft.com/ja-jp/mem/intune/enrollment/troubleshoot-windows-enrollment-errors
| No. | エラーコード | エラー内容概要 | 対処方法 |
|---|---|---|---|
| 1 | 0x80192ee7 | DNS 名前解決ができていない | インターネット接続および Intune デバイス登録エンドポイントの FQDN が正しく名前解決できているか確認、 DNS 設定確認など |
| 2 | 0x80180001 | Intune自動登録するグループ ポリシーで利用する資格情報が「デバイスの資格情報」になっている | 「ユーザー資格情報」に変更してグループ ポリシーを再配布する |
No. 1 の参考情報
MDM errors failures and how to fix them
URL:https://foxdeploy.com/2017/08/04/mdm-errors-failures-and-how-to-fix-them/
No. 2 の参考情報
AUTOENROLLMENT FAILS WITH UNKNOWN ERROR 0x80180001 & 0x8018002a
URL:https://blog.alschneiter.com/2019/12/20/autoenrollment-fails-with-unknown-error-0x80180001-0x8018002a/
やってみる
今回は Hybrid Azure AD Join コンピューターの Intune をリタイヤさせた際の動作を見たいので、既に構築自体は完了している状態からスタートします。
構成自体は下記公開情報や MS 公式 Blog を参考にしてください。
-参考情報
グループ ポリシーを使用した Windows 10 デバイスの自動登録
URL:https://docs.microsoft.com/ja-jp/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy
マネージド ドメイン用(AD FS なし) Hybrid Azure AD Join を一から構成する
URL:https://jpazureid.github.io/blog/azure-active-directory/how-to-create-hybridazureadjoin-managed/
Intune デバイスを管理する Microsoft Endpoint Manager admin center (https://endpoint.microsoft.com) の対象デバイスの「モニター」→「ハードウェア」を見ると以下画面ショットのように Azure AD デバイス ID と Intune デバイス ID がそれぞれ表示されていることが分かります。
Azure AD にデバイスを登録すると Azure AD デバイス ID が払い出され、Intune にデバイスを登録すると Intune デバイス ID が払い出されます。今回 Intune からリタイヤをするので、Intune デバイス ID はリタイヤするたびに新しい ID が払い出されますが、Azure AD デバイス ID は Intune からリタイヤしても変更されないことがわかりました。
クライアント側で「dsregcmd /status」を実行することで Azure AD デバイス ID を確認できます。
Device Details の項目にある 「DeviceId」が Azure AD デバイス ID に該当します。
(dsregcmd /status の出力結果を一部マスクしています)
C:\Users\test001>dsregcmd /status
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : YES
DomainName : xxxxx
+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+
DeviceId : 82acd062-e8c2-40be-8fd5-f54709e7e79f
Thumbprint : C9AE1EA24EA107D6D8BE83A6FFD32A41EF436D60
DeviceCertificateValidity : [ 2020-09-20 18:32:35.000 UTC -- 2030-09-20 19:02:35.000 UTC ]
KeyContainerId : ea1c220c-3238-4dcc-a716-fa6299048bbf
KeyProvider : Microsoft Software Key Storage Provider
TpmProtected : NO
+----------------------------------------------------------------------+
| Tenant Details |
+----------------------------------------------------------------------+
TenantName :
TenantId : 7a19fda3-2e6b-4876-8023-dcf0c7df2d8c
Idp : login.windows.net
AuthCodeUrl : https://login.microsoftonline.com/7a19fda3-2e6b-4876-8023-dcf0c7df2d8c/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/7a19fda3-2e6b-4876-8023-dcf0c7df2d8c/oauth2/token
MdmUrl : https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
MdmTouUrl : https://portal.manage.microsoft.com/TermsofUse.aspx
MdmComplianceUrl : https://portal.manage.microsoft.com/?portalAction=Compliance
SettingsUrl :
JoinSrvVersion : 1.0
JoinSrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId : urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion : 1.0
KeySrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId : urn:ms-drs:enterpriseregistration.windows.net
WebAuthNSrvVersion : 1.0
WebAuthNSrvUrl : https://enterpriseregistration.windows.net/webauthn/7a19fda3-2e6b-4876-8023-dcf0c7df2d8c/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvVer : 1.0
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/7a19fda3-2e6b-4876-8023-dcf0c7df2d8c/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : NO
WorkplaceJoined : NO
WamDefaultSet : YES
WamDefaultAuthority : organizations
WamDefaultId : https://login.microsoft.com
WamDefaultGUID : {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2020-09-21 14:06:07.000 UTC
AzureAdPrtExpiryTime : 2020-10-05 14:06:06.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/7a19fda3-2e6b-4876-8023-dcf0c7df2d8c
EnterprisePrt : NO
EnterprisePrtAuthority :
+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+
AadRecoveryEnabled : NO
KeySignTest : PASSED
+----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+
IsDeviceJoined : YES
IsUserAzureAD : YES
PolicyEnabled : NO
PostLogonEnabled : YES
DeviceEligible : NO
SessionIsNotRemote : NO
CertEnrollment : none
PreReqResult : WillNotProvision
では Intune からリタイヤさせます。Microsoft Endpoint Manager 画面上から「デバイス」→「Windows」の順にクリックし対象のデバイスを選択します。
画面左上にある「リタイヤ」をクリックします。
確認画面が表示されるので「はい」をクリックします。
リタイヤが開始されました。
数分待つことで対象のデバイスが一覧から消えました。
Azure ポータルのデバイス一覧から該当のデバイスが Intune 準拠済みではなくなりました。
この状態で dsregcmd /status を対象の Windows 10 コンピューター上で同期済みユーザーで実行してみます。
Device State として「AzureAdJoined」が「No」になっていることが分かります。
Intune からリタイヤしたことで一度明示的にデバイスが Azure AD から解除されたことがこの結果をみることでわかります。
PRT も失効しています。
この状態で再度 Intune ライセンスが割り当てられている Azure AD 同期済みユーザーで対象の Windows コンピューターにログオンしなおします。
その前に、管理者ユーザーでログオンして gpupdate /force を実行し Intune 自動登録用のタスク ( Microsoft > Windows > EnterpriseMgmt )を取得する必要があります。
(Intune からリタイヤしデバイス構成が解除されるとこのタスクも削除されるので、再取得する必要があります)
(コマンド)
C:\Users\shyamag>gpupdate /force
Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
グループ ポリシーが降ってきたら下記画面ショットのように管理者ユーザーのタスク スケジューラー上に 5 分毎に実行されるタスク名「Schedule created by enrollment client for automatically enrolling in MDM from AAD using AAD device credential」が設定されていることを確認します。
この状態で Intune ライセンスが割り当てられている Azure AD 同期済みユーザーでログオンしなおしてみます。
Azure AD Join としてデバイスが登録されていることが分かります。
また、デバイス ID を含むデバイス情報が取れており、かつ Azure AD のデバイス ID は Intune によりリタイヤされる前と変わらないことが確認できます。
対象の Windows コンピューターでロック、アンロックを行い PRT が取得され、PRT を利用したユーザー資格情報を基にしたタスクを利用し Intune に登録されるかどうかを確認します。
ロック、アンロックで PRT が取得できたことを確認しました。
イベント ビューアーのアプリケーション ログを見てみます。0x8018002b のエラーが出てますね。
-参考情報
MDM の自動登録: Failed
https://docs.microsoft.com/ja-jp/mem/intune/enrollment/troubleshoot-windows-enrollment-errors#auto-mdm-enroll-failed
原因: 次の条件のいずれかに該当している場合。
UPN に、.local (joe@contoso.local など) のような未確認またはルーティング不可能なドメインが含まれています。
[MDM ユーザー スコープ] が [なし] に設定されています。
PRT が問題なく取れている通り、ルーティング可能なドメインでログオンしているので、MDM ユーザーのスコープ対象となっているか確認します。
「すべて」になっているので問題なさそうですね。
そうこうしている間に 5 分後の自動実行のタイミングで別のイベント ID 76 (0x80180001) が記録されていました。
こちらのエラーについては下記 Blog が非常に詳しく解説してくれています。
-参考情報
AUTOENROLLMENT FAILS WITH UNKNOWN ERROR 0x80180001 & 0x8018002a
URL:https://blog.alschneiter.com/2019/12/20/autoenrollment-fails-with-unknown-error-0x80180001-0x8018002a/
端的にいうと、下記公開情報にも書いている通り、現状はこのグループ ポリシーを利用して Intune 自動登録するためには「デバイス資格情報」ではなく「ユーザーの資格情報」を利用する必要があるので、「ユーザーの資格情報」を利用する設定に変えなくてはいけない、ということです。
-参考情報
グループ ポリシーを使用した Windows 10 デバイスの自動登録
URL:https://docs.microsoft.com/ja-jp/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy
該当箇所抜粋
Windows 10 Version 1903 では、MDM.admx ファイルが更新され、デバイスの登録に使用する資格情報を選択するオプションが追加されました。 デバイスの資格情報は、Windows 10 Version 1903 以降がインストールされているクライアントにのみ有効な新機能です。 以前のリリースの既定の動作では、ユーザーの資格情報に戻されます。
もし利用されている AD DS サーバーの該当 OU に配布しているグループ ポリシーが下記画面ショットのように「デバイスの資格情報」となっている場合は「ユーザー資格情報」にプルダウンメニューで変更しましょう。
変更して「適用」します。適用後対象のグループ ポリシーを gpupdate /force で再配布します。
グループ ポリシーが再配布された状態で再度 5 分ほどタスクが再実行されるまで待ってみます。
すると 0:20 には失敗していた MDM 登録が 0：24 にイベント ID 75 として登録に成功していることが確認できます。
登録に失敗していた原因が、自動 MDM 登録の「資格情報の種類 (デバイスの資格情報では NG ) 」であったことが分かりました。
念のため MEM (Microsoft Endpoint Manager) 管理画面を見ると、対象の Windows コンピューターが準拠済みとして登録されていました。
ハードウェア画面を見ると、下記画面ショットのように「Azure AD デバイス ID」は変更されないまま保持できていることが確認できます。
Intune デバイス ID は一度リタイヤしているので新しい ID として登録されています。
こちらがリタイヤ後の再登録した状態。
こちらがリタイヤ前の状態。(再掲)
これにより、結論のところにも書いたとおり、例えば誤って Intune から Hybrid Azure AD Join のコンピューターをリタイヤさせてしまった場合や、Intune への再登録をする必要に迫られた場合において、必ずしも対象の Windows 10 コンピューターの管理者権限で「dsregcmd /leave」でデバイスを Azure AD から削除してあげる必要はない、ということが分かりました。
おわりに
今回は Hybrid Azure AD Join + Intune 管理済みの Windows 10 コンピューターを Intune からリタイヤさせた場合の Hybrid Azure AD Join を含む再構成に必要な手順を確認してみました。
ポイントとしては「dsregcmd /leave」コマンドレットはコマンドプロンプトを管理者として実行した上でクライアント側で実行させる必要がありますが、Intune リタイヤをするだけであれば明示的に「dsregcmd /leave」コマンドレットを実行しなくても Intune の自動再登録が可能であるという点にあるかと思います。
今回の記事が少しでも参考になれば幸いです。