I've been having this issue with SCEP cert not recognizing the users and going by system account, and that will cause the device show as "Not managed" in Okta.

Could anyone point me to the right direction on how to resolve this problem? I've tried working with Intune Support but not help there.

Any help would be appreciated since we've been stuck on this for a couple of months now.

Thanks,

Alex

I’m sure by now that we are all aware of the coming changes to Secure boot certificates as documented by Microsoft here. To cut a long story short, when Secure Boot was introduced by Microsoft back in 2011 or so, they secured it with some default certificates which are set to expire in June 2026.

Secure boot checks the bootloader and verifies it’s digital signature, if it’s trusted it allows it to run, otherwise it blocks it, which is a good way of blocking rootkits, bootkits and other low-level firmware attacks.

Historically speaking Secure boot became part of UEFI 2.0 specification in January 2006, but Microsoft started rolling it out in 2011 including distributing the first Secure Boot signing certificates in 2011. These were later released to mainstream computers with the release of Windows 8 in October, 2012 where Microsoft required OEMs (Original Equipment Manufacturers) to enable Secure boot and ship systems with UEFI mode enabled.

The original 2011 secure boot certificates were designed with a 15 year lifecycle, and in 2023 Microsoft introduced new 2023 certificate authorities. So here we are, all those years later, updating the bios (firmware) of modern laptops and desktops to ensure that they are capable of updating/supporting the new certificates prior to them expiring.

There are plenty of good blog posts out there today showing you how to best deal with the  Secure Boot certificate problem, but they are really focusing on supported, modern hardware, below are some examples.

• https://blog.mindcore.dk/2026/04/secure-boot-certificate-update-intune/
• https://joymalya.com/intune-secure-boot-2023-certificate-update-rollout-part-1/
• https://pureinfotech.com/windows-11-secure-boot-certificates-expiring-june-2026/
• https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235#community-4469235-_option2

What about older hardware ?

But where does that leave older hardware that does support UEFI and secure boot, and should they be turned off/disposed of ? Security experts would most likely say yes to the  latter question as they’d be wide open to rootkits/bootkits which is a painful reality when you consider the cost of new computers today thanks to the AI boom.

I’m actually writing this article on an old Lenovo T570, which technically is old, it was released in 2017, but has been updated with Windows 11 25H2, and 32GB ram. It’s not the snappiest but it works fine for what I need.

I looked at Microsoft Intune’s infamous secure boot status report and it showed me lots of red x’s for my older hardware even though I was already pushing out remediation scripts in my Intune lab to deal with the Secure boot certificates expiry mess. The following were looking sad:

• Lenovo T570
• Dell Optiplex 9020
• Microsoft Surface Pro 2

You can access this report in the Intune console by clicking on Reports, Windows Autopatch, Windows quality updates, Reports, and finally selecting the secure boot status report.

You can see the details of the report that I ran below, the green arrow shows my Lenovo T570 is not up to date for any of the 4 certificates listed in the report.

So I posted a tweet on Twitter (yeah, that’s what I call it) and got some instant feedback, which is the reason for this blog post. In the screenshot below you can see when the bios was last updated on my Lenovo (2024).

Fellow MVP, Mike Terrill responded with some great advice.

You should still be able to push the certs into the active db. However, the default db wouldn’t get the updated certs. If you did a factory restore of the bios, then the active ones would be replaced and need to be installed again.

And he included some Powershell examples from his talk at MMS.

I’m including his Powershell code below. All credit to Mike Terill and Gary Blok (I believe).

$SecureBootRegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
New-ItemProperty -path $SecureBootRegPath -name "AvailableUpdates" -PropertyType dword -Value 0x1844 -Force
Start-ScheduledTask -taskname '\Microsoft\Windows\PI\Secure-Boot-Update'
#verify
get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject
get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject

So basically I ran the code above on my Lenovo T570 (from an elevated prompt) and the results were interesting.

Below we add a reg key and trigger a scheduled task. The registry value tells Windows to deploy all available certificate updates as documented here and/or here (thanks Jon).

and reveal the certificate status after a reboot

To my joy, the following day the secure boot status report looked much much better for my Lenovo.

Success! thanks Mike!

I also got info from another Twitter user and he advised me to look here for some additional advice for patching older systems.

• https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/

I did of course try the same method on some other old computers (Microsoft Surface Pro 2, Dell Optiplex 9020) and while it had some success with some of the certs, it couldn’t update the Microsoft Corporation KEK 2K CA 2023 certificate. According to Copilot this was because the firmware on the Dell and Surface, was just too old.

Perhaps, perhaps. But then why did my Surface Book 2, which has a firmware (bios) date of wait for it, 2015 update all of the 4 certificates without any issue. That remains to be seen. I’ll update this blog post as I learn more, I definitely don’t want to ‘trash’ some old computers just because their secure boot certificates can’t get updated, worst case scenario I’ll convert them to Linux.

On My Surface Pro 2 it updates 3 out of 4, the 4th being the missing KEK certificate, just like on the Dell.

Looking in the SYSTEM event viewer, Event ID 1803 is showing every time I trigger the scheduled task from the Powershell script.

That links me to this:

Understanding Secure Boot Events 1802 and 1803 – Microsoft Support

Learn more

Finally, if you want to learn more aboute this subject (better late than never) take a look at this Patch My PC webinar, or Johan Arwidmarks free training on the subject:

• https://patchmypc.com/events/secure-boot-2026-are-you-actually-covered/
• https://academy.viamonstra.com/courses/mini-course-secure-boot-2026

Summary

Windows Autopatch on it’s own is not enough for getting these systems up-to-date with regards to the Secure boot certificate expiry. There are remediation scripts which definetly help, but they are mostly aimed at modern hardware.

Thankfully, you can update some older hardware by using the example script above, either manually or push it out via Intune/ConfigMgr after you have of course ensured that the bios version is the latest available and that Windows is up-to-date.

Thanks again to Mike, the beer is on me at MMS in October 

In the previous post I showed you what happens when a user or admin reset’s Windows after the August 2025 cumulative update (KB5063875) , basically the reset fails (rolls back).

That problem can be fixed by applying an out of band update which can be deployed manually or automatically to affected clients.

In this post I’ve once again teamed up with my buddy Paul to automate fixing this reset problem using Windows Autopatch in Microsoft Intune. It has a feature to Expedite updates. We’ve both tested this in our separate labs and are happy to share the results with you so that you too, can fix this in an automated way using Windows Autopatch.

Expediting updates

As the name sounds, this allows us to expedite (rush) updates to an Entra ID group containing our target computers, and this method can be used to get Quality Updates including Out of band updates to your devices via Windows Autopatch. There are some prerequisites, listed below:

• Devices meet the prerequisites for Windows Autopatch.
• Devices installed the update described in KB4023057 – Update for Windows 10 Update Service components (or a newer version).
• To verify that your devices meet the prerequisites for receiving an expedited update, use the Readiness test for expediting updates.

Let’s create our Expedite updates policy.

In Intune, browse to Devices, Windows Updates and select Quality Updates. In the Create + drop down, select Expedite policy.

Give the policy a suitable name and description. In the Select the quality update you would like to expedite, select the 08/26/2025 D Update for Windows 10 and later option.

If you are wondering what the D Update and B Security Updates are, here’s an explanation.

B updates

• Released on the second Tuesday of each month (commonly called Patch Tuesday).
• These are the mandatory, cumulative updates that include security fixes and sometimes reliability improvements.

D updates

• Released on the fourth week of the month (usually the preview releases).
• These are optional, non-security preview updates.
• They contain fixes and improvements that will roll into the next month’s B update.

to summarize…

• B = Security & required (Patch Tuesday)
• D = Optional preview (late month, contains fixes but no new security fixes)

So, as we already have deployed the August Cumulative update that would be the B update. We definitely need the fixes (out of band) that came after that and that would be the contained in the D updates.

Finally, if a reboot is required (and it is required), decide on how many days before it’s enforced,  so we’ll set it to 0 days.

After clicking Next, select the group(s) you want to target with these out of band updates.

Don’t worry about the fact that there’s no devices in that group yet, we’ll add them as needed later.

Click Next and the policy is created.

Finally, when you are ready to test this add one or more devices to the target Entra Id groups.

After the device gets the policy, and as long as there are no policy conflicts your end users should be notified about the pending restart.

After the restart is completed, you can verify Windows update settings, and view the history. The latest OOB (Out of band) update should be installed and as it’s also cumulative it will contain the fix to allow Windows reset to work again.

Job done!

Summary

While this ability to expedite updates in Windows Autopatch is welcome, it’s far from perfect. There are several problems, which we’ll list here:

Speed of delivery. The blurb from Microsoft claims the following, highlighted below

But in several VM’s where myself and Paul tested, the expedited update arrived in an anything but their claimed speed. In reality, the update took several hours to approx one day and numerous syncs on the clients and in the Intune console before we saw the popup. On some vm’s we are still waiting for the magic to happen even though all the prerequisites are in place.

Update: We got a reply from Peter Braune on Twitter, who stated the following, it may help you if you are going down this path.

We actually had to create a policy via settings catalog “Automatically receive optional updates”, to get this update rolling out to clients. Once the policy was in place the update was installed immediately. Downside, preview updates being rolled out automatically too.

Lack of ability to target a specific hotfix.  You you can only choose between B or D updates and hope that they include the fix you need. What we really wanted was to be able to specficially install KB5066189, but that’s not possible currently with this method via the console.

Lack luster reporting. If you want to see what’s happening with your expedited update in real time then you are out of luck. Of the several machines we targeted the reporting suggested nothing was wrong, which in a way was true because nothing was happening. And that’s the problem, how can you quickly determine whether your hotfix is applied or not to these target devices ?

Policy conflicts. After enabling Expedited updates, you might end up troubleshooting policy conflicts on your target devices if your tenant has had the following installed. Windows Autopatch – Office Update Configuration – Expedited (Expedited updates for CVE-2023-23397).

Hopefully Microsoft is listening and will improve this service going forward.

That’s it from us, see you in the next one.

Occasionally you want to inform users about something, such as the need to update or install software, and the easiest way to do that is with some sort of a popup notification. The ability to do that in Microsoft Intune is not currently available in the product although it is a Uservoice item in progress. In the meantime however, if you need to send a notification to users of Windows devices in Microsoft Intune, it's possible using PowerShell and here's how to do it.

The idea here is that you can customize the PowerShell script to deliver the message you want (and if necessary take possible actions, however you need to add your custom code to the script and it must not exceed 200KB). the screenshots below are taken on a Windows 10 version 1709 device enrolled into Intune, the device is logged on as a user with normal permissions (not an Administrator) and this was configured with Windows AutoPilot.

Note: The Intune management extension which is used to run the PowerShell script has the following prerequisites:

• Devices must be joined to Azure AD
• Devices must run Windows 10, version 1607 or later

Step 1. Download the script

Download the DisplayMessageInIntune.ps1 script.

DisplayMessageInIntune.zip

Step 2. Edit the script in ISE

Launch PowerShell ISE and open the extracted downloaded script. Scroll down to the following values. The values are currently set as PowerShell Parameters with the hope that the current functionality in Microsoft Intune will support Params with PowerShell scripts in the future (I've requested this ability as a DCR to Microsoft directly). If this ability does come to Intune then I will blog an update to this post explaining how to make it dynamic.

When you've changed the message title and message body, you might also want to change the Type and Option available to the user, below are the values you can configure.

$Option can be any of the following values

"OK"
"OKCancel"
"AbortRetryIgnore"
"YesNoCancel"
"YesNo"
"RetryCancel"

$Type can be any of the following values

"Asterisk"
"Error"
"Exclamation"
"Hand"
"Information"
"None"
"Question"
"Stop"
"Warning "

Finally after line 69 you can add any additional code you want, for example to check what key was pressed etc.

Step 3. Upload the script to Microsoft Intune

In the Intune service in Azure select Device Configuration and click on PowerShell Scripts.

In PowerShell scripts, click on Add.

Enter the following values:

Name: "Display a message in Intune"

Description: "Using PowerShell to messages in Intune"

Script location: DisplayMessageInIntune.ps1

Next click on Settings, Configure to see the options available, 

Change the first option so that the script runs with the same permissions as the logged on user.

Click OK when done and then click on Create to create the PowerShell script in Intune.

Next click on Assignments to assign the PowerShell script to a Group of Users.

To do that, click on Select Groups and then select a Group of Users that you'd like to assign this to.

Next click on Save to save this group.

Step 4. Review what happens on a Windows device

On a Windows device, logon using the credentials of a user that is in the selected group that you assigned the PowerShell script to.

Tip: You can restart the Microsoft Intune Management Extension service (as a user account with Administrator permissions) rather than wait one hour for that extension service to run the PowerShell script.

Note: Your users don't need to do the service restart, this is just so you get instant gratification and can review the end-result.

After the policy is received the message popup is displayed on top of all windows.

result !

Troubleshooting

You can review 2 logs files, one is the log file for Microsoft Intune Management Extension:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

and the other is generated by the PowerShell script itself:

C:\Windows\Temp\DisplayMessageInIntune.log

Note: If you want to display the message to a user in SYSTEM context then download serviceUI.exe from the MDT toolkit and launch powershell with that exe, like so... and create a Win32 App instead of using a PowerShell script option.

ServiceUI.exe -process:explorer.exe %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File DisplayMessageInIntune.ps1

Recommended reading

• https://docs.microsoft.com/en-us/intune/intune-management-extension
• https://oliverkieselbach.com/2017/11/29/deep-dive-microsoft-intune-management-extension-powershell-scripts/
• https://www.petervanderwoude.nl/post/combining-the-powers-of-the-intune-management-extension-and-chocolatey/

Note: This method is not officially supported by Microsoft. That said, this speeds up compliance and more importantly increases security as the device is already encrypted (part 1) before the user logs on (part 2). BitLocker recovery key changes after the user has completed enrolment are handled automatically (part 3).

Note: I've updated the scripts 2023/12/23 to use new logging path and detection files instead of registry keys.

Windows Autopilot preprovisioning (WhiteGlove) is the ability to preprovision content and policies to devices while they are installed in the factory.

We had a challenge to speed up the overall compliance of Windows Autopilot devices and the obvious solution was to stage as much content as we could during preprovisioning (WhiteGlove) but to also enable BitLocker encryption during that process, the only problem is that Microsoft don't officially support BitLocker encryption during the WhiteGlove scenario as the recovery key information is only uploaded after a user logs in. In our initial testing, Bitlocker disk encryption wouldn't even start until the user logged in.

That is not so much of a problem for a small amount of content on the hard disc but what if you have hundreds of Gigabytes of data to encrypt which could potentially take hours to encrypt after the user has logged on. As BitLocker encryption is a common Compliance policy setting, this needed to be addressed.

The challenge was to do the heavy lifting (pre-provisioning and encryption) during the WhiteGlove process and to only upload the key to Intune once the user actually enrolled the device. That need brought about this solution which is in 3 parts. The first part covers device encryption during provisioning at the factory. The second part uploads the recovery key to Intune after the user has signed in and completed WHFB setup and the final part moves those successfully encrypted devices to a WhiteGlove_Completed azure ad group targeted with BitLocker policy to take care of rotating recovery key info etc.

All parts are listed below:

• Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 1 <- you are here
• Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 2
• Encrypting devices during Windows Autopilot provisioning (WhiteGlove) - Part 3

Step 1. Create an Azure AD group

In Microsoft Intune, create a dynamic device group called WhiteGlove Computers with a query for a WhiteGlove Group Tag. This group will dynamically fill with computers that have the correct Group Tag assigned to them.

Below is the query used:

(device.devicePhysicalIds -any (_ -eq "[OrderID]:WhiteGlove"))

Step 2. Exclude BitLocker configuration profiles from this group

Locate any existing BitLocker configuration profiles in your tenant and exclude then from this group otherwise they will cause the solution to fail.

Step 3. Allow Pre-provisioned deployment

Next, locate your Windows Autopilot Deployment Profiles and enable the WhiteGlove ability by turning on the Allow Pre-provisioned deployment setting. Deploy the profile to the group created in Step 1. This profile must also enable a User Account Type of Local Admin. Don't panic, we'll be removing this local admin ability later on in the solution before the end user can cause trouble.

In the example below you can see a Windows Autopilot deployment profile called Intune: Local admin

Step 4. Exclude standard user deployment profiles

If you have any additional Deployment Profiles for Standard Users, make sure to exclude this group from those profiles otherwise they won't get the right settings needed for the second part of this solution.

Step 5. Configure a WhiteGlove ESP

Configure at least one Enrollment Status Page (ESP) targeted to your WhiteGlove Computers Azure AD group

Step 6. Add a Win32 App

Next, using the latest version of the IntuneWinappUtil.exe app, create a Win32 app called Enable Bitlocker during Windows Autopilot WhiteGlove. This app will enable Bitlocker during WhiteGlove at the factory. The app is in the attached 7 ZIP file, use 7-Zip to uncompress.

Note: Only logged on members of windows-noob.com can download this file.

WhiteGlove - Enable BitLocker During WhiteGlove preprovisioning.7z

Configure the app settings as follows:

Name: Enable Bitlocker during Windows Autopilot WhiteGlove
Program Install command: install.win.ap.enable.bitlocker.during.whiteglove.cmd
Program uninstall command: install.win.ap.enable.bitlocker.during.whiteglove.cmd
Install behavior: System
Device restart behavior: No specific action
Return codes:
0 Success
1707 Success
3010 Soft reboot
1641 Hard reboot
1618 Retry

Requirements:

Operating system architecture: x64
Minimum operating system Windows 10 1903

Detection rules:

Rules format Manually configure detection rules

Detection rules File

Path: C:\ProgramData\windowsnoob\WhiteGlove

File or folder: EncryptedDuringWhiteGlove.txt

Detection method: File or folder exists

Next, assign the app as required to your WhiteGlove Computers AAD group

Step 7. Add the Group tag to a test device

In this step either import a new CSV of a Windows Autopilot device (or use an existing device) to test this on, and then add the WhiteGlove GroupTag to that Windows Autopilot device.

Step 8. Provision the device

The staging of content and policies to the device normally will take place at the factory (OEM) or IT Admin staging area. At the first screen of OOBE (shown below)

The technician needs to press the Windows key 5 times to start provisioning mode.

Next, Select Windows Autopilot provisioning from the list and click Continue.

If everything went well it will download the correct Windows Autopilot deployment profile and display it (Intune: Local admin)

Click Provision to start the staging process.

Once the ESP installs the Win32 app, it will begin encrypting the drive. You can reveal this with the following command:

manage-bde -status

The next screenshots are from real hardware.

and once all apps and policies are installed completely and successfully the drive is fully encrypted and the protectors are stored in the TPM along with a BEK key stored on the SYSTEM partition temporarily.

At this point the technician can click on Reseal to seal the device for user enrollment (Part 2).

That 's it for this part, please join me in Part 2 where we'll add the next Win32 app which will do a bunch of actions including:

• create a scheduled task to run a script when WHFB setup is completed
• remove BEK protector
• add numerical password protector
• upload the key to Intune
• restart the computer with a shutdown message to the end user

Troubleshooting

The Win32 app used in this part logs to C:\ProgramData\windowsnoob\WhiteGlove\win.ap.enable.bitlocker.during.whiteglove.log

The contents of which are shown below from a working WhiteGlove deployment, please use this as a reference to compare your log file.

02/27/2023 04:33:46 Starting script: 'win.ap.enable.bitlocker.during.whiteglove' version: '0.11'...
02/27/2023 04:33:46 checking the current bitlocker encryption status
02/27/2023 04:33:47 Current Bitlocker Status: FullyDecrypted, None
02/27/2023 04:33:47 Fully decrypted, no need to decrypt
02/27/2023 04:33:47 starting TPM section
02/27/2023 04:33:48 TPM chip is currently owned, will not attempt to take ownership
02/27/2023 04:33:48 attempting to assign drive letter to the SYSTEM partition
02/27/2023 04:33:51 starting BitLocker Encryption section
02/27/2023 04:33:51 adding reg keys for BitLocker encryption settings
02/27/2023 04:33:51 succeeded adding the reg key
02/27/2023 04:33:51 adding AES-XTS256 reg key for BitLocker encryption settings
02/27/2023 04:33:51 succeeded adding the reg key
02/27/2023 04:33:51 Enabling BitLocker, TPM Protector and Recovery Password Protector
02/27/2023 04:34:10 enabling bitlocker worked YAY!!!!
02/27/2023 04:34:16 Current BL Status: C:, EncryptionInProgress, XtsAes256,Tpm ExternalKey
02/27/2023 04:34:16 Percentage Encrypted: '96'%.
02/27/2023 04:34:16 Percentage Encrypted: '96'%.
02/27/2023 04:34:16 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:17 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:18 Percentage Encrypted: '96'%.
02/27/2023 04:34:19 Percentage Encrypted: '96'%.
02/27/2023 04:34:19 Percentage Encrypted: '96'%.
02/27/2023 04:34:19 Percentage Encrypted: '97'%.
02/27/2023 04:34:19 Percentage Encrypted: '97'%.
02/27/2023 04:34:19 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:20 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:21 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:22 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:23 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:24 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:25 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:26 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:27 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:28 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:29 Percentage Encrypted: '97'%.
02/27/2023 04:34:30 Percentage Encrypted: '97'%.
02/27/2023 04:34:30 Percentage Encrypted: '97'%.
02/27/2023 04:34:30 Percentage Encrypted: '98'%.
02/27/2023 04:34:30 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:31 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:32 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:33 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:34 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:35 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:36 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:37 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:38 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:39 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:40 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:41 Percentage Encrypted: '98'%.
02/27/2023 04:34:42 Percentage Encrypted: '98'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:42 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:43 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:44 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:45 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:46 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:47 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:48 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:49 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:50 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:51 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:52 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:53 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:54 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:55 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:56 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:57 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:58 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:34:59 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:00 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:01 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:02 Percentage Encrypted: '99'%.
02/27/2023 04:35:03 Percentage Encrypted: '99'%.
02/27/2023 04:35:03 Percentage Encrypted: '99'%.
02/27/2023 04:35:03 Percentage Encrypted: '100'%.
02/27/2023 04:35:03 Current BL Status: C:, FullyEncrypted, XtsAes256,Tpm ExternalKey
02/27/2023 04:35:03 removing drive letter assigned to the SYSTEM partition now...
02/27/2023 04:35:04 The drive is fully encrypted now :-), we are exiting the script !

Once encryption during WhiteGlove is completed a reg key is created

and a file is created called EncryptedDuringWhiteGlove.txt in C:\ProgramData\windowsnoob\WhiteGlove

This file is used as the detection rule for this Win32 app meaning that encryption must be completed by the app to be detected.

Note: This solution was originally tested and released for use on Windows 10 version 22H2, but it works just fine on Windows 11 version 22H2 or later. Do make sure that Automatic Bitlocker Encryption is disabled by the OEM (HP, Dell, Lenovo, etc) or disable it yourself using the following method:
 

1. DISM mount your WIM image.
2. reg load HKLM\TEMP C:\mountpath\Windows\System32\config\SYSTEM
3. reg add HKLM\TEMP\CurrentControlSet\Control\BitLocker /v PreventDeviceEncryption /t REG_DWORD /d 1 /f
4. reg unload HKLM\TEMP
5. DISM commit your changes.

Recommended reading

• Windows Autopilot for pre-provisioned deployment (Public preview) - https://learn.microsoft.com/en-us/mem/autopilot/pre-provision
• 3 things to know before deploying bitlocker with Intune - https://brookspeppin.com/2022/07/06/3-things-to-know-before-deploying-bitlocker-with-intune/
• Disabling Windows 11 automatic encryption

In part 1 you learned how to use Azure functions and a http trigger to add a device to an Azure Ad security group. In this part you'll see how it all fits together on the client side after Autopilot is complete.

Step 1. Get the scripts

Download the client side scripts here. Please read the note before trying.

Note: To download the files here, please make sure you are logged on to this site otherwise you'll get an error.

• Download the following zip file here: temp.zip

Step 2. Extract the files

Extract the files to C:\temp

Step 3. Edit AddDeviceToAzureAdGroup.ps1

Using Windows PowerShell ISE or notepad, open AddDeviceToAzureAdGroup.ps1, you need to edit the following two lines.

Replace $company with your own company name, and for $URL you will need to login to your Azure resource group created in part 1 and copy the HttpTrigger1 url by clicking on Get Function URL and copying the url as shown below.

Note: If you don't do this properly then it won't work !

Paste in the URL you copied from your HttpTrigger and append &deviceID= on the end as shown here.

Step 4. Encode the scripts

Open the EncodeScripts.ps1 script and run it. It will generate new encoded copies of the two scripts that will become embedded in the

Step 5. Edit AddDeviceToAzureAdGroup_CreateScheduledTask.ps1

Open AddDeviceToAzureAdGroup_CreateScheduledTask.ps1 and scroll down to the $Base64_1 line.

In notepad, open C:\temp\encoded1.txt, press CTRL+A and CTRL+C to copy everything in that file. Back in the PowerShell script, paste the copied content into the $Base64_1 variable in between the "" as shown below.

repeat this exercise for the $Base64_2 variable but use the C:\temp\encoded2.txt file contents for that variable.

Note: You have to repeat this process any time you edit either of the following two scripts.

• AddDeviceToAzureAdGroup.ps1
• AddDeviceToAzureAdGroup.vbs

After my edits it looks like this, your encoded variables will most likely have different values.

Save the file.

Step 6. Add the PowerShell script to Intune

Create a new deployment to your Autopilot Users group using the  AddDeviceToAzureAdGroup_CreateScheduledTask.ps1 PowerShell script.

use the following settings

Deploy it to your Autopilot Users group

Step 7. Verify the end result

Launch Autopilot

After it's done, you'll login to the desktop. If you check scheduled tasks you should see this task is scheduled to run approx 15 minutes after you've logged on, if you see a different behavior then please modify the setting on line 79 of  the AddDeviceToAzureAdGroup_CreateScheduledTask.ps1 script.

The task that created that scheduled task extracted files to the users temp folder.

As the task hasn't run yet we don't have a log file for adding the device to the azure ad group yet. The scheduled task log looks something like this however.

After the scheduled task has run you'll have a new log file to look at called AddDeviceToAzureAdGroup.log available in the logged on users temp folder.

The log file is very detailed and will show the actions of getting the deviceID, detecting the Group Name and the success of adding the device to the Azure Ad group. Below you can see that it has confirmed the addition of the device to the group.

At which point you can check the group in the MEM portal. And there's your device ?

The script also creates registry keys so that you can see when it added the device, to which group and using which deviceID.

Job done !

I hope you found this useful, if you do, please give me feedback.

cheers

niall

I've come across various problems during Windows Autopilot causing OOBE to fail that could be solved if only we could decide the order of when things were installed, and to resolve this in a nice way we wanted to dynamically populate an Azure AD group that could be targeted with a device configuration profile. That would mean that we could target sensitive policies to devices after enrollment instead of during enrollment allowing for a smoother, less error prone experience.

Being able to apply a profile after Autopilot is finished requires knowing when Autopilot is actually complete, and I touched upon that subject in a previous blog post here. To expand upon that, we can run a scheduled task on login which runs a PowerShell script which in turn, only delivers the payload if certain things are in place such as.

• C:\ProgramData\Microsoft\IntuneManagementExtension  was created within the last X hours
• The logged on user is not defaultuser0

We could do this using a PowerShell script which runs as a scheduled task after login but that would require storing sensitive credentials on the client.

This blog post will show you the necessary steps taken to get to a stage where you can add devices to an Azure AD group using Azure Functions and Graph, and that is interesting because in conjunction with an app registration allows you to embed certificates or secrets within the function and thereby bypass the need for storing credentials in your PowerShell script which runs on the client.

Note: In this blog, the app uses http triggers that use certificate secrets, this is fine in a lab, but in production you should use Azure Key Vault instead as it's more secure. If you'd like to understand how to set that up please read my blog post about Azure Key Vault here.

There are other ways of doing this, but this is kind of neat. You need to do the following steps.

• Create a resource group
• Create an app registration
• Create a client secret
• Create a function app
• Add a HTTP trigger
• Get the application ID
• Create an azure ad group
• Add missing details
• Configure API permissions
• Test adding a client

So now you have an idea of what this blog post is about, let's get started.

Note: I've released an updated version of this concept which includes checking for device compliance here.

Step 1. Create a resource group

In Azure Active Directory, create an Azure Resource Group. To do that click on Create a Resource in https://portal.azure.com.  In the page that appears, search for Resource Group. Select it and click on Create. Next, give it a useful name like Graph_Functions, and select the region applicable to you.

And click on Review + create and after being presented with the summary, click Create.

Step 2. Create an app registration

In Azure Active Directory, create an create an APP Registration called graph_functions by clicking on App registrations in the left pane and clicking on + New registration.

fill in the user-facing display name and then click on Register.

The app registration is created.

Step 3. Create a client secret

In the Graph_Function app registration you just created, click on Certificates & Secrets, choose the option to create a + New client secret

Give it a name like graph_function_secret

Click Add

After adding the client secret make sure to copy the secret and keep it safe.

copy the secret value and id, you will need them later.

Step 4. Create a function app

Next, select your previously created resource group called Graph_Functions and create a function app in the graph_functions resource group by clicking on +Add

Search for Function App and click Create. A wizard will appear, fill in your choices and select PowerShell core and your region.

Create a new storage group or let the wizard create it's own, then click Review + Create. If it generates an error click on the error details, most likely the storage group name you tried to create is already taken. If so, pick another name.

Finally, click on Create to create the function app.

Step 5. add a HTTP trigger

Select the function app created above and click on functions in the left pane. In the ribbon click on + Add.

Select HTTP trigger and click on Add.

Select Code + test and paste in the code below then save the results
 

# use this code in a http trigger as part of a function app
# for more details see https://www.windows-noob.com/forums/topic/21814-adding-devices-to-an-azure-ad-group-after-windows-autopilot-is-complete-part-1/
# Niall Brady, windows-noob.com 2020/12/18 v 0.3


using namespace System.Net
# Input bindings are passed in via param block.
param($Request, $TriggerMetadata)
# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."
# Interact with query parameters or the body of the request.

$deviceId = $Request.Query.deviceId

if (-not $deviceId) { 
                    $deviceId = $Request.Body.deviceId
                }
# define the following variables
$ApplicationID =    "" # this is the id of the app you created in app registrations
$TenantDomainName = "" # your tenant name, eg: windowsnoob.com
$AccessSecret =     "" # this is the secret of the app you create in app registrations
$GroupID = ""          # this is the ObjectID of the Azure AD group that we want to add devices to


$Body = @{
Grant_Type = "client_credentials"
Scope = "https://graph.microsoft.com/.default"
client_Id = $ApplicationID
Client_Secret = $AccessSecret
}
# make initial connection to Graph
$ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantDomainName/oauth2/v2.0/token" -Method POST -Body $Body
#get the token
$token = $ConnectGraph.access_token
# to improve logging...
$a = Get-Date
$body = " `n"
$body = $body + "$a Starting Azure function...`n"
$body = $body + "$a Connected to tenant: $TenantDomainName.`n"
# now do things...

if ($deviceId) {
    $body = $body + "$a You supplied deviceId: '$deviceId'" + ".`n"
    # deviceID should be supplied to the function via the function url, 
    # if you want to hard code it for testing un rem next line and supply the correct deviceId
        #$deviceID = "3a4f4d9d-c648-4ca2-966f-6c6c10acff35"
        #$InputDevice = "MININT-U7CQUG7"
        #$Devices = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/devices?`$filter=startswith(displayName,'$InputDevice')" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{    
    $Group = Invoke-RestMethod -Method Get        -uri "https://graph.microsoft.com/v1.0/groups?`$filter=Id eq '$GroupId'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value
    $GroupName = $Group.displayName
    $body = $body +"$a Group.displayName: '$GroupName'" + ".`n"
    $GroupMembers = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value
    $AddDevice = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/devices?`$filter=deviceId eq '$deviceId'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ 
   
   if ($GroupMembers.ID -contains $_.id) {
       Write-Host -ForegroundColor Yellow "$($_.DisplayName) ($($_.ID)) is in the group" 
        $body = $body + "$a $($_.DisplayName) ($($_.ID)) is already in the '$GroupName' group, nothing to do.`n"
    } else {
        Write-Host -ForegroundColor Green "Adding $($_.DisplayName) ($($_.ID)) to the group"
        $body = $body +  "$a Adding $($_.DisplayName) ($($_.ID)) to the group with ObjectID $GroupID.`n"
        $BodyContent = @{
            "@odata.id"="https://graph.microsoft.com/v1.0/devices/$($_.id)"
        } | ConvertTo-Json
        Invoke-RestMethod -Method POST -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members/`$ref" -Headers @{Authorization = "Bearer $token"; 'Content-Type' = 'application/json'} -Body $BodyContent
    }
}
$body = $body +  "$a Exiting Azure function."
}

# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
 StatusCode = [HttpStatusCode]::OK
 Body = $body
})

Step 6. Get the application ID

Go back to app registrations, select the app called graph_functions and copy this field.

• Application (client) ID:

copy the Application (client) ID somewhere.

Step 7. Create an azure ad group

In Microsoft Endpoint Manager create an azure ad group called Autopilot Completed

Take note and copy the Object ID of this Azure Ad group.

Step 8. Add missing details

Now that you have the values you need (remember you copied the access secret earlier ?), go back into your function app and edit the code, fill in the values below for the following variables

• $ApplicationID
• $TenantDomainName
• $AccessSecret
• $GroupID

like I've done here... but obviously use your own values.

Save the code after making your edits.

Step 9. configure API permissions

Next you need to configure API Permissions for the app registration, don't forget to 'grant admin consent after doing so', please select the following permissions from those available.

Click + Add a permission, click Microsoft Graph, select Application permissions

• Device.Read.All                     Application                Read all devices                        Yes                Granted for windowsnoob.com
• Group.ReadWrite.All             Application                Read and write all groups        Yes                Granted for windowsnoob.com

In your lab environment it's ok to Grant admin consent, in Production, think more carefully about how you want to approach it.

and once done they'll look like so.

Step 10. Test adding a client

Now you are ready to test this. On a client, open a cmd prompt and type dsregcmd /status

look for the deviceID value highlighted below and copy it.

Copy that value and on your http trigger function, use the following in your test window. Replace the deviceID listed below with one from your device.

{
"deviceID": "f6331344-f625-4259-87e7-73b62f6dbc4a"
}

Click Run and watch your function do it's thing ?

If you followed my guide exactly you'll see something like this.

And after a quick look in the members of your Azure Ad group, guess what, your client computer is present !

Awesome ! job done

Useful links

• Graph explorer - https://developer.microsoft.com/en-us/graph/graph-explorer#
• Powershell modules in Azure functions - https://tech.nicolonsky.ch/azure-functions-powershell-modules/
• Create first function in visual studio code - https://docs.microsoft.com/en-us/azure/azure-functions/create-first-function-vs-code-powershell
• Add devices to an Azure ad group using Graph- https://euc365.com/add-devices-to-an-azure-ad-group-using-the-microsoft-graph-api/
• Using Graph in an Azure  function - https://techcommunity.microsoft.com/t5/windows-dev-appconsult/using-microsoft-graph-in-an-azure-function/ba-p/317434

That's it for this part, please join me in Part 2 where we'll look into scripting things in an automated way on the client.

cheers

niall

When users complete Windows Autopilot Out of Box Experience (OOBE), they can be asked to confirm Country and Keyboard settings, based on what is configured in the following Windows Autopilot Deployment Profile settings. Below is the Windows Autopilot deployment profile settings used for this blog post, notice how the User account type is set to Standard. Notice also that the Privacy settings setting is set to Hide.

Your users will most likely be used to seeing the region related screens during OOBE, for example:

However if you disable Privacy Settings in the Windows Autopilot Deployment profile, even though you might allow users to select Country and Keyboard settings, Windows Autopilot still sets the Time Zone to Pacific Standard Time.

You can confirm this behavior by pressing left shift+F10 and typing PowerShell then Get-TimeZone.

This Time Zone will apply regardless of what country the user selects.

Even if your users are tech-savvy enough to find out where in Windows Settings they need to change these region based settings, if they are a standard user (which they should be in today's security conscious world), changing the timezone may leave them with incorrect time and incorrect regional format settings in the operating system.

To fix this you could use Geo location and Azure services as per Nickolaj's post here, provided of course that:

• Your company allows Geo location
• Your company is not using any proxies or VPN's that mask the users actual location.

This solution is not affected by either of these things, doesn't need local administrative permissions and does not require enabling privacy settings. This solution prompts the end user to confirm (or change) the detected settings, and then uses some back end magic to set everything in place including triggering a time sync.

This method works even for standard (non administrator) users.

Requirements

The method requires that you use the English (En-US) version of Windows 10 as delivered from your OEM. If any other language is applied from the factory then it might cause some of the logic to fail. If you do go down that route, then you'll need to prepare language specific versions of the zonemapping.csv and other files as necessary. So let's get started. You can always install language packs later.

Step 1. Get the scripts

Note: You can only download these files when logged on as a member of https://www.windows-noob.com

Note: Intune has a hard block of 200,000 bytes per PowerShell script. To get around this limit, I've removed most of the original comments from the Powershell scripts. The resulting script can be uploaded to Intune as it's less than the 200,000 bytes limit even with all the files encoded. If you'd like a copy of the version with comments included to help with troubleshooting, scroll to the very bottom of this blog post.

Download the condensed ZIP: win.ap.CreateScheduledTask.SetTimeZone_CONDENSED_VERSION.zip

Extract the condensed ZIP file to C:\Scripts\SetTimeZone

Step 2. Get ServiceUI.exe from MDT

You'll need the ServiceUI.exe executable file to display user interfaces (UI) to end users when operating in SYSTEM context. To get the file, download and install MDT somewhere and navigate to C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\x64. To download MDT click here.

Copy the ServiceUI.exe file to your extracted SetTimeZone\Encode folder so it looks like this.

Step 3. Modify the scripts

Open SetTimeZone-GUI.ps1 and SyncTime.ps1 in PowerShell ISE and make changes as appropriate. Once done editing those scripts to suit your needs save the changes. Then run the Encode script to generate the encoded txt files which you will paste into the variables highlighted below.

you can do that by locating the appropriate TXT file for each encoded file, for example for ServiceUI.exe it'll be the ServiceUI.txt file, open it in notepad,

copy the contents of that file using CTRL+A and CTRL+C

and paste the results using CTRL+V into the associated variable, once you've done all 5 encoded files it'll look something like this

If you are happy with all the changes in win.ap.CreateScheduledTask.SetTimeZone.ps1, save the changes.

Step 4. Deploy it from Intune

In Microsoft Endpoint Manager, select devices, scripts and add a new PowerShell script. Fill in some details like so.

Deploy it to your Windows Autopilot users (start with a small group of users to test...), note that if you deploy this script to users that have already enrolled, the script checks if the enrollment was within the last 72 hours and if it was it will run, but if the enrollment was more than 72 hours ago, it'll do nothing.

Step 5. Test it out

First off, let's see what the expected outcome is. After Windows Autopilot enrollment is complete, and the user has logged on to the desktop, shortly after they login they will see a popup window asking them to Confirm or Change their Time Zone and Region settings. Below is an example of that.

The user can confirm the settings by simply clicking Confirm, or if they want to change any of the options they can do so by clicking the relevant drop down menu.

In this example the user changed the Regional format to English (Sweden), from English (United States) and after clicking Change the settings are applied.

The following will occur when Confirm or Change is clicked.

The keyboard layout is set (1), the regional format is in the chosen format (2) and the time will change to the selected timezone within one minute (3). The time sync takes place via an event generated in event viewer by the SetTimeZone-Gui script.

Windows 11 support

Does it work with Windows 11 ? absolutely !

see here:

Job done !

Troubleshooting

Note: If you are testing this on a hyper-v virtual machine, please disable enhanced mode.

There are three log files generated by this solution

• win.ap.CreateScheduledTask.SetTimeZone.log located in C:\Windows\Temp
• win.ap.SetTimeZone-GUI.log located in C:\Users\<username>\appdata\local\Temp
• win.ap.synctime.log located in C:\Windows\Temp

Here you can see it changing the time zone as revealed in the log file time change...

the following scheduled tasks are created.

The SetTimeZone scheduled task will run within a few minutes of the user logging in, it runs the following script.

which in turn launches Powershell and our SetTimeZone-Gui.ps1 script

%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File %temp%\SetTimeZone-Gui.ps1

That will launch the UI shown previously, allowing the end user to confirm or change the detected settings. Once the user confirms or changes the timezone settings an event ID will be generated which will in turn launch the Synctime Based on EventId task.

Magic ?

If the user ignores the popup and restarts the computer, it will appear again after logging on every time they logon for 7 days. You can change that behavior via the scripts settings.Ok that's it for this blog post, see you next time,

cheers

niall

Related: https://smsagent.blog/2022/05/13/beware-of-changing-regional-format-after-intune-enrolment/

Footnote: Here is the commented version of ZIP. This version of the scripts cannot be uploaded to Intune as it's too big, use for troubleshooting purposes only.win.ap.CreateScheduledTask.SetTimeZone_COMMENTED_VERSION.zip

I received a brand new HP Laptop (HP EliteBook 830 G6) to verify our current Autopilot setup, and I went through OOBE. All seemed well and I was curious about the version of Windows shipped so I ran WinVer. The following screen appeared.

Notice how the registered owner and registered organization fields are automatically populated with HP's default settings, this was a Windows Autopilot enrolled HP delivered with HP's business clean image (no bloatware). The following registry key reveals where those values are set.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion

if the following REG_SZ keys are missing:

• RegisteredOrganization
• RegisteredOwner

You'd see the following instead.

So now that I knew why I was seeing those values I decided to fix it.

Step 1 - Add a PowerShell script to Endpoint Manager

In Microsoft Endpoint Manager select Devices and then select Scripts as shown here (alternatively, choose Devices, Windows, PowerShell Scripts...)

Click on Add and select Windows 10 as the operating system.

Fill in the Name of the script and a description, note that the Name does not have to match the actual name of the script.

Note: you must be a logged in member of windows-noob.com to download this script.

Next, point it to the PowerShell script which you can download here and select to Run this script using the logged on credentials.

Next select the Groups you want to assign it to, I selected my Windows 10 Autopilot DEVICES group

Step 2. Test an Autopilot device

Start OOBE (out of box experience) on an Autopilot enrolled device.

move through the screens and you'll have to enter your credentials at the welcome to your Tenant name screen

after signing in successfully the Enrollment Status Page will appear (if configured to do so)

Step 3. Verify changes

If everything went according to plan, after a while Windows Autopilot will be completed and you'll be logged on to the desktop, you can now verify the changes by typing WinVer.

Troubleshooting

If things didn't go as planned take a look at the IntuneManagementExtension.log with CMTrace. It's found in the C:\ProgramData\Microsoft\IntuneManagementExtention\Logs folder

and confirm that the script ran successfully and that it ran in User context (user was a local admin in this case). If you need to run it as SYSTEM then change the variable for RegisteredOwner in the script to something else.

job done !

Downloads

Here's the PowerShell script used above

ConfigureRegistered_User_Org.ps1

In part 1 I showed you how to prepare Azure for the PC Buyback app, in part 2 you added the Win32 app, deployed it and saw how it behaved on a Windows Autopilot registered device. In this part we'll add some additional functionality namely logging to Azure tables so that we have a record of when the PC went through the process of PC Buyback. To set this up we'll add another 2 http triggers, and then configure their integration.

Note: If you are new to this it might seem overwhelming, don't panic, take your time and follow my guide, if you do it correctly you'll get a successful result.

This mini series is broken down into the following parts:

• PC Buyback for Windows Autopilot devices - part 1
• PC Buyback for Windows Autopilot devices - part 2
• PC Buyback for Windows Autopilot devices - part 3 <--- You are here

Step 1. Create the AddDataToAzure http trigger

In the previously created PCBuyback Function app, create a new http trigger called AddDataToAzure

In the newly created Http trigger, click on Code + Test and paste in the following code to overwrite the existing code...

#######################################################################################################################################
# use this code in a http trigger as part of a function app
# Niall Brady, 2024/05/08
# for more info see https://www.windows-noob.com/forums/topic/23414-pc-buyback-for-windows-autopilot-devices-part-3
# https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-powershell?tabs=portal
#######################################################################################################################################


using namespace System.Net;
using namespace System;
#using namespace System.DateTime;

# Input bindings are passed in via param block.
param($Request, $TriggerMetadata, $inputTable)

$Tenant = "windowsnoob.com"
$triggerName = "ADD data TO Azure Table"
# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."

# Interact with query parameters or the body of the request.
$ComputerName = $Request.Query.ComputerName
if (-not $ComputerName) {
    $ComputerName = $Request.Body.ComputerName
}
$UserName = $Request.Query.UserName
if (-not $UserName) {
    $UserName = $Request.Body.UserName
}
$Model = $Request.Query.Model
if (-not $Model) {
    $Model = $Request.Body.Model
}
$Manufacturer = $Request.Query.Manufacturer
if (-not $Manufacturer) {
    $Manufacturer = $Request.Body.Manufacturer
}
$Serial = $Request.Query.Serial
if (-not $Serial) {
    $Serial = $Request.Body.Serial
}
#$DateReset = $Request.Query.DateReset
#if (-not $DateReset) {
#    $DateReset = $Request.Body.DateReset
#}
$Status = $Request.Query.Status
if (-not $Status) {
    $Status = $Request.Body.Status
}
$Reason = $Request.Query.Reason
if (-not $Reason) {
    $Reason = $Request.Body.Reason
}
$ResetType = $Request.Query.ResetType
if (-not $ResetType) {
    $ResetType = $Request.Body.ResetType
}

    $a = Get-Date
    $body = $body + "$a ------------------------------------`n"
    $a = Get-Date
    $body = $body + "$a Starting the following trigger:  '$triggerName'.`n"
    $a = Get-Date
    $body = $body + "$a Connected to tenant: '$Tenant'.`n"

if ($ComputerName) {
    $a = Get-Date
    $body = $body + "$a Adding this computer to Azure Tables: '$ComputerName'.`n"
#}

#fix the date
#$NewDate = $(get-date($DateReset) -UFormat '+%Y-%m-%dT%H:%M:%S.000Z')
#$DateReset = $NewDate

$a = Get-Date
$body = $body + "$a Get next row key....`n"
#$nextRowKey=$([int]$(($inputTable.RowKey|measure -Maximum).Maximum)+1)
$nextRowKey=Get-Random
$a = Get-Date
$body = $body + "$a nextRowKey = '$nextRowKey'.`n" # this will be the row key that we insert in this operation

# Input row into DB
#$tableStorageItems = @()

Add-Type @"
public struct rowitem {
public System.String PartitionKey;
public System.String RowKey;
public System.String ComputerName;
public System.String UserName;
public System.String Model;
public System.String Manufacturer;
public System.String Serial;
public System.String Status;
public System.String Reason;
public System.String ResetType;
}
"@

$PCBuyback = New-Object rowitem
$PCBuyback.PartitionKey = 1
$PCBuyback.RowKey = $nextRowKey.ToString()
$PCBuyback.ComputerName = $ComputerName
$PCBuyback.UserName = $UserName
$PCBuyback.Model = $Model
$PCBuyback.Manufacturer = $Manufacturer
$PCBuyback.Serial = $Serial
$PCBuyback.Status = $Status
$PCBuyback.Reason = $Reason
$PCBuyback.ResetType = $ResetType
#$tableStorageItems += $PCBuyback

# insert the data
$Result = Push-OutputBinding -Name outputTable -Value $PCBuyback

$body = $body + " Adding the data returned (usually blank...): $Result `n"

}
$a = get-date
$body = $body + "$a Exiting Azure function.`n"
$a = Get-Date
$body = $body + "$a ------------------------------------`n"

# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body = $body
})

Save the changes, like so...

Step 2. Modify the http trigger Integration

In the new http trigger AddDataToAzure, click on Integration and then click on Add input

In the Binding Type drop down menu, select Azure Table Storage, in the Storage account connection click on New and select your pcbuyback storage account (which was created during part 1 in the initial creation of the function app. Change the Table name to PCBuyback. When done, click on Add.

Next, do the same thing for Output by clicking on Add output, then configure it as shown in the screenshot below. Finally click Add.

After adding both the input and output, the integration should appear like this.

Step 3. Create the VerifyDataAdded http trigger

In the previously created PCBuyback Function app, create a new http trigger called VerifyDataAdded

In the newly created Http trigger, click on Code + Test and paste in the following code to overwrite the existing code...

#######################################################################################################################################
# use this code in a http trigger as part of a function app
# Niall Brady, 2024/05/08
# for more info see https://www.windows-noob.com/forums/topic/23414-pc-buyback-for-windows-autopilot-devices-part-3
# https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-powershell?tabs=portal
#######################################################################################################################################

using namespace System.Net
# Input bindings are passed in via param block.
param($Request, $TriggerMetadata, $inputTable)
$Tenant = "windowsnoob.com"
$triggerName = "VerifyDataAdded"
# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."

# Interact with query parameters or the body of the request.
$nextRowKey = $Request.Query.nextRowKey
if (-not $nextRowKey) {
    $nextRowKey = $Request.Body.nextRowKey
}
$CheckComputerName = $Request.Query.CheckComputerName
if (-not $CheckComputerName) {
    $CheckComputerName = $Request.Body.CheckComputerName
}

    $a = Get-Date
    $body = $body + "$a ------------------------------------`n"
    $a = Get-Date
    $body = $body + "$a Starting the following trigger:  '$triggerName'.`n"
    $a = Get-Date
    $body = $body + "$a Connected to tenant: '$Tenant'.`n"

if ($nextRowKey -and $CheckComputerName) {
    $a = Get-Date
    $body = $body + "$a Checking the following row: '$nextRowKey'.`n"
    $body = $body + "$a Looking for this computername: '$CheckComputerName'.`n"
   
#}

#Put all table rows into $table
$table=""
foreach($row in $inputTable){
    $table+="$($row.PartitionKey) - $($row.RowKey) - $($row.ComputerName) - $($row.UserName) - $($row.Model) - $($row.Manufacturer) - $($row.Serial) - $($row.Status) - $($row.Reason) - $($row.ResetType)
   "
}
# print out the results...
#write-host ">>>>>$table<<<<<"

#validate section
#$body = $body + "Validate: $($($inputTable|Where-Object -Property RowKey -EQ 12).ComputerName)"
$a = Get-Date
$found = $($($inputTable|Where-Object -Property RowKey -EQ $nextRowKey).ComputerName)
$body = $body + "$a ComputerName found: $found`n"
#write-host "DEBUG: found " $found
if ($found -match $CheckComputerName) {
    $a = Get-Date
    $body = $body + "$a FOUND a MATCH :-)`n"
}
else
{
    $a = Get-Date
    $body = $body + "$a sorry, did not find a match :-(`n"
}
}
$a = get-date
$body = $body + "$a Exiting Azure function.`n"
$a = Get-Date
$body = $body + "$a ------------------------------------`n"

# show the output to the browser...Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body = $body
})

Click Save after adding the code above to the new trigger.

Step 4. Modify the http trigger Integration

In the new http trigger VerifyDataAdded, click on Integration and then click on Add input, configure it like so

And next, make the following changes to the output.

Step 5. Modify PCBuyback Azure table permissions

In your PCBuyback storage (contained within the PCBuyback resource group) modify the Access control (IAM) and add the following role assignments to your user that you want to create the Azure Table in the next step.

• Storage Table Data Contributor
• Storage Table Data Reader

Step 6. Create the PCBuyback Azure table

In your PCBuyback storage (contained within the PCBuyback resource group) which may be named differently depending on how you setup the functionapp, using the Storage browser option in the menu, browse to Tables and click on + Add table as shown here.

The Table name must be PCBuyback as shown here, click OK when done.

The created PCBuyback table is shown.

Step 7. Verify the http triggers

Now that you've created the triggers and modified the integration, you'll need to verify that they do what they are supposed to do. Let's start with the AddDataToAzure trigger. To test this, paste in the following text and click on Test/Run.

{
"ComputerName": "AP-XXXXXXXX",
"UserName": "NIALL",
"Model": "HP EliteBook 830 G7 Notebook PC",
"Manufacturer": "HP",
"Serial": "XXXXXXXX",
"Status": "OK",
"Reason": "PC Buyback (Intune)",
"ResetType": "WIPE"
}

as shown here...

If you did everything correctly it'll return a 200 HTTP response code along with the HTTP response content, if not, verify the steps above again.

Once the above trigger is tested successfully, click on Overview in the http trigger, and copy the function URL somewhere useful.

Finally, you can verify that it actually has poked the data into Azure tables, by browsing to the PCBuyback table and reviewing the data added.

Now that you have the RowKey and ComputerName, you can use that data to verify the other trigger in this part, namely the VerifyDataAdded trigger. Use the following code in that Test/Run and modify it as appropriate for your environment.

Note: The nextRowKey value will be revealed in the previous test and will be random, you need to provide the exact one from the previous test or copy it from the PCBuyback Azure tables. In other words, the nextRowKey value I'm showing below is unique to my environment and will most likely NOT work in your verification test.

{
    "nextRowKey": "1352755005",
    "CheckComputerName": "AP-XXXXXXXX"
}

After running that test, Success ! It found a MATCH.

Once the above trigger is tested successfully, click on Overview in the http trigger, and copy the function URL somewhere useful.

Step 8. Modify the PCBuyback.ps1 script

At this point we are done with the Azure changes and now need to modify the PCBuyback.ps1 PowerShell script. In PowerShell ISE (or VSCode) find this line and remove the # infront of StoreDetailsInAzure as shown below, also remove the $DateReset variable as we don't need it.

so that the line looks like this.

Next, locate the URI section here and add the two function URLS you copied in the steps above.

Save the script

Step 9. Upload changes to Intune

Use the IntuneWinAppUtil.exe to create a new version of the app that we created in Step 6, part 2 here,

After uploading the new intunewin version, log onto a test PC targeted with the PC Buyback app and test it.

The app launches by the user clicking on it...

and after clicking OK and reading the warning, the PC Buyback process begins in earnest.

and while the PC is busy resetting itself as described in Part 2, a record was added to our PCBuyback Azure tables, confirming that the user actually did buy back their PC.

Success !

that's it for this blog series, see you in the next one,

cheers

Niall

In part 1 I showed you how to prepare Azure for the PC Buyback app, in this part we'll add the Win32 app, deploy it and see how it behaves on a Windows Autopilot registered device.

This mini series is broken down into the following parts:

• PC Buyback for Windows Autopilot devices - part 1
• PC Buyback for Windows Autopilot devices - part 2 <--- You are here
• PC Buyback for Windows Autopilot devices - part 3

Step 1. Download the scripts

Download this zip and extract to C:\Dev\Intune\Win32 apps

Note: you must be a logged on member of windows-noob.com to download the ZIP

PC Buyback - Intune.zip

Step 2. Get ServiceUI.exe from MDT

You'll need the ServiceUI.exe executable file to display user interfaces (UI) to end users when operating in SYSTEM context. To get the file, download and install MDT somewhere and navigate to C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\x64. To download MDT click here. Copy the 64 bit version of ServiceUI.exe file to your extracted win32app_source folder so it looks like this.

Step 3. Get 7Zip for compressing files

Download 7Zip and install it. Copy 7z.dll and 7z.exe from the default folder C:\Program Files\7-Zip

Copy those 2 files to  C:\Dev\Intune\Win32 apps\PC Buyback - Intune\encode

In PowerShell ISE run the Encode script..

After it is completed encoding the files, you'll have a bunch of additional text files in the encode folder.

Open each text file using notepad, press CTRL+A to mark all the text, then copy using CTRL+C

and paste the content of each file using CTRL+V into the corresponding section of the PCBuyback.ps1 script as shown below.

Note: The QR code used in the PC Buyback app points to part 1 of this blog series, but you can customize it to point to an internal knowledge base article to assist users with the entire process. One thing to keep in mind, I used https://www.qr-code-generator.com to create the QR code, but after creating it, you'll need to resize it to 118x120 pixels (in MS paint or similar).

Step 4. Modify variables

In the PCBuyback.ps1 script, configure the following email related variables:

• $ToAddress
• $FromAddress
• $APIkey

Next, copy the Function URL for each of the http triggers you created in part 1, below shows you how to do that

paste those URLs into the corresponding variable in the script

Save the changes to the PCBuyback.ps1 script.

Step 5. Get the Microsoft Win32 content prep tool

Download the Win32 content prep tool from here. Copy the IntuneWinAppUtil.exe file to your Win32 apps root folder, it should look like this.

Open a command prompt and browse to the PCBuyback folder structure. Launch the IntuneWinAppUtil.exe file and answer the following.

• Please specify the source folder: win32app_source
• Please specify the setup file: PCBuyback.ps1
• Please specify the output folder: win32app_target
• Do you want to specify catalog folder (Y/N)? n

as shown here.

Step 6. Add the Win32 app in Intune

Log into Intune and add a new Win32 App. Below are some screenshots showing how I've configured the app.

For Select app type, select Windows app (Win32) from the drop down menu

Click on Select app package file and point it to the pcbuyback.intunewin file in the win32app_target folder, fill in some info about the app, for the logo, click on Select image and point it to the encode folder where the icon file can be used

fill in the install commands, point it to install_pcbuyback.cmd

fill in the requirements,

and for detection rules point it to the detection script in the root of the PC Buyback - Intune files

finally deploy it to an Entra ID group that contains the computers that are targeted for buyback, and deploy it as Available.

Step 7. Test the app on a device

On a test device that is already enrolled into Intune and Windows Autopilot registered, add the device to the azure ad group above and launch Company Portal. The PC Buyback app should appear.

Click Install and after a few moments the app should appear.

Clicking OK shows a warning

and clicking OK to the warning starts the process, after a few moments it will remove the device from Intune, then remove the Windows Autopilot registered device and zip up the logs before emailing them

After emailing the logs and confirmation that it's done PC Buyback, it will restart

after the restart it will start resetting Windows removing all apps and settings that were on the device

After the reset, Windows installs itself again...

and after the reinstallation, it's back to the first screen of the OOBE, so the user can now setup their device personally

When the user runs PC Buyback an email is sent to the email address you configured...

and the process will store details in Azure tables (coming in Part 3)

Troubleshooting

If the app fails for whatever reason, it will log the details in C:\ProgramData\windowsnoob\PCBuyback\win.ap.pcbuyback.log

Below is a sample of that log file from a successfully wiped device

04/06/2024 10:00:42 Starting script: 'Win.AP.PCBuyback' version: '0.0.5' ...
04/06/2024 10:00:42 extracting scripts to 'C:\ProgramData\windowsnoob\PCBuyback'...
04/06/2024 10:00:42 decoding BASE64 encoded file...'7z.exe'
04/06/2024 10:00:43 decoding BASE64 encoded file...'7z.dll'
04/06/2024 10:00:45 decoding BASE64 encoded file...'scanforhelp.png'
04/06/2024 10:00:45 decoding BASE64 encoded file...'PCBuybackUI.png'
04/06/2024 10:00:47 Detecting the logged on user...
04/06/2024 10:00:47 localuserfull was identified as: 'AzureAD\NiallBrady'
04/06/2024 10:00:47 Detection method 1: The user was identified as: NiallBrady
04/06/2024 10:00:47 SID: 'S-1-12-1-1583932090-1131944776-3006070936-2698034199'
04/06/2024 10:00:47 found sid
04/06/2024 10:00:48 registrypath is: HKU:\S-1-12-1-1583932090-1131944776-3006070936-2698034199\SOFTWARE\windowsnoob\Autopilot
04/06/2024 10:00:48 Checking if registryvalue: 'PCBuyback' in registrypath: 'HKU:\S-1-12-1-1583932090-1131944776-3006070936-2698034199\SOFTWARE\windowsnoob\Autopilot' exists...
04/06/2024 10:00:49 Reg key exists...
04/06/2024 10:00:49 registrypath is: HKU:\S-1-12-1-1583932090-1131944776-3006070936-2698034199\SOFTWARE\windowsnoob\Autopilot
04/06/2024 10:00:49 Checking if registryvalue: 'PCBuyback' in registrypath: 'HKU:\S-1-12-1-1583932090-1131944776-3006070936-2698034199\SOFTWARE\windowsnoob\Autopilot' exists...
04/06/2024 10:01:09 Reason added: ''
04/06/2024 10:01:11 The user chose OK to the PCBuyback warning, starting the reset process...
04/06/2024 10:01:11 Is this a Windows Autopilot device:
04/06/2024 10:01:11 Checking if the device is registered as a Windows Autopilot device started...
04/06/2024 10:01:11 Device serial number: 3135-5201-3107-6925-8353-2276-24
04/06/2024 10:01:19 DEBUG: The following was returned from the graph call. '
04/06/2024 17:01:19 Starting Azure function...
04/06/2024 17:01:19 Connected to tenant: windowsnoob.com.
04/06/2024 17:01:19 supplied serial number: '3135-5201-3107-6925-8353-2276-24'.
04/06/2024 17:01:19 Get Device Reference from Intune.
DeviceTrue.
04/06/2024 17:01:19 Serial number: 3135-5201-3107-6925-8353-2276-24 is an autopilot machine.
 Exiting Azure function.'
04/06/2024 10:01:19 the device was detected as a Windows Autopilot device, so let's remove it as a registered AP device
04/06/2024 10:01:19 Remove Windows Autopilot device from Intune started.
04/06/2024 10:01:19 Windows Autopilot device serial number: 3135-5201-3107-6925-8353-2276-24
04/06/2024 10:01:20 DEBUG: The following was returned from the graph call. 'Success'
04/06/2024 10:01:20 Removed Windows Autopilot device '3135-5201-3107-6925-8353-2276-24' from intune.
04/06/2024 10:01:20 Exiting the Intune based PC Buyback script, thanks for watching :-).
  If all went well and if the recovery partition on this device is healthy, Windows Reset should begin in the next few moments...
04/06/2024 10:01:20 DEBUG: The user chose OK to the PC Buyback Warning message. Starting the Windows reinstallation process now...
04/06/2024 10:01:20 checking for Power...
04/06/2024 10:01:20 virtual machine detected, will not check for power.
04/06/2024 10:01:20 Creating folder to store logs etc...
04/06/2024 10:01:20 Grabbing the reason why the user wanted to reset...
04/06/2024 10:01:20 Grabbing 'C:\ProgramData\windowsnoob\PCBuyback' logs
04/06/2024 10:01:20 Grabbing Windows temp logs
04/06/2024 10:01:20 DEBUG: Folder size (in bytes) = 2.22250366210938
04/06/2024 10:01:20 DEBUG: truncated bytes = 3
04/06/2024 10:01:20 Folder size (in MB) = 3
04/06/2024 10:01:20 Log files size: 3
04/06/2024 10:01:20 Log file size limit = 10
04/06/2024 10:01:20 Log file size (3) is less than 10, will include temp logs in email...
04/06/2024 10:01:20 Creating Autopilot cab file...
04/06/2024 10:01:42 adding C:\ProgramData\windowsnoob\PCBuyback\Win.AP.PCBuyback.log

Windows Autopilot allows you to quickly enroll devices using policies, apps and settings applicable to your tenant, and that's great for deploying new Windows devices. Those devices can be registered as Windows Autopilot registered devices by the OEM (Original Equipment Manufacturer) or by a third party integrator or by the organization themselves by importing the Windows Autopilot hardware CSV into Intune.

After a device has reached end of life however, it needs to be disposed of or sold on. It would be nice to offer end users the ability to buy back their old Company hardware with minimum fuss, but at the same time to remove Intune management and remove the device from Windows Autopilot registration while installing a new copy of Windows 11 professional that the end user could use for their own personal use.

I created a Win32 app that does all this called PC Buyback. The app integrates with a back end Azure app using http triggers to do the magic. This post will cover the app features and code needed to implement it in your own tenant.

The features of the app are as follows:

• Easy to use
• Self-Service app available in Company Portal
• Removes company data and apps
• Re-installs Windows
• Changes Windows edition using OEM license info stored in BIOS
• Emails results to a company inbox
• Logging to Azure tables (optional)

Note: In this blog, the app uses http triggers that use certificate secrets, this is fine in a lab, but in production you should use Azure Key Vault instead as it's more secure. If you'd like to understand how to set that up please read my blog post about Azure Key Vault here.

This mini series is broken down into the following parts:

• PC Buyback for Windows Autopilot devices - part 1 <--- You are here
• PC Buyback for Windows Autopilot devices - part 2
• PC Buyback for Windows Autopilot devices - part 3

Step 1. Create resource group

In Entra, using an account that has permission to create Resource Groups in your subscription, create a resource group called PCBuyback, create it in the region that your tenant is located.

Step 2. Create a function app in the resource group

In the PCBuyback resource group, create a function app in the same region as the resource group you created above.

Step 3. Create a RemoveAutopilotDevice http trigger

In the Function app, create a trigger called RemoveAutopilotDevice

In the newly created Http trigger, click on Code + Test

and paste in the following code to overwrite the existing code...

#  
# Remove Autopilot device by serial number
# Verify if the device is autopilot and delete it from intune

# version: 0.1 windowsnoob.com 2024/03/31

using namespace System.Net

# Input bindings are passed in via param block.
param($Request, $TriggerMetadata)

# Write to the Azure Functions log stream.
Write-Host "PowerShell HTTP trigger function processed a request."

# Interact with query parameters or the body of the request.
$serialNumber = $Request.Query.serialNumber
if (-not $serialNumber) { 
    $serialNumber = $Request.Body.serialNumber
}
# define the following variables
$ApplicationID = "" # create an application with permissions to delete devices in Azure 
$TenantDomainName = "" # your tenant name
$AccessSecret = "" # this is the secret of the app you create in app registrations

$GraphBody = @{
    Grant_Type = "client_credentials"
    Scope = "https://graph.microsoft.com/.default"
    client_Id = $ApplicationID
    Client_Secret = $AccessSecret
}
# make initial connection to Graph
$ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantDomainName/oauth2/v2.0/token" -Method POST -Body $GraphBody
#get the token
$token = $ConnectGraph.access_token

# to improve logging...
$body = " `n"
$response = ""
$body = $body + "$(Get-Date)" + " Starting Azure function...`n"
$body = $body + "$(Get-Date)" + " Connected to tenant: $TenantDomainName.`n"
# now do things...

if ($serialNumber) {
    $body = $body + "$(Get-Date)" + " You supplied serialNumber: '$serialNumber'" + ".`n"
    Try{
        # Get Device Reference from Intune
        $body = $body + "$(Get-Date)" + " Get Device Reference from Intune" + ".`n"
        $Device = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?`$filter=contains(serialNumber,'$serialNumber')" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value    
        
        If($Device){
            $body = $body + "$(Get-Date)" + " Found number of devices similar to '$serialNumber': $($Device.count)" + "`n"
            Foreach($d in $Device){
                If($d.serialNumber -eq $serialNumber){
                    $body = $body + "$(Get-Date)" + " Get deviceID from Intune: $($d.id)" + ".`n"
                  Invoke-RestMethod -Method Delete -uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($d.id)" -Headers @{Authorization = "Bearer $token"}     
                    $body = $body + "$(Get-Date)" + " Successfully deleted Device $($d.serialNumber) from Intune. May take a few minutes to complete in Intune Portal." + ".`n"
                    Write-Host $body
                    $response = "Success"
                    break
                }
            }
        }
        Else{
            $body = $body + "$(Get-Date)" + " serialNumber: $serialNumber does not exist in Intune" + ".`n"
            $response += "Failed"
            Write-Host $body
        }
    }
    Catch{
        $body = $body + "$(Get-Date)" + " $($Error)" + ".`n"
        $body = $body + "$(Get-Date)" + " Failed to get Device Reference from Intune." + ".`n"
        $response += "Failed"
        Write-Host $body
    }

    Try{
        # Get Device Reference from Windows AutoPilot
        $body = $body + "$(Get-Date)" + " Get Device Reference from Windows AutoPilot" + ".`n"
        $Device = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/deviceManagement/windowsAutopilotDeviceIdentities?`$filter=contains(serialNumber,'$serialNumber')" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value
        
        If($Device){
            $body = $body + "$(Get-Date)" + " Found number of devices similar to '$serialNumber': $($Device.count)" + "`n"
            Foreach($d in $Device){
                If($($d.serialNumber) -eq $serialNumber){
                    $body = $body + "$(Get-Date)" + " Get deviceID from Windows Autopilot: $($d.id)" + ".`n"
                    $body = $body + "$(Get-Date)" + " Get ManagedDeviceId from Windows Autopilot: $($d.managedDeviceId)" + ".`n"
                    Invoke-RestMethod -Method Delete -uri "https://graph.microsoft.com/v1.0/deviceManagement/windowsAutopilotDeviceIdentities/$($d.id)" -Headers @{Authorization = "Bearer $token"}     
                    $body = $body + "$(Get-Date)" + " Successfully deleted Serial Number $($d.serialNumber) from Windows Autopilot device. May take a few minutes to complete in Intune Portal." + ".`n"
                    $response = "Success"
                    Write-Host $body
                    break
                }
            }
        }
        Else{
            $body = $body + "$(Get-Date)" + " Serial Number: $serialNumber does not exist in Windows Autopilot" + ".`n"
            $response += "Failed"
            Write-Host $body
        }
    }
    Catch{
        $body = $body + "$(Get-Date)" + " $($Error)" + ".`n"
        $body = $body + "$(Get-Date)" + " Failed to get Serial Number: $serialNumber from Windows Autopilot." + ".`n"
        $response += "Failed"
        Write-Host $body
    }
    
    $body = $body +  "$(Get-Date)" + " Exiting Azure function."
    
}

# Associate values to output bindings by calling 'Push-OutputBinding'.
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
 StatusCode = [HttpStatusCode]::OK
 Body = $response
})