Evolving Autopilot Manager

A year ago, I released the Autopilot Manager to support Autopilot hash imports during Windows OOBE via an approval process (if not already familiar with Autopilot Manager, please read here Introducing Autopilot Manager first) and the solution is used by a lot of companies in the meanwhile. This is quite some time to discuss about features with people using the solution and receiving great feedback for better usage in enterprise contexts. So, I did quite a few additions to the solution which are helpful in various ways. I thought it is time to share these enhancements with all of you in a separate post. This post will focus on the Autopilot Manager enhancements I made and describes the intention why I added them to the solution. Let’s dive into it. In general, I implement enhancements normally in a way, that they are controlled by app service configurations, so they can be enabled or disabled on demand.

Table of content

• Customizable Timeout
• Deletion Requests
• Re-Register Mode
• Sending Audit data to Log Analytics
• Homepage Customization Options

Customizable Timeout

First of all, I received a lot of feedback to make the caching timeout value customizable, by default it was 60 minutes, which can now be configured to whatever is needed. The longer caching time is especially important for some organizations as helpdesk processes need some time and the user action to enter the command line is challenging enough to do once, so they prefer to keep the cached data longer to have more time to approve them. The following figure has a configured value of 2h:

To configure this, just add the following configuration:

AppConfig:AutopilotManagerConfig:Timeout to a value you like in minutes

Deletion Requests

Next I got requests to support the changed behavior during Autopilot. Microsoft Endpoint Manager changed the Windows Autopilot self-deployment mode and Pre-Provisioning mode (formerly known as white glove, in Public Preview) experience. To reuse a device, you must delete the device record created by Intune, otherwise you will see the following Error code 0x80180014 when re-enrolling using self-deployment or pre-provisioning mode.

Meaning if your Autopilot self-deployment or pre-provisioning fails you can’t go ahead and try it once more, you have to delete the Intune object first. In larger enterprise environments this is challenging as well. Imagine you have a staging area to prepare your pre-provisioned devices and a device fails. Now the technician must call the helpdesk to get the Intune device record deleted as the technician normally do not have the permission to do this by them own. To support a better workflow here, you can now use a new Autopilot Manager Client (ap.exe) parameter -e (e for erase) to invoke a deletion request. This request is cached like the import request and must be approved the same way. The functionality is only available in Approval Mode of Autopilot Manager. Now the process can be like this. Technicians in the staging area are preparing pre-provisioned devices and if one fails, they can do the delete request via ‘-e’ parameter and a person overseeing the pre-provisioning work can approve the request as he might have approval permissions. This way no help desk ticket or support request needs to be done and the break-fix to start over again the pre-provisioning is done in a fast way. No permission needs to be granted to the Intune portal.

The Deletion requests will show up like regular import request:

and are approved the same way:

To get this to work, you need to grant additional permissions on the App registration. Without this the app service will not be able to delete Intune devices:

DeviceManagementManagedDevices.ReadWrite.All

Keep in mind this is only available in Approval Mode of Autopilot Manager and you need to set the configuration:

AppConfig:AutopilotManagerConfig:AllowDeletionInApprovalMode to true

Re-Register Mode

The Re-Register Mode was invented as there is an operational workflow issue for most during break fix scenarios. Imagine a mainboard is broken (btw this is the most used case of Autopilot Manager break fix scenarios) and an OEM technician is coming on-site and replaces the mainboard. Often the technician will set the serial number of the old mainboard on the new replaced one to have an identical laptop (from management perspective) again. This is an important fact we use to implement the Re-Register mode. The issue here is now, that Autopilot will not recognize the device object anymore as a mainboard replacement needs you to de-register the device upfront and register it again after the replacement (see here Windows Autopilot motherboard replacement guidance). This process is very cumbersome and involves a lot of manual steps and the right timing to get the device up and running again. With Autopilot Re-Register mode, the way how Autopilot Manager is operating is changed. With Re-Register Mode the Autopilot Manager will search for the Intune and Autopilot object by serial number (remember the new mainboard will get the same serial number configured by the technician again) and will delete them upfront. After this the normal import of the Autopilot object will be processed again. This is helpful for Azure AD joined devices and mainboard replacement break fix scenarios as they are re-installed in such a case anyway. Motherboard replacement kills the TPM and therefore various vital keys for the OS. If your AADJ devices are maintained in a cloud managed approach this is not a big deal as data is anyway in OneDrive or other online storage locations. To enable this mode, you have to set the configuration:

AppConfig:AutopilotManagerConfig:UseReRegisterMode set tot True

The same like for the Deletion request you need to grant the additional permissions to be able to delete the Intune devices:

DeviceManagementManagedDevices.ReadWrite.All

A re-creation of the Autopilot object will lose the PurchaseOrderId on the Autopilot object. This is set during import initially by the OEM. If you depend on this value you can set:

AppConfig:AutopilotManagerConfig:PreservePurchaseOrderIdOnReRegister to true

which will preserve the value and set it during import of the new object again. The value can only be set during initial import, not afterwards.

Sending Audit data to Log Analytics

In enterprises you often have the need to see who has approved something during investigations. Initially I stored a history for 3 hours in the cache of the App service itself. This is still available but limited in terms of enterprise needs. To support better auditing, I implemented sending audit data to a log analytics instance via Data Collector API (see here Send log data to Azure Monitor by using the HTTP Data Collector API (preview)). If you configure the following configurations and let them point to your log analytics instance you will get audit data for every request and processing.

AppConfig:AutopilotManagerConfig:UseLogAnalytics set to true
AppConfig:AutopilotManagerConfig:LogAnalyticsWorkspaceId set to "your workspace GUID"
AppConfig:AutopilotManagerConfig:LogAnalyticsSharedKey set to "your shared workspace key"

This is pretty simple to setup. You need to create a Log Analytics workspace, follow this guide here Create a Log Analytics workspace in the Azure portal.

Then copy the workspace id and the shared key (primary or secondary key) to configure them in the app service configuration:

If you like to have the hardware id (aka hardware hash) also send to Log Analytics add the following configuration:

AppConfig:AutopilotManagerConfig:LogAnalyticsReportHardwareHash set to true or false

Finally, if everything is setup you will see the following entries in Log Analytics:

Homepage Customization Options

For more individual customizations of Autopilot Manager, I added some options to customize look and feel and options to show some links for the approval and history page:

Let’s start with the additional approval and history links in the footer. If you like to have one of those just add the following to the configuration:

AppConfig:AutopilotManagerConfig:ShowHomepageApprovalLink set to true
AppConfig:AutopilotManagerConfig:ShowHomepageHistoryLink set to true

If you like to have a company logo on the right side of the homepage, add the following to the configuration and let it point to an image on a blob storage or somewhere else:

AppConfig:AutopilotManagerConfig:HomepageCompanyLogoImageUrl to an image url "https://company.com/image/comapnylogo.png"

As last customization option you are able now to change the sentence below the headline. There is a config value for the Approval Mode sentence or the Non-Approval Mode (Self-Service Mode).

If you use Approval Mode, change the sentence via:

AppConfig:AutopilotManagerConfig:HomepageHeadlineSentenceApprovalMode to e.g. "Please call the helpdesk (+49 180-12345678) for approval of device import."

This is particular helpful if you like to add a helpdesk phone number like in the example above.

If you use Self-Service Mode change the sentence via:

AppConfig:AutopilotManagerConfig:HomepageHeadlineSentenceNonApprovalMode to e.g. "Please scan the QR code to import the device."

Final remarks

If you want to use any of those enhancements you have to configure them explicitly via configuration. Nothing is silently configured in the background. To get the latest version just restart the Autopilot Manager App Service. As long as the app configuration setting WEBSITE_RUN_FROM_PACKAGE points to:

https://raw.githubusercontent.com/okieselbach/Autopilot-Manager/master/dist/Artifacts.zip

you will get the latest version including all the enhancements.

If you are looking for the solution, it is found on my GitHub site:

https://github.com/okieselbach/Autopilot-Manager

I hope these enhancements are as useful for others as they are already for some out there.

This project is a community release and based on my voluntary work, I appreciate any constructive feedback, just open a GitHub issue, use GitHub Discussions, or leave a comment here. I will support the solution as best effort and as time allows. I’ll look into bugs and help to get it up and running. On GitHub Discussions I may already have answered specific questions you have, it’s worth a visit.

Happy Autopilot operations for you all 😉