Success with remote Windows Autopilot and hybrid Azure Active Directory join

By Jason Sandys – Senior Program Manager | Microsoft Endpoint Manager – Microsoft Intune

Anongoing goal at Microsoftis to create products and solutions that providea path to success,while meetingourcustomers where they are. One example is enabling hybrid Azure Active Directory(Azure AD)join forWindows endpoints during Autopilot provisioning. This postdiscusses requirements andrecommendations for implementinghybrid AzureADjoinfrom a remote location where the Windows endpoint cannot directly connect to a domain controller. For this remote scenario,customerswho are not yet ready to fully AzureADjoin their Windows endpointscan use a VPN solution toimplementremote provisioningwithAutopilot.

Keep in mind that whileMicrosoft fully supportshybrid AzureADjoin, we designedthis capabilityas an interim solution for existing endpoints. We strongly encourage customers to begin their planning and implementation of fullAzureAD-joined systems as soon as possible.

Compared to Azure AD join, the end-to-end solution for hybrid Azure AD joining systems from a remote location using Autopilot has multiple additional requirements and dependencies. To achieve a successful result, you need to orchestrate these requirements properly. These include the following:

• The Intune Connector for Active Directory
• A Win32-based VPN client
• Azure AD Connect
• A device certificate issued using SCEP support from Intune (assuming you use an auto-connecting VPN connection)
• An Intune domain join profile
• Microsoft Configuration Manager agent installation (if you are using co-management)

While there is no single path to success for all organizations,we have collected someguidelines,based on customer feedback and experience, to helpyouimplement remote Autopilot withhybrid AzureADjoin.

Set expectations.

Autopilot is notaclassic imagingsolutionor operating system deployment. Instead, it is acloudnative, user-driven provisioning solution that assumes the organization has embracedcloudnativemanagement and acloudnativeendpoint strategy.Theend goal of Autopilot is not to have an endpoint fully configured from the user's perspective when the Autopilot process completes. Instead, the goal is to enroll the endpoint into Intune and allow Intune to deploy necessary policies, applications, and updates. Some of this can and will happen during the Autopilot process. Wanting or expecting all of it to occur during Autopilot adds additional complexity (and thus points of possible failure) and time that the user must wait for it to complete before they can begin using the system.Westronglyrecommendonly deploying aminimum viable set of policies, configurations, and applications during Autopilot. For an excellent discussion of this topic, seeSelecting Required Apps for your Enrollment Status Page.

Understand the role of your on-premises resources.

Hybrid Azure Active Directory join may help you on your path to cloud native management, but this interim solution still requires connectivity to an on-premises resource. Specifically, this resource is your on-premises Active Directory and a domain controller within that AD domain, which endpoints use for many activities, including but not limited to the following:

• Authentication
• Hybrid Azure Active Directory join completion
• Initial user login and profile caching, i.e., cached credentials
• User password changes
• Group policy delivery

Autopilot does not change the nature of a classic AD domain-joined endpoint. These same constraints still limit you (and the endpoint).

Use a trusted VPN solution and client.

AVPN clientandgatewayis a significant component of this end-to-end solution.The most common way for customers to provide this VPNfunctionalityis to usea third-party VPN solution that Microsoft does not directly support. To be clear, we support customers' use of athird-partyVPNsolution, but we cannot directly support the solution itself or provide configuration guidance.Thevendorof the chosen VPN client and gatewayisresponsible forprovidingallhelp and support.

Note:The built-in Windows 10 VPN client is supported but requiresaseparate VPN concentratoror gatewaywhich may add complexity to the configuration of the VPN profile in Intune. For a walkthrough that usesthe built-in Windows 10 VPN client, seeTrying out Autopilot hybrid join over VPN in your Azure lab.

Configure the VPN solution to auto-connect.

Doing thiseliminates a manual task that the interactive user must perform(and know to perform) before they can successfullysignintotheendpoint.Correctly configuringthe VPN client to auto-connect is specific to each vendor’s VPN client implementation,relies on the successfulissuanceof a certificateto theendpointby Intune, and assumes the VPN clientcan use the issued device certificate.

Keep in mind that auto-connecting VPNs have possible security implications. As with many potential security risks, you must weigh the risk against the realized usability gain. You should consult your VPN vendor, internal security personnel, and policies for guidance.

Note: Many VPN solutions verify the certificate subject name (SN) or subject alternative name (SAN) against the Windows computer object in AD. For Intune to deliver a device certificate with these details, configure the Intune SCEP profile with a replacement variable in the certificate template’s SN or SAN field: {{FullyQualifiedDomainName}}. This forces Intune to issue and deliver the device certificate after the Windows domain object is successfully created with the proper name in either the SN or SAN field.

Stick with Active Directory Federation Services (AD FS) if you have it deployed already.

WithoutADFSin the picture, thehybrid AzureADjoinprocess requiresAzureADConnect to synchronize an endpoint-generated certificate to yourAzureADtenant. Thissynchronizationprocessoccurs (by default) every 30 minutes.Thus, for an individual endpoint,hybrid AzureADjoincompletion may take up to 30 minutes (or more depending on additional factors).ADFSdoes not require this certificate synchronization, and there is no delay in completing thehybrid AzureADjoinprocess.

Adopt a simple naming convention.

Complex naming schemes are fragile constructsthattheAutopilot solution for hybrid Azure ADjoined endpointsdoes not directly support.Instead ofrelying on endpointnamingforIntune profiletargetingor organizational purposes, usesustainableand deterministicmechanismsthatdependon endpoint characteristicsorclearadministrative intent. These mechanismsincludestatic Azure AD security groups,dynamic Azure AD security groups,andIntunefilters.Using these mechanismsenables you to have the best and most flexible experience.

Disable the user Enrollment Status Page if you are not using AD FS.

TheuserphaseoftheEnrollmentStatusPage(ESP)and the items it tracks only work if theendpointhas completed thehybrid AzureADjoinprocess. Without a successfulhybrid AzureADjoinof the endpoint, the user cannot authenticate toAzureAD, and therefore, Intune cannot deliver policy for that user. This leads to errors and theESPeventually timesout.If you targetIntune profiles, policies, or applications at usersthatareenforcedduring Autopilot,disable the user ESPphaseusing the instructions atHow can I disable the ESP if it has been configured on the device.

Use a single trusted forest only.

The current design of the Intune connector does not account for any complexity within the on-premises AD environment, including untrusted forests or AD site replication.While youmay not be able or want to adjust your AD environment to account for Autopilot, these complexities will lead to delays due toAD replicationor failureseven within a single trusted forest or domain.

Do not deploy the Microsoft Endpoint Configuration Manager client agent during Autopilot.

Doing so is strictly unsupported because of the identity change that the endpoint undergoes during Autopilot when the endgoal for the endpoint ishybrid AzureADjoin. Seethe noteunderWindows Autopilotfor the documented support statement. Alternatives include all other valid forms of deploying the client agent,as documentedinHow to deploy clients to Windows computers in Configuration Managerwith the caveat that this must occurafterAutopilot completes.

Adjust your application deployment.

In addition to setting your expectations for the Autopilot process, you should adapt your implementation of the applications that you expect Intune to deploy during Autopilot. This adjustment includes the following considerations:

• Prevent reboots initiated by application installers. Autopilot does not deal well with unexpected reboots; therefore, ensure you've correctly adjusted the command line for any application installers to suppress or prevent endpoint restarts.
  
  
• Use only Win32 apps to deploy applications during Autopilot. While not strictly required, mixing line-of-business (LOB) applications and Win32 app installations during Autopilot can lead to sporadic conflicts in the Windows Installer service. These conflicts are due to the asynchronous nature of Intune policy delivery and enforcement and are unpredictable and challenging to troubleshoot.
  
  
• Use dependencies sparingly. Sometimes, you cannot avoid dependencies, for example, when an application depends on a common framework or library. Autopilot fully supports using dependencies between Win32 apps; however, excessive use can lead to complex scenarios leading to failures. We did not design Autopilot to mimic a task sequence's full deterministic behavior, and you should avoid trying to emulate it using dependencies. 

Initiating Autopilot from a remote location whilehybrid AzureADjoining the endpointhas its challenges;however, many organizations successfully utilizethis scenarioby followingsome orallthe guidanceabove.Each recommendation has its pros and consthat you must consider, but eachwillincrease your overall success rate.When implementing thisscenario, keep the process simple, manageexpectations, anddon’taim torecreate the result or experience oftraditionaloperating system deployment. 

Finally, keep in mind thathybridAzureADjoining new systems isintendedto bean interim solution for organizations that are not yet fully prepared toAzureADjoin their Windows endpoints. Thus, whileyou cantakeadvantage of the capability tohybridAzureADjoin a remote systemduring Autopilot, you should plan for and begin piloting fullAzureADjoinfor yourWindows endpointsas soon as possible.SeeAzure AD joined devicesforfurther detailsandGetting started with cloud native Windows endpoints with Microsoft Endpoint Managerfor a complete walkthrough.

If you have questions or comments for the Intune team, reply to this post or reach out to @IntuneSuppTeam on Twitter.