Tuesday, September 14, 2021

Success with remote Windows Autopilot and hybrid Azure Active Directory join

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

 

An ongoing goal at Microsoft is to create products and solutions that provide a path to success, while meeting our customers where they are. One example is enabling hybrid Azure Active Directory (Azure AD) join for Windows endpoints during Autopilot provisioning. This post discusses requirements and recommendations for implementing hybrid Azure AD join from a remote location where the Windows endpoint cannot directly connect to a domain controller. For this remote scenario, customers who are not yet ready to fully Azure AD join their Windows endpoints can use a VPN solution to implement remote provisioning with Autopilot.

 

Keep in mind that while Microsoft fully supports hybrid Azure AD join, we designed this capability as an interim solution for existing endpoints. We strongly encourage customers to begin their planning and implementation of full Azure AD-joined systems as soon as possible.

 

Solution requirements 

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:

 

 

Recommendations for success 

While there is no single path to success for all organizations, we have collected some guidelines, based on customer feedback and experience, to help you implement remote Autopilot with hybrid Azure AD join.

 

Set expectations.

Autopilot is not a classic imaging solution or operating system deployment. Instead, it is a cloud native, user-driven provisioning solution that assumes the organization has embraced cloud native management and a cloud native endpoint strategy. The end 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. We strongly recommend only deploying a minimum viable set of policies, configurations, and applications during Autopilot. For an excellent discussion of this topic, see Selecting 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.

A VPN client and gateway is a significant component of this end-to-end solution. The most common way for customers to provide this VPN functionality is to use a third-party VPN solution that Microsoft does not directly support. To be clear, we support customers' use of a third-party VPN solution, but we cannot directly support the solution itself or provide configuration guidance. The vendor of the chosen VPN client and gateway is responsible for providing all help and support.

 

Note: The built-in Windows 10 VPN client is supported but requires a separate VPN concentrator or gateway which may add complexity to the configuration of the VPN profile in Intune. For a walkthrough that uses the built-in Windows 10 VPN client, see Trying out Autopilot hybrid join over VPN in your Azure lab.

 

Configure the VPN solution to auto-connect.

Doing this eliminates a manual task that the interactive user must perform (and know to perform) before they can successfully sign in to the endpoint. Correctly configuring the VPN client to auto-connect is specific to each vendor’s VPN client implementation, relies on the successful issuance of a certificate to the endpoint by Intune, and assumes the VPN client can 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.

Without AD FS in the picture, the hybrid Azure AD join process requires Azure AD Connect to synchronize an endpoint-generated certificate to your Azure AD tenant. This synchronization process occurs (by default) every 30 minutes. Thus, for an individual endpoint, hybrid Azure AD join completion may take up to 30 minutes (or more depending on additional factors). AD FS does not require this certificate synchronization, and there is no delay in completing the hybrid Azure AD join process.

 

Adopt a simple naming convention.

Complex naming schemes are fragile constructs that the Autopilot solution for hybrid Azure AD joined endpoints does not directly support. Instead of relying on endpoint naming for Intune profile targeting or organizational purposes, use sustainable and deterministic mechanisms that depend on endpoint characteristics or clear administrative intent. These mechanisms include static Azure AD security groups, dynamic Azure AD security groups, and Intune filters. Using these mechanisms enables you to have the best and most flexible experience.

 

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

The user phase of the Enrollment Status Page (ESP) and the items it tracks only work if the endpoint has completed the hybrid Azure AD join process. Without a successful hybrid Azure AD join of the endpoint, the user cannot authenticate to Azure AD, and therefore, Intune cannot deliver policy for that user. This leads to errors and the ESP eventually times out. If you target Intune profiles, policies, or applications at users that are enforced during Autopilot, disable the user ESP phase using the instructions at How 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 you may not be able or want to adjust your AD environment to account for Autopilot, these complexities will lead to delays due to AD replication or failures even 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 end goal for the endpoint is hybrid Azure AD join. See the note under Windows Autopilot for the documented support statement. Alternatives include all other valid forms of deploying the client agent, as documented in How to deploy clients to Windows computers in Configuration Manager with the caveat that this must occur after Autopilot 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. 

 

Summary

Initiating Autopilot from a remote location while hybrid Azure AD joining the endpoint has its challenges; however, many organizations successfully utilize this scenario by following some or all the guidance above. Each recommendation has its pros and cons that you must consider, but each will increase your overall success rate. When implementing this scenario, keep the process simple, manage expectations, and don’t aim to recreate the result or experience of traditional operating system deployment. 

 

Finally, keep in mind that hybrid Azure AD joining new systems is intended to be an interim solution for organizations that are not yet fully prepared to Azure AD join their Windows endpoints. Thus, while you can take advantage of the capability to hybrid Azure AD join a remote system during Autopilot, you should plan for and begin piloting full Azure AD join for your Windows endpoints as soon as possible. See Azure AD joined devices for further details and Getting started with cloud native Windows endpoints with Microsoft Endpoint Manager for a complete walkthrough.

 

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

Posted at https://sl.advdat.com/2Xt9rj8
Labels: ,