How to configure automatic registration of Windows domain-joined devices with Azure Active Directory

To use Azure Active Directory device-based conditional access, your computers must be registered with Azure Active Directory (Azure AD). You can get a list of registered devices in your organization by using the Get-MsolDevice cmdlet in the Azure Active Directory PowerShell module.

This article provides you with the steps for configuring the automatic registration of Windows domain-joined devices with Azure AD in your organization.

For more information about:

Before you begin

Before you start configuring the automatic registration of Windows domain-joined devices in your environment, you should familiarize yourself with the supported scenarios and the constraints.

To improve the readability of the descriptions, this topic uses the following term:

  • Windows current devices - This term refers to domain-joined devices running Windows 10 or Windows Server 2016.
  • Windows down-level devices - This term refers to all supported domain-joined Windows devices that are neither running Windows 10 nor Windows Server 2016.

Windows current devices

  • For devices running the Windows desktop operating system, we recommend using Windows 10 Anniversary Update (version 1607) or later.
  • The registration of Windows current devices is supported in non-federated environments such as password hash sync configurations.

Windows down-level devices

  • The following Windows down-level devices are supported:
    • Windows 8.1
    • Windows 7
    • Windows Server 2012 R2
    • Windows Server 2012
    • Windows Server 2008 R2
  • The registration of Windows down-level devices is not supported for:
    • Non-federated environments (password hash sync configurations).
    • Devices using roaming profiles. If you are relying on roaming of profiles or settings, use Windows 10.

Prerequisites

Before you start enabling the auto-registration of domain-joined devices in your organization, you need to make sure that you are running an up-to-date version of Azure AD connect.

Azure AD Connect:

  • Keeps the association between the computer account in your on-premises Active Directory (AD) and the device object in Azure AD.
  • Enables other device related features like Windows Hello for Business.

Configuration steps

This topic includes the required steps for all typical configuration scenarios.
Use the following table to get an overview of the steps that are required for your scenario:

Steps Windows current and password hash sync Windows current and federation Windows down-level
Step 1: Configure service connection point Check Check Check
Step 2: Setup issuance of claims Check Check
Step 3: Enable non-Windows 10 devices Check
Step 4: Control deployment and rollout Check Check Check
Step 5: Verify registered devices Check Check Check

Step 1: Configure service connection point

The service connection point (SCP) object is used by your devices during the registration to discover Azure AD tenant information. In your on-premises Active Directory (AD), the SCP object for the auto-registration of domain-joined devices must exist in the configuration naming context partition of the computer's forest. There is only one configuration naming context per forest. In a multi-forest Active Directory configuration, the service connection point must exist in all forests containing domain-joined computers.

You can use the Get-ADRootDSE cmdlet to retrieve the configuration naming context of your forest.

For a forest with the Active Directory domain name fabrikam.com, the configuration naming context is:

CN=Configuration,DC=fabrikam,DC=com

In your forest, the SCP object for the auto-registration of domain-joined devices is located at:

CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your Configuration Naming Context]

Depending on how you have deployed Azure AD Connect, the SCP object may have already been configured. You can verify the existence of the object and retrieve the discovery values using the following Windows PowerShell script:

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";

$scp.Keywords;

The $scp.Keywords output shows the Azure AD tenant information, for example:

azureADName:microsoft.com
azureADId:72f988bf-86f1-41af-91ab-2d7cd011db47

If the service connection point does not exist, you can create it by running the Initialize-ADSyncDomainJoinedComputerSync cmdlet on your Azure AD Connect server.
The cmdlet:

  • Creates the service connection point in the Active Directory forest Azure AD Connect is connected to.
  • Requires you to specify the AdConnectorAccount parameter. This is the account that is configured as Active Directory connector account in Azure AD connect.

The following script shows an example for using the cmdlet. In this script, $aadAdminCred = Get-Credential requires you to type a user name. You need to provide the user name in the user principal name (UPN) format (user@example.com).

Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";

$aadAdminCred = Get-Credential;

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

The Initialize-ADSyncDomainJoinedComputerSync cmdlet:

  • Uses the Active Directory PowerShell module, which relies on Active Directory Web Services running on a domain controller. Active Directory Web Services is supported on domain controllers running Windows Server 2008 R2 and later.
  • Is only supported by the MSOnline PowerShell module version 1.1.166.0. To download this module, use this link.

For domain controllers running Windows Server 2008 or earlier versions, use the script below to create the service connection point.

In a multi-forest configuration, you should use the following script to create the service connection point in each forest where computers exist:

$verifiedDomain = "contoso.com"    # Replace this with any of your verified domain names in Azure AD
$tenantID = "72f988bf-86f1-41af-91ab-2d7cd011db47"    # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com"    # Replace this with your AD configuration naming context

$de = New-Object System.DirectoryServices.DirectoryEntry
$de.Path = "LDAP://CN=Services," + $configNC

$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")
$deDRC.CommitChanges()

$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)

$deSCP.CommitChanges()

Step 2: Setup issuance of claims

In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a 3rd party on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).

Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint (either 1.3 or 2005 versions) hosted by the on-premises federation service.

Note

When using AD FS, either adfs/services/trust/13/windowstransport or adfs/services/trust/2005/windowstransport must be enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. You can see what end-points are enabled through the AD FS management console under Service > Endpoints.

If you don’t have AD FS as your on-premises federation service, follow the instructions of your vendor to make sure they support WS-Trust 1.3 or 2005 end-points and that these are published through the Metadata Exchange file (MEX).

The following claims must exist in the token received by Azure DRS for device registration to complete. Azure DRS will create a device object in Azure AD with some of this information which is then used by Azure AD Connect to associate the newly created device object with the computer account on-premises.

  • http://schemas.microsoft.com/ws/2012/01/accounttype
  • http://schemas.microsoft.com/identity/claims/onpremobjectguid
  • http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

If you have more than one verified domain name, you need to provide the following claim for computers:

  • http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid

If you are already issuing an ImmutableID claim (e.g., alternate login ID) you need to provide one corresponding claim for computers:

  • http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID

In the following sections, you find information about:

  • The values each claim should have
  • How a definition would look like in AD FS

The definition helps you to verify whether the values are present or if you need to create them.

Note

If you don’t use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims.

Issue account type claim

http://schemas.microsoft.com/ws/2012/01/accounttype - This claim must contain a value of DJ, which identifies the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:

@RuleName = "Issue account type for domain-joined computers"
c:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value = "DJ"
);

Issue objectGUID of the computer account on-premises

http://schemas.microsoft.com/identity/claims/onpremobjectguid - This claim must contain the objectGUID value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:

@RuleName = "Issue object GUID for domain-joined computers"
c1:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    store = "Active Directory", 
    types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), 
    query = ";objectguid;{0}", 
    param = c2.Value
);

Issue objectSID of the computer account on-premises

http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid - This claim must contain the the objectSid value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:

@RuleName = "Issue objectSID for domain-joined computers"
c1:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);

Issue issuerID for computer when multiple verified domain names in Azure AD

http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid - This claim must contain the Uniform Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or 3rd party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that specific order after the ones above. Please note that one rule to explicitly issue the rule for users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added.

@RuleName = "Issue account type with the value User when its not a computer"
NOT EXISTS(
[
    Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value == "DJ"
]
)
=> add(
    Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
    Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value == "User"
]
=> issue(
    Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
    Value = regexreplace(
    c1.Value, 
    ".+@(?<domain>.+)", 
    "http://${domain}/adfs/services/trust/"
    )
);

@RuleName = "Issue issuerID for domain-joined computers"
c:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
    Value = "http://<verified-domain-name>/adfs/services/trust/"
);

In the claim above,

  • $<domain> is the AD FS service URL
  • <verified-domain-name> is a placeholder you need to replace with one of your verified domain names in Azure AD

For more details about verified domain names, see Add a custom domain name to Azure Active Directory.
To get a list of your verified company domains, you can use the Get-MsolDomain cmdlet.

Get-MsolDomain

Issue ImmutableID for computer when one for users exist (e.g. alternate login ID is set)

http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID - This claim must contain a valid value for computers. In AD FS, you can create an issuance transform rule as follows:

@RuleName = "Issue ImmutableID for computers"
c1:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
] 
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    store = "Active Directory", 
    types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), 
    query = ";objectguid;{0}", 
    param = c2.Value
);

Helper script to create the AD FS issuance transform rules

The following script helps you with the creation of the issuance transform rules described above.

$multipleVerifiedDomainNames = $false
$immutableIDAlreadyIssuedforUsers = $false
$oneOfVerifiedDomainNames = 'example.com'   # Replace example.com with one of your verified domains

$rule1 = '@RuleName = "Issue account type for domain-joined computers"
c:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value = "DJ"
);'

$rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
c1:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    store = "Active Directory", 
    types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), 
    query = ";objectguid;{0}", 
    param = c2.Value
);'

$rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
c1:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(claim = c2);'

$rule4 = ''
if ($multipleVerifiedDomainNames -eq $true) {
$rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
NOT EXISTS(
[
    Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value == "DJ"
]
)
=> add(
    Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value = "User"
);

@RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
c1:[
    Type == "http://schemas.xmlsoap.org/claims/UPN"
]
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
    Value == "User"
]
=> issue(
    Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
    Value = regexreplace(
    c1.Value, 
    ".+@(?<domain>.+)", 
    "http://${domain}/adfs/services/trust/"
    )
);

@RuleName = "Issue issuerID for domain-joined computers"
c:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
    Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
);'
}

$rule5 = ''
if ($immutableIDAlreadyIssuedforUsers -eq $true) {
$rule5 = '@RuleName = "Issue ImmutableID for computers"
c1:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
    Value =~ "-515$", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
] 
&& 
c2:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
]
=> issue(
    store = "Active Directory", 
    types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), 
    query = ";objectguid;{0}", 
    param = c2.Value
);'
}

$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules 

$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5

$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules 

Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString 

Remarks

  • This script appends the rules to the existing rules. Do not run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again.

  • If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains cmdlet), set the value of $multipleVerifiedDomainNames in the script to $true. Also make sure that you remove any existing issuerid claim that might have been created by Azure AD Connect or via other means. Here is an example for this rule:

    c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
    => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)",  "http://${domain}/adfs/services/trust/")); 
  • If you have already issued an ImmutableID claim for user accounts, set the value of $immutableIDAlreadyIssuedforUsers in the script to $true.

Step 3: Enable Windows down-level devices

If some of your domain-joined devices Windows down-level devices, you need to:

  • Set a policy in Azure AD to enable users to register devices.

  • Configure your on-premises federation service to issue claims to support Integrated Windows Authentication (IWA) for device registration.

  • Add the Azure AD device authentication end-point to the local Intranet zones to avoid certificate prompts when authenticating the device.

Set policy in Azure AD to enable users to register devices

To register Windows down-level devices, you need to make sure that the setting to allow users to register devices in Azure AD is set. In the Azure portal, you can find this setting under:

Azure Active Directory > Users and groups > Device settings

The following policy must be set to All: Users may register their devices with Azure AD

Register devices

Configure on-premises federation service

Your on-premises federation service must support issuing the authenticationmehod and wiaormultiauthn claims when receiving an authentication request to the Azure AD relying party holding a resouce_params parameter with an encoded value as shown below:

eyJQcm9wZXJ0aWVzIjpbeyJLZXkiOiJhY3IiLCJWYWx1ZSI6IndpYW9ybXVsdGlhdXRobiJ9XX0

which decoded is {"Properties":[{"Key":"acr","Value":"wiaormultiauthn"}]}

When such a request comes, the on-premises federation service must authenticate the user using Integrated Windows Authentication and upon success, it must issue the following two claims:

http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
http://schemas.microsoft.com/claims/wiaormultiauthn

In AD FS, you must add an issuance transform rule that passes-through the authentication method.

To add this rule:

  1. In the AD FS management console, go to AD FS > Trust Relationships > Relying Party Trusts.
  2. Right-click the Microsoft Office 365 Identity Platform relying party trust object, and then select Edit Claim Rules.
  3. On the Issuance Transform Rules tab, select Add Rule.
  4. In the Claim rule template list, select Send Claims Using a Custom Rule.
  5. Select Next.
  6. In the Claim rule name box, type Auth Method Claim Rule.
  7. In the Claim rule box, type the following rule:

    c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] => issue(claim = c);

  8. On your federation server, type the PowerShell command below after replacing <RPObjectName> with the relying party object name for your Azure AD relying party trust object. This object usually is named Microsoft Office 365 Identity Platform.

    Set-AdfsRelyingPartyTrust -TargetName <RPObjectName> -AllowedAuthenticationClassReferences wiaormultiauthn

Add the Azure AD device authentication end-point to the Local Intranet zones

To avoid certificate prompts when users in register devices authenticate to Azure AD you can push a policy to your domain-joined devices to add the following URL to the Local Intranet zone in Internet Explorer:

https://device.login.microsoftonline.com

Step 4: Control deployment and rollout

When you have completed the required steps, domain-joined devices are ready to automatically register with Azure AD. All domain-joined devices running Windows 10 Anniversary Update and Windows Server 2016 automatically register with Azure AD at device restart or user sign-in. New devices register with Azure AD when the device restarts after the domain join operation is completed.

Devices that were previously workplace-joined to Azure AD (for example for Intune) transition to “Domain Joined, AAD Registered”; however it takes some time for this process to complete across all devices due to the normal flow of domain and user activity.

Remarks

  • You can use a Group Policy object to control the rollout of automatic registration of Windows 10 and Windows Server 2016 domain-joined computers.

  • Windows 10 November 2015 Update automatically registers with Azure AD only if the rollout Group Policy object is set.

  • To rollout the automatic registration of Windows down-level computers, you can deploy a Windows Installer package to computers that you select.

  • If you push the Group Policy object to Windows 8.1 domain-joined devices, registration will be attempted; however it is recommended that you use the Windows Installer package to register all your Windows down-level devices.

Create a Group Policy object

To control the rollout of automatic registration of Windows current computers, you should deploy the Register domain-joined computers as devices Group Policy object to the devices you want to register. For example, you can deploy the policy to an organizational unit or to a security group.

To set the policy:

  1. Open Server Manager, and then go to Tools > Group Policy Management.
  2. Go to the domain node that corresponds to the domain where you want to activate auto-registration of Windows current computers.
  3. Right-click Group Policy Objects, and then select New.
  4. Type a name for your Group Policy object. For example, Automatic Registration to Azure AD. Select OK.
  5. Right-click your new Group Policy object, and then select Edit.
  6. Go to Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration. Right-click Register domain-joined computers as devices, and then select Edit.

    Note

    This Group Policy template has been renamed from earlier versions of the Group Policy Management console. If you are using an earlier version of the console, go to Computer Configuration > Policies > Administrative Templates > Windows Components > Workplace Join > Automatically workplace join client computers.

  7. Select Enabled, and then select Apply.

  8. Select OK.
  9. Link the Group Policy object to a location of your choice. For example, you can link it to a specific organizational unit. You also could link it to a specific security group of computers that automatically register with Azure AD. To set this policy for all domain-joined Windows 10 and Windows Server 2016 computers in your organization, link the Group Policy object to the domain.

Windows Installer packages for non-Windows 10 computers

To register domain-joined Windows down-level computers in a federated environment, you can download and install these Windows Installer package (.msi) from Download Center at the Microsoft Workplace Join for non-Windows 10 computers page.

You can deploy the package by using a software distribution system like System Center Configuration Manager. The package supports the standard silent install options with the quiet parameter. System Center Configuration Manager Current Branch offers additional benefits from earlier versions, like the ability to track completed registrations. For more information, see System Center Configuration Manager.

The installer creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows. The task silently registers the device with Azure AD with the user credentials after authenticating using Integrated Windows Authentication. To see the scheduled task, in the device, go to Microsoft > Workplace Join, and then go to the Task Scheduler library.

Step 5: Verify registered devices

You can check successful registered devices in your organization by using the Get-MsolDevice cmdlet in the Azure Active Directory PowerShell module.

The output of this cmdlet shows devices registered in Azure AD. To get all devices, use the -All parameter, and then filter them using the deviceTrustType property. Domain joined devices have a value of Domain Joined.

Next steps