Why and how you should register your Windows 10 Domain Joined PC’s with Azure AD

Domain joining a PC has been the way for companies in a long time to make sure they have a common identity inside their network and control of the PCs in their network. This does not change with Windows 10. However new possibilities come to play when Azure AD becomes a part of the picture.

  • You get Single Sign On (SSO) towards work resources in the cloud. That means that users don’t receive any authentication prompts when they access resources like Office 365 portal and other federated Azure SaaS apps ( from outside the company network. And you will also get SSO from inside your company network without using ADSF as you need to do today.
  • Enterprise roaming of user settings between devices. The user setting no longer roam via you Microsoft Account (MSA), but now uses your AzureAD for roaming. This means that you don’t need an MSA to enable synchronization of setting. (This feature is not available in Azure AD as of today, but should be coming soon.
  • Access to Windows Store for business using AD Account enabling the users to download and install the preselected apps of their company from the companys partion of the Windows Store without using an Microsoft Account
  • Microsoft Passport for Work and Windows Hello
  • Conditional Access to both On-premises and Cloud resources like SaaS Apps and E-Mail.

To make this magic happen you will need the latest version of AAD Connect and a Group Policy. When this is in place the domain joined Windows 10 computer will automaticly register in Azure AD.

So how to this work?

When the Group Policy is applied on the Windows 10 Computer the device registration will trigger. If the policy is configured on Windows 10 it is located at:
Computer Configuration/Policies/Administrative Templates/Windows Components/Device Registration

If the policy is configured from a Windows Server 2012 R2 it is located at:
Computer Configuration/Policies/Administrative Templates/Windows Components/Workplace Join

The Group Policy will create a task in Task Scheduler on the device with the name Automatic-Device-Join. This task which run as SYSTEM reaches out to AD using the computer identity to find Azure AD tenant information. For more detailed information please take a look at Connect domain-joined devices to Azure AD for Windows 10 experiences

Now the computer authenticates it self to Azure AD either through ADFS or directly if you have configured you enviroment without ADFS using password hash sync.


If you are using ADSF the device authenticates to Azure Device Registration Service (DRS) using Windows Integrated Authentication (Kerberos). Claims are passed to Azure AD via ADSF during authentication and are written as attributes in the newly created device object. The attributes are Object GUID and SID of computer object on-prem and Claims stating that computer is domain joined.

If you are not using ADSF the task will create a credential in the form of a self-signed certificate and will register the computer via LDAP in the userCertificates attribute. AAD Connect detects that the computer has registered this credentials and syncs this to Azure AD as a device object holding this credential, the object GUID and the Computer SID. The task will use this credentials to authenticate to Azure DRS directly once the device is created in Azure AD.

There will be a delay between when the policy is applied on the computer and the device ready for regsitration. This is because information needs to sync up via AAD Connect in this scenario.

The task will generate a private/public key pair to be used in a certificate signing request (CSR) to Azure DRS to obtain the certificate that the device will use to authenticate to Azure AD later on. If the device has a TPM the private keys will be hardware protected on the device.

Finaly the task sends the CSR obtaining the certificate and places it in the LocalMachine\My store and a device object is created in Azure AD with the certificate thumbprint associated with it.

Now the user will enjoy the new features I started with and IT will also be able to restrict access to only devices that are domain joined or compliant.

Jan Ketil Skanke

Jan Ketil is an Enterprise Mobility MVP since 2016 and are working as a COO and Principal Cloud Architect at CloudWay in Norway. He has been in the industry for more than 20 years working for both Microsoft Partners and Microsoft. He loves to speak about anything around Enterprise Mobility and Secure Productivity. He is also the lead for the community conference Experts Live Norway. Jan Ketil has presented at large industry conferences like Microsoft Ignite, Microsoft Ignite The Tour, Microsoft Inspire, Experts Live Europe, Techmentor HQ (3rd best session 2019) and NIC Conference in Oslo.


  • I am seeing the following error when I run this command under SYSTEM context. Any suggestions on troubleshooting the DRS discovery for the tenant info?

    dsregcmd.exe /debug
    dsregcmd::wmain logging initialized.
    DsrCmdAccountMgr::IsDomainControllerAvailable DsGetDcName success { domain:domain.internal forest:domain.internal domainController:\\MYDC.domain.internal isDcAvailable:true }
    PreJoinChecks Complete.
    preCheckResult: Join
    isPrivateKeyFound: 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. 0x80072f8f
    wmain TenantInfo::Discover failed with error code 0x801c0021.
    AzureAdJoined : NO
    EnterpriseJoined : NO

    • You need to verify that your devices are synced to Azure AD. The Device OU needs to by in sync scope. Also you can see in Eventviewer under Applications and Services logs-Microsoft-Windows-AAD for errors. I see this specific error if the device is not synced to AAD.

  • Sounds great.
    Does it mean every Azure AD users who logs on an AD DS joined computer will be automatically workplace joined?

  • How can you view Win 10 devices on azure ad that are both domain and azure joined?
    Also, if you try to enable Bitlocker it prompts you to save the key on the cloud. How can I view the key since in this case the device is not tied to a specific user?

  • Interesting read. Thanks.
    When I run with the /debug paramter, it get this:

    DsrCmdAccountMgr::IsDomainControllerAvailable DsGetDcName success { domainController:\DKDN01DCxx.xxxx.yyy isDcAvailable:true }
    wmain TenantInfo::Discover failed with error code 0x80070057.

    Any idea?

    • First question: are you running the command in System and not as a user?
      Second question: Have you setup the SCP for AAD Registration to work?

      Domain-joined devices will use the service connection point to discover Azure AD tenant information at the time of automatic registration with the Azure device registration service.

      On the Azure AD Connect server, run the following PowerShell commands:
      Import-Module -Name “C:Program FilesMicrosoft Azure Active Directory ConnectAdPrepAdSyncPrep.psm1”;

      $aadAdminCred = Get-Credential;

      Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;

      For more details look here:

  • Hi

    Thanks for the article.

    I am done all the configuration but still untill to join the devices(windows 10) to Azure AD. And I do not see the scheduled task on the client devices(win 10) . Group polices has been modified to apply the auto devices registration settings. Is there any way to troubleshoot?

    Thanks heap

    • The first you need to do is to check / find the scheduled task in Task Scheduler, it should be in this location:
      MicrosoftWindowsWorkplace Join

      If should also have a status of Ready and trigger at logon of any user. Here you can also see the last run result.

      If you want to do some more troubleshooting you can also manually run the command in the task with debug flag in a admin command prompt:

      %SystemRoot%System32dsregcmd.exe /debug
      Look at the output and see if you find any errors.


Categories use cookies to ensure that we give you the best experience on our website.