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
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
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:
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
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:
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."
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:
you will get the latest version including all the enhancements.
If you are looking for the solution, it is found on my GitHub site:
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 😉
Hi, those are great addition.
Does this tool also work for HAAD devices for Autopilot?
For HAADJ you have to register the devises in Autopilot as well, so yes you can you the Autopilot Manager to get them registered upfront. HAADJ is just different later on as you need line of sight to your domain controllers to successful complete a hybrid join Autopilot enrollment.
very cool and impressive tool
Is there something like logfiles on the App Service side ?
I would like to debug the process in the webservice if something goes wrong
yes, there is, on the App Service in Azure there is a “App Service Logs” configuration, turn on application logging and then use the log stream to view the log in real time or use the advanced tools in Azure on the App Service, that will open Kudu und from there you can open a debug console and browse the app service filesystem. Under LogFiles/Applications you should find what you are looking for, the log file which is also displayed real time under log stream.
This looks like a very useful tool to help support Autopilot.
I have configured all the components in Azure as documented. I have then installed Windows 10 21H2 as a Hyper-V image to test the solution. However, after downloading ap.exe to the Windows client, it stated it is not compatible with the version of Windows I am running. I am using ap.exe v126.96.36.199
This is typically if you forget to change the path from c:\windows\system32 to temp. Please try again by changing path upfront via „cd %tmp%“
I did follow this step, and can see that ap.exe is downloaded to c:\users\default~2\appdata\local\temp
Even when I run it from there using ap -?, it still says it is not compatible.
Can you check if the ap.exe is correctly downloaded? If it is not downloaded and the size if e.g. 0 or 1 KB you will get the same message. Are you pointing to the GitHub account as an URL? Then you should use the extra parameter for curl -L to follow redirects… like this:
curl -o ap.exe -L https://raw.githubusercontent.com/okieselbach/Autopilot-Manager-Client/master/dist/ap.exe & ap !here-your-apserver-url! -v
Your assumption was correct. For some reason, the version of ap.exe which was being downloaded to the client was getting corrupted. I implemented the static website feature of the storage account and was downloading it from there. I still haven’t worked out what the problem is with this approach.
Once I followed your suggestion and downloaded directly from GitHub, then ap.exe ran as expected on the client.
I will continue testing using this approach for the time being.
Thanks for your excellent and quick help
Sorry if i am missing something. You explain above how to enable the Re-Register mode. But how then to use it? E.g. for ‘Erase’ there was -e switch for ap.exe… How do we initiate a re-register request?
Sorry, for my late response. You don’t have to do anything. if you decide to use re-register on the service (app service) side it will just work like described.