ConfigMgr admins have invested countless hours and effort in creating Task Sequences to perform various imaging functions in their environments. These are typically Bare Metal (New Computer), Refresh (Re-imaging of existing PC), and Replace (Migrating User Data to new computer). While there have been many enhancements to the Task Sequence engine over the years, the basic functionality and implementation of these mechanisms have largely remained static.
With the introduction of Autopilot, administrators now have a completely new method to handle these scenarios with a high degree of function parity between it and Task Sequences. While there are certain limitations to Autopilot as it exists today, these limitations shouldn’t preclude ConfigMgr admins from exploring Autopilot.
Author’s Note
Every image in this post includes a path at the top of the image to demonstrate where the particular policies can be found and/or created in Intune and Azure Active Directory. When referencing AAD, the organization name was replaced with “Azure AD” to make the instruction a little more obvious.
AAD Group Membership Rules
One of the functional differences between Intune and Autopilot vs ConfigMgr is that the former uses Azure Active Directory Groups to target policies, whereas the latter is primarily using Device Collections. Administrators can use queries that primarily leverage Active Directory Attributes to populate the AAD groups. While they are not as robust as the machine oriented WQL queries for ConfigMgr Device Collections, they are good enough to get the job done.
“ZTDId” is one of three options that can be leveraged in automatically populating a group for Autopilot deployments, and will likely suit most organizations needs, unless they are purchasing hardware from an OEM or Value Added Reseller. See here for more details on creating groups for hardware purchases.
Once this group is created, we can then target it for our various configurations and policies that makeup our Autopilot deployment.
Bare Metal
The Bare Metal Task Sequence, arguably the work-horse of any environment and likely the template for the other Task Sequences used in a production environment, will be the first Task Sequence to be replicated when starting with Autopilot.
Since Autopilot leaves the existing OEM applied image intact, including device drivers, there isn’t much to replicate in the WinPE phase. If there are steps that an admin is doing specifically in WinPE, such as altering the applied Windows image without having to manage the file permissions, these items would likely need to be scripted and applied with PowerShell.
Even though Autopilot does not require one to apply device drivers, this does not preclude an administrator from having to maintain both device drivers and firmware updates. The Drivers as a Service tool can be utilized to keep both Intune and ConfigMgr managed endpoints’ drivers updated, and as well as implementing Modern BIOS Management to maintain BIOS firmware.
Applications
Applications, both Win32 and Store can be deployed through Autopilot, either as a deployment to the specific Azure AD Group, or to All Users and All Devices.
- Important Point: Every policy that is to be assigned with Intune/Autopilot needs to have an “Assignment”, just like in the above image. This is analogous to a Deployment to a Collection in ConfigMgr. Each one of the following configuration items discussed below will have an Assignment pane in its configuration and the Autopilot Deployment AAD Group should be selected. One can select “All Users and All Groups” if it is required to have the configured policy applied globally.
If an administrator wishes to have a Windows Store app deployed to the Autopilot device, they would need to ensure that the app is set for “Offline” mode. It is also highly advisable to deploy the Company Portal app through Autopilot to make the end users’ on-boarding experience easier.
Domain Joining (Hybrid AAD Join Only)
If an administrator wishes to have their Autopilot deployed system joined with Hybrid Azure Active Directory, the policy to handle Domain Join exists in Device Configuration. Here the admin can specify the Domain, the OU, and a prefix for naming. The balance of the name will use random numbers.
Naming with AAD
If an administrator is using Azure AD Join, and not Hybrid, naming is handled a little differently. With the AAD OOBE, variables can be applied, along with a prefix, to create a meaningful and unique name. Also, the naming field is the primary difference between the AAD and Hybrid AAD deployment profile configuration.
Local Admin
There are a variety of ways to configure Local Administrator settings, like Accounts Configuration Service Provider (CSP) and through an Endpoint Protection Device Configuration profile. The below example is using Azure AD to add specific users to the local admin group, which is easier to setup than the previously mentioned methods. It is also global. The downside to it is there is no granularity, and if a non-global and granular configuration is required, the other policies are there to meet the organizational needs.
BitLocker + Other Security Settings
Enabling Bitlocker is handled through Device Configuration and can be found under Endpoint Protection. While there are many settings in this configuration item that are not available to the Enable Bitlocker step in the ConfigMgr Task Sequence, these items are available through traditional Group Policy.
Under the Endpoint Protection settings exists plenty of other security based configurations, including Firewall, the “Guards”, and other important options. It is worth evaluating these settings when crafting a proper production deployment.
Start Menu Layout
Instead of relying on a PowerShell command or a copy function to apply the Windows 10 Start Menu like in ConfigMgr, there is a policy to apply the template in a similar fashion to GPO. This policy also contains settings to control a variety of Start related options, such as Shut Down, Hibernate, and Pinning. There is so much more than in ConfigMgr.
While on this topic, it is quite possible that this common customization may become unfashionable after the widespread adoption of Windows 10 19H1 as Microsoft has changed how the default Start Menu is laid out. It is truly superb!
Default Application Association
Unfortunately, applying the default app association isn’t quite as simple as pointing DISM to the exported XML file. However, applying the association isn’t that difficult. Peter van der Woude has a great little write up on the process, just use the “Microsoft Intune standalone (Azure portal)” instructions.
Background Image
Lock Screen
Feature and Quality Updates
Installing updates, both Feature (i.e. Windows Version Upgrades) and Quality (i.e. Monthly Patches) can be configured to be applied via this policy. What is really nice is this policy will continue to be in effect, so long as the device stays in the ADD Group, meaning the patching policy isn’t just for provisioning. There is also control of installing and restarting behavior with Maintenance Time (Outside of Business hours), as well as configuration of restart notification Windows. There is a lot more here than what is in ConfigMgr’s WUfB policy.
Wireless Networking
Intune provides both a Basic and Enterprise Wi-Fi profile, depending on what the organization requires. The below example is the Basic configuration.
For Everything Else, There’s PowerShell
There are plenty of other configuration items that can be deployed to the Autopilot of which are beyond the scope of this post, but if there are any items missing, they can potentially be resolved with PowerShell.
One could easily remove Modern Apps with PowerShell, clear the Desktop of Icons (including Edge shortcut), enable Windows Features, and whatever else may need to be done to make the endpoint configuration on par with an existing Bare Metal Task Sequence.
Autopilot Drawbacks and an Upcoming Solution
While Autopilot and Task Sequences have largely achieved feature parity, there are some key places that ConfigMgr still has a clear advantage. Autopilot, by design, pulls all its content from the internet. While this is advantageous for building systems anywhere, many organizations are still building their systems in a room somewhere on-premises. Since Autopilot does not leverage Distribution Points, Delivery Optimization, or other content sharing mechanisms, this makes internet connection a bottleneck, can potentially increase internet service costs, and increase build time.
The other major drawback to Autopilot is that the build process only starts once the end user has logged in. This means that once the user has logged in during the Out of Box Experience, they must wait for all the application installations and configuration items to be applied. Depending on how complex of a build process has been implemented, the end user may have to wait a significant amount of time before the computer is usable.
With both of these drawbacks called out, it should be noted that during Ignite 2018, Microsoft announced “White Glove”, an upcoming feature addition to Autopilot that is intended to address these limitations. There hasn’t been much of anything published about White Glove since its announcement, and it is unknown when this feature will become available. But if it delivers what it is rumored to, it will make Autopilot that much more on par with ConfigMgr.
Final Thoughts….For Now
Autopilot has come along way since its inception, and it is very impressive to see a new technology gain much of the functionality of a much older and more developed solution. Autopilot can, and should, be deployed in tandem with ConfigMgr Task Sequences. It is an absolute game-changer in the realm of systems management, and just may usurp Task Sequences in popularity.
But if one needs to partition a hard drive, keep content strictly on-premises, or happens to lock themselves out of their Autopilot machines and cannot reset the computer, the Task Sequence will always be there.
Views: 19,779
