Skip to content

Ulysses Neves

Microsoft Entra ID, authentication, and hybrid identity troubleshooting.

Menu
  • Início
  • Microsoft Azure
  • Microsoft AD FS
  • Microsoft 365
  • Contact
Menu

Azure AD Hybrid Device Join – Troubleshooting error code 0x801c0021 during the ‘discover’ phase

Posted on 16 de September de 2022

Hello everyone. Today, we’re going to investigate the error message ‘DsrCmdJoinHelper::Join: TenantInfo::Discover failed with error code 0x801c0021‘ when trying to turn a domain-joined device into Hybrid Azure AD Joined.

Scenario: Azure AD Hybrid Device Join  

In this article, we’ll focus on the error message, but if you are looking for the requirements and steps to implement Azure AD Hybrid Device Join, please check this Microsoft implementation guide.

Checking device registration status

Prior to the Hybrid Join implementation, once you run the command dsregcmd /status on a windows 10 or 11 domain-joined machines, you may face the device state as below:

+———————————————————————-+
| Device State |
+———————————————————————-+

         AzureAdJoined : NO
      EnterpriseJoined : NO
          DomainJoined : YES
            DomainName : CORP
           Device Name : WS10-Hybrid.corp.contoso.com

In case you have DomainJoined is YES, and AzureAdJoined set to NO, means the device is currently joined to the OnPrem Active Directory only.

For more information about all parameters in the output, please check this Microsoft Official document.

ISSUE: You have implemented all steps to have your domain joined devices turn into Azure AD Hybrid join, and the devices still don’t show AzureAdJoined as YES.
You face error message DsrCmdJoinHelper::Join: TenantInfo::Discover failed with error code 0x801c0021 when running dsregcmd /status.

Investigating the issue

There are some events and tools that can be used to investigate device join process in the client. We are going to use below ones:
– Utility dsregcmd
– Event viewer log Microsoft-Windows-User Device Registration/Admin
– Event viewer log Microsoft-Windows-User Device Registration/Debug

Dsregcmd diagnostic data

Running dsregcmd /status using a command prompt in one affected machine, you can see in the Diagnostic Data that DsrBeginDiscover is failing.

DsrCLI: logging initialized.
DsrCLI: logging initialized.
DsrCmdJoinHelper::Join: ClientRequestId: 2b367844-2668-4b80-8190-b237d3f788aeDsrCmdAccountMgr::IsDomainControllerAvailable: DsGetDcName success { domain:corp.contoso.com forest:corp.contoso.com domainController:\DC.corp.contoso.com isDcAvailable:true }
PreJoinChecks Complete.
preCheckResult: Join
deviceKeysHealthy: undefined
isJoined: undefined
isDcAvailable: YES
isSystem: YES
keyProvider: undefined
keyContainer: undefined
dsrInstance: undefined
elapsedSeconds: 0
resultCode: 0x0
Automatic device join pre-check tasks completed.
TenantInfo::Discover: DsrBeginDiscover failed. 0x80072ee2
DsrCmdJoinHelper::Join: TenantInfo::Discover failed with error code 0x801c0021.
DSREGCMD_END_STATUS
AzureAdJoined : NO
EnterpriseJoined : NO

Now, checking the Event viewer log Microsoft-Windows-User Device Registration/Admin, we can find a few errors related to communication against Azure AD:

The WinHTTP callback function failed. WINHTTP_STATUS_CALLBACK status code: 2097152 (WINHTTP_CALLBACK_STATUS_REQUEST_ERROR). Error: Unknown HResult Error code: 0x80072ee2

Checking the event viewer log Microsoft-Windows-User Device Registration/Debug filtering by event ID 500, we see the client trying to reach the Azure AD tenant after identifying in the Active Directory to which tenant the device should register.

TryGetADRegistrationConfiguration: read keywords found value azureADName:contoso.com

TryGetADRegistrationConfiguration: read keywords found value azureADId:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx

With the event below, we can see the HTTP request running under SYSTEM context.

With subsequent events, we see the error message returned from the request above:

WinHttpRequest::OnCallback: WINHTTP_ASYNC_RESULT dwResult: 5 (API_SEND_REQUEST), dwError: 0x00002ee2

WinHttpRequest::OnCallback: The callback handling failed with error code: 0x80072ee2

DsrCmdJoinHelper::Join: TenantInfo::Discover failed with error code 0x801c0021.

Back to event viewer log Microsoft-Windows-User Device Registration/Admin, filtering by event IDs 304 and 309, we can see the Azure DRS service discover phase has failed:

REASON: Due to network connectivity issues, the Automatic Device join task is not capable of authenticating the computer against Azure AD, failing on phase F explained in this Official Microsoft Article, that says:

The Automatic Device Join task triggers with each user sign-in or every hour, and tries to authenticate the computer to Azure AD using the corresponding private key of the public key in the userCertificate attribute. Azure AD authenticates the computer and issues an ID token to the computer.

FIX: The Automatic Device Join task run under the SYSTEM context and normal failure scenarios are related to proxy blocking the machine account from accessing the internet. If this is your case, best solution is to work with the network team to allow the device account to reach Azure AD without proxy authentication.

In my case, I’ve blocked the outbound communication from this machine to reproduce the failed network connectivity between the device and Azure AD. After removing the firewall rule, with a new sign-in to the machine, the Automatic Device Join task triggers again, and now we see a successful join:

Event Viewer Log: Microsoft-Windows-User Device Registration/Admin
Event IDs: 100 and 101

With the callback successful status, the discovery phase is working fine and the Automatic registration is succeeded.

And we confirm with the output of command dsregcmd /status, that the affected device has both Azure DomainJoined and AzureAdJoined set to YES.

+———————————————————————-+
| Device State |
+———————————————————————-+

         AzureAdJoined : YES
      EnterpriseJoined : NO
          DomainJoined : YES
            DomainName : CORP
           Device Name : WS10-Hybrid.corp.contoso.com

Summary

In this article, we covered how to investigate the error message ‘DsrCmdJoinHelper::Join: TenantInfo::Discover failed with error code 0x801c0021‘ when trying to turn a domain-joined device into Hybrid Azure AD Joined.

I hope you have enjoyed reading this article, and it helps you manage your Hybrid devices in Azure AD.

Enjoyed the article? Like and share. 🙂

Note: I do not represent the organization I work for, all the opinions expressed here, are my own. This post is provided AS IS with no warranties or guarantees and confers no rights.

In case you have any suggestions or feedback, please leave a comment.

[ ]’s
Ulysses Neves



2 thoughts on “Azure AD Hybrid Device Join – Troubleshooting error code 0x801c0021 during the ‘discover’ phase”

  1. Kris says:
    7 de July de 2023 at 07:25

    I have this, but on testing connectivity, it works fine under system context – but i still get the above error and cannot hybrid join any machines.

    We dont use a proxy either….

    As per here: https://techcommunity.microsoft.com/t5/microsoft-intune/still-can-t-get-endpoints-azure-ad-hybrid-joined/m-p/3868061

    Reply
    1. Uneves says:
      16 de July de 2023 at 13:50

      Hi Kris, Thanks for bringing your comment here. The proxy blocking authentication under SYSTEM context is just one scenario that can block the device registration, but there are other scenarios like local configurations via GPO or missing requirements. Normally, the command dsregcmd /status gives you more information on what is preventing the Hybrid join to occur. If you are familiar with the Windows Event viewer, the events mentioned in my article can give you more details and help in the troubleshooting. I would recommend checking the requirements public doc https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-hybrid-azure-ad-join#prerequisites, but if you still face the issue, best would be to open a ticket with Microsoft to get proper support.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Microsoft Authenticator Will Block Jailbroken Devices in 2026 — What You Need to Know 17 de March de 2026
  • Enhancing Azure role activation security with FIDO2/Passkeys 23 de September de 2024
  • Microsoft Entra ID CAP | Enforcing WHfB using Authentication Strength 21 de April de 2024
  • Troubleshooting Error Code ‘0x000005e’ in WHfB: PIN Authentication Woes 11 de February de 2024
  • WHfB: Fixing Windows Hello for Business error ‘LogoncertTemplateReady: NO (StateNoTemplate)’ 29 de December de 2023

Archives

  • March 2026
  • September 2024
  • April 2024
  • February 2024
  • December 2023
  • September 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019

Tags

#aaddownleveldevice #aadhybridjoin #adfs #adfsonsql #azuread #azureauth #azureCA #azuredevice #azurehybridjoin #azuremfa #azuresecurity #capolicy #cloudkerberostrust #conditionalaccess #conditionalaccesspolicy #deviceregistration #gmsaaccount #gopasswordless #hybridaadjoin #mfaserver #msadfs #msazure #msidentity #namedlocation #sslcertificatevalidation #tshootadfs #tshoothybridjoin #tshootwaptrust #waptrust #WHFBcerttrust #whfbdeployment #WHfBhybridsetup #widdatabase adconnect authenticationcontext authenticationstrength az500 azuread azuremfa azurepim azuresecurity cloudsecurity microsoft365 msazure WHfB
©2026 Ulysses Neves | Design: Newspaperly WordPress Theme
Ulysses Neves
Gerenciar Consentimento de Cookies
Para fornecer as melhores experiências, usamos tecnologias como cookies para armazenar e/ou acessar informações do dispositivo. O consentimento para essas tecnologias nos permitirá processar dados como comportamento de navegação ou IDs exclusivos neste site. Não consentir ou retirar o consentimento pode afetar negativamente certos recursos e funções.
Funcional Always active
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos. O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
Ver preferências
  • {title}
  • {title}
  • {title}