Today in this post, I want to share with you my experience of managing a Windows 10 on ARM device with Microsoft Intune.
This is a follow-up to my previous post in which I tried to introduce you to the ARM64 variant of Windows 10.
Things that this blog post covers are listed below.
- How to get your hands on Windows 10 on ARM for testing?
- How can you get a Windows 10 on ARM device into enterprise management with Intune?
- App deployment experience to a Windows 10 on ARM device from Intune?
- Things to be considered for PowerShell scripts.
So let’s get started.
Table of Contents
How to get your hands on Windows 10 on ARM for testing?
In my previous post, I already mentioned that Windows 10 on ARM is an RTM [Release To Manufacturer] release, meaning Microsoft only licenses it to OEMs who manufactures ARM-powered notebooks to ship such devices with the ARM version of Windows OS pre-installed.
Does that mean you can’t test the ARM version of Windows 10 with the help of a VM, like we can test the traditional x64 version of Windows 10 on Hyper-V or any other virtualization software?
You can get the ARM version of Windows 10 in the form of a VHDX file available for download by signing-up for the Windows Insider Program.
However, there is a catch here!
The VHDX file downloaded contains the ARM64 version of the Windows 10 image that only works on ARM64 processors.
As such you won’t be able to use it for creating a VM on an x64 host system!
Microsoft mentions the below requirements to setup the ARM version of Windows 10 on a VM.
- ARM-powered hosts that are running either the Microsoft SQ1, Microsoft SQ2, Qualcomm Snapdragon 8cx, or Qualcomm Snapdragon 850 processor.
- Windows 10 on ARM (Host OS) in PRO or Enterprise SKU with build 19559 or newer.
- Hyper-V enabled.
Thus, if you want to have your hands on Windows 10 on ARM, either on a device directly or as a VM, you would still need an ARM-powered system as per the specifications above.
Do not have any such ARM-powered Windows notebook available with you but happen to own an M1 Mac device?
You can test the ARM-specific variant of Windows 10 with a Mac device that’s armed with Apple’s new ARM-based M1 SoC.
But before we begin, it is important to note that…
No Boot Camp support on Apple Silicon
The new Apple silicon (M1) powered Mac devices do not support Boot Camp anymore, a very popular software that is often used by many to dual boot Windows on Intel (x64) powered Mac devices.
This makes complete sense because with Microsoft having no plans of making their ARM specific Windows 10 available generally anytime soon, there was no point for Apple to carry forward the support of Boot Camp on their M1 Mac devices. This is because the M1 SoC being based on ARM architecture, unless Boot Camp could somehow translate the x64 instructions to ARM instructions on the runtime (Rosetta 2 maybe!), there is no way one could have dual boot a M1 Mac device with a x64 version of Windows 10 anyways!
However, It would be definitely interesting to see how Apple brings back Boot Camp support for their ARM-powered Macs, if and when Microsoft decides to start licensing Windows 10 on ARM for general availability.
As such, if you were thinking that you would be able to dual boot an M1 Mac device with the ARM version of Windows 10, it’s not something that’s going to happen anytime soon.
Leaving Boot Camp out of consideration, the only other option left is to use a supported virtualizer.
Virtualizer is the way forward…
This brings me to mention Alexander Graf, the first person who adapted QEMU, a popular open-source machine emulator and hardware virtualizer, to run Windows 10 on ARM on Apple Silicon (ARM-based M1 SoC).
You can find the steps to run Windows 10 on ARM as a VM on an M1 Mac using QEMU here.
However, I have used Parallels Desktop instead which is a very popular but premium software that allows hardware virtualization on Mac devices.
Setting up Windows 10 on ARM on an M1 Mac using Parallels Desktop
Note that the current GA version of the software, the Parallels Desktop version 16 is meant for the x64 Intel variants and not for Macs running Apple's ARM-based M1 SoC. The Parallels team is actively working on a version specific for Apple's new ARM-based SoCs and they have made it available via their Technical Preview Program. (and it's free, well till the time it remains in beta!)
Get Windows 10 on ARM VHDX
You first need to sign-up for Windows Insider Program and then you can download the Windows 10 on ARM VHDX file.
Download the VHDX file on your Mac. (or transfer it to your Mac if your downloading it on another system)
Get Parallels Desktop 16 for Mac devices running Apple Silicon
As of now, till the software is in beta and not released generally, all you would need to do is
- Follow this link
- Register for a Parallels account (or sign into a Parallels account if you already have one)
and you get to try the beta build of the Parallels Desktop 16 which is for the M1 Mac devices.
Download the package, install and activate it on your Mac.
Now that you have both the virtualizer software installed and the VHDX file containing the OS image, let’s start creating the Virtual Machine.
Create a VM with the VHDX file
On first run of Parallels Desktop (or when you have no VM created), you get the Installation Assistant screen as shown below.
Click on the Continue button.
It would now ask for a VHDX file which has an OS image to create the VM.
Simply drag the Windows 10 Client ARM64 Insider Preview VHDX file that you downloaded previously into this screen. The software will automatically detect the OS in the VHDX file provided.
Click on Create button and it will start creating the VM.
Follow through the usual on screen flow and you would have Windows 10 on ARM running as a VM on a M1 Mac ready in no time.
Management experience with MEM Intune
Now that we have got our Windows 10 on ARM VM running, let’s check the experience of managing the same with MEM Intune.
Provisioning Windows 10 on ARM with Windows Autopilot
Extracting the hardware hash and uploading it via the MEM portal to register the VM with Autopilot service is, as usual, using the Get-WindowsAutoPilotInfo script.
You can use the Graph Explorer to check the registered Windows Autopilot device
Get https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeviceIdentities { "@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceManagement/windowsAutopilotDeviceIdentities", "@odata.count": 1, "value": [ { "id": "3b0a368a-eda9-4724-aeda-11077e3047c8", "deploymentProfileAssignmentStatus": "assignedOutOfSync", "deploymentProfileAssignmentDetailedStatus": "none", "deploymentProfileAssignedDateTime": "0001-01-01T00:00:00Z", "orderIdentifier": "", "groupTag": "", "purchaseOrderIdentifier": "", "serialNumber": "Parallels-XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX", "productKey": "", "manufacturer": "Parallels", "model": "Parallels ARM Virtual Machine", "enrollmentState": "notContacted", "lastContactedDateTime": "0001-01-01T00:00:00Z", "addressableUserName": "", "userPrincipalName": "", "resourceName": "", "skuNumber": "", "systemFamily": "Parallels VM", "azureActiveDirectoryDeviceId": "36a9b2cf-9c1a-4ea3-abd8-9287fc7d169c", "managedDeviceId": "00000000-0000-0000-0000-000000000000", "displayName": "" }]}
As usual, there is an associated Azure AD device object that gets created for the autopilot registration which is stamped with the ZTDID.
There is no difference in the Autopilot provisioning for the ARM64 variant of Windows 10 vs the traditional x64 variant.
The device in OOBE greets you with the branded sign-in screen
And once the user signs-in with correct credentials, it goes through the ESP to track device setup as configured from MEM portal.
Once done, it gets the user to the desktop.
Same experience, just a different OS architecture!
Unless you have confirmed that your Intune win32 app deployments work on Windows 10 on ARM devices, you may end up with an ESP provisioning failure for failed Win32 app deployments if you are tracking those during ESP.
The above statement is explained later in this post!
As of now, Intune (MEM) can’t uniquely identify ARM variant of Windows
Well atleast on the MEM portal, the only column that helps to easily identify Windows 10 on ARM device is the Model.
The OS version to identify OS type is not that user friendly, to be honest. (Who remembers OS type by build numbers anyway!)
An identifier like OSArchitectureType clearly showing whether the OS is an x64 or ARM variant would be a nice little addition!
However, I did find it quite interesting that Microsoft still uses WindowsRT as deviceType to identify Windows 10 on ARM devices.
{
"id": "f5c53a98-b28b-4d97-b864-b25e90fde7d0",
"userId": "d35ca381-e692-4e08-9d33-759db7dff5d5",
"deviceName": "JOY-64839",
"ownerType": "company",
"managedDeviceOwnerType": "company",
"managementState": "managed",
"enrolledDateTime": "2021-01-17T19:06:51Z",
"chassisType": "unknown",
"operatingSystem": "Windows",
"deviceType": "windowsRT",
"complianceState": "compliant",
"managementAgent": "mdm",
"osVersion": "10.0.21286.1000",
"azureADRegistered": true,
"deviceEnrollmentType": "windowsAzureADJoin",
"activationLockBypassCode": null,
"emailAddress": "joymalya@intunewithjoy.in",
"azureActiveDirectoryDeviceId": "36a9b2cf-9c1a-4ea3-abd8-9287fc7d169c",
"deviceRegistrationState": "registered",
"exchangeLastSuccessfulSyncDateTime": "0001-01-01T00:00:00Z",
"isEncrypted": false,
"userPrincipalName": "joymalya@intunewithjoy.in",
"model": "Parallels ARM Virtual Machine",
"manufacturer": "Parallels",
"complianceGracePeriodExpirationDateTime": "9999-12-31T23:59:59Z",
"serialNumber": "Parallels-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"userDisplayName": "Joymalya Basu Roy",
"configurationManagerClientEnabledFeatures": null,
"wiFiMacAddress": "",
"deviceHealthAttestationState": null,
"totalStorageSpaceInBytes": 274532925440,
"freeStorageSpaceInBytes": 253547773952,
"managedDeviceName": "joymalya_Windows_1/17/2021_7:06 PM",
"autopilotEnrolled": true,
"managementCertificateExpirationDate": "2022-01-15T09:45:33Z",
"processorArchitecture": "unknown",
"joinType": "azureADJoined",
"skuFamily": "Pro",
"skuNumber": 48,
"hardwareInformation": {
"serialNumber": "Parallels-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"tpmSpecificationVersion": null,
"operatingSystemEdition": null,
"deviceFullQualifiedDomainName": null,
"deviceGuardVirtualizationBasedSecurityHardwareRequirementState": "meetHardwareRequirements",
"deviceGuardVirtualizationBasedSecurityState": "running",
"deviceGuardLocalSystemAuthorityCredentialGuardState": "running",
"osBuildNumber": null,
"operatingSystemProductType": 0,
"sharedDeviceCachedUsers": []
},
Create Azure AD dynamic Device group for Windows 10 on ARM devices
deviceModel being the only attribute to identify a Windows 10 on ARM device on the MEM Intune portal brings me to an important topic that is the Azure AD group.
If you would want to contain Windows 10 on ARM devices in a separate group for exclusion purposes from the rest of x64 based devices and/or to target things that are specific to the ARM64 variant, as of now, you can create a dynamic device group using device Model as the basis of your dynamic query.
For example, I created a dynamic Azure AD group using the below query
(device.deviceModel -contains "Parallels ARM Virtual Machine")
If you have Windows 10 on ARM devices of different models or from different OEMs, you can create a dynamic device group based on a query, something like this
(device.deviceModel -contains "Parallels ARM Virtual Machine") or (device.deviceModel -contains "Surface Pro X") or (device.deviceModel -contains "<OEM Model>")
You can now use this group to target/deploy policies (or for exclusion from existing policies) to your Windows 10 on ARM devices.
Configuration and Compliance work as usual on Windows 10 on ARM
In the limited time that I spent with the VM as of now, I have not seen any issues with the configuration profiles that I applied which are listed below.
- Device Restrictions – Prevent Automatic Encryption on AAD Join
- Device Restrictions – Start Menu Layout
- Admin Template – OneDrive Known Folder Redirection
- Trusted Certificate profile
- SCEP Certificate profile
- Windows Health Monitoring (for Endpoint Analytics Performance score)
- Windows 10 MDM Security Baseline for August 2020
- Endpoint Protection > Disk Encryption > Bitlocker Silent Encryption policy
All applied with success, except for the last one which returned with a failed status.
However, a quick look at System Information disclosed that the policy failure is due to the system not meeting requirement itself.
Note that since this ARM64 version of Windows 10 is running on an M1 Mac, so no support for TPM and UEFI Secure Boot.
Application deployment from Intune
Michael Niehaus in his blog post already pointed that Windows 10 on ARM has three different default directory for the different types of application as below
- C:\Program Files – For 64-bit ARM native apps and now 64-bit win32 apps (x64) as well.
- C:\Program Files (x86) – For 32-bit win32 apps (x86)
- C:\Program Files (Arm) – For 32-bit ARM native apps.
The 32-bit applications (both x86 and ARM) runs in their own WOW environment and the corresponding registry redirection paths are
- 32-bit win32 (x86) apps –
HKLM\SOFTWARE\WOW6432Node - 32-bit ARM apps –
HKLM\SOFTWARE\WowAA32Node
HKLM\SOFTWARE being the registry path for 64-bit ARM native and 64-bit win32 (x64) apps.
Coming back to Intune app deployment, I had the below apps deployed.
- Zoom – x86 MSI LOB app
- Company Portal – MSfB Online app
- VLC – x64 win32 app
- Cisco AnyConnect – x64 win32 app
- Microsoft 365 Apps for Windows 10 (O365 Pro Plus)
The x86 MSI LOB app and the MSfB Online app installed successfully as can be seen in the snap below.
However, the M365 Apps for Windows 10 (previously the Office Pro Plus suite) failed with Error code: 0x643
Office couldn't install because the version of Office that's already installed on the device is either MSI or a different architecture. Make sure you've removed any MSI versions of Office and that any existing Click-to-Run versions have the same architecture as what you're installing (32 bit or 64 bit).
Interestingly, the 64-bit Office C2R setup when initiated from portal.office.com did get installed fine!
Need to check to find out why? For someday later maybe!
Now comes the most interesting part and that is Win32 app deployment. During the short time I got to spend with this till now, I had no luck. 😅
Below is the log entries for one of the x64 win32 app processed by IME agent on the VM
[Win32App] Processing app (id=ac853466-40a5-4c14-b096-235dc90e0228, name = vlc-3.0.12-win64.exe) with mode = DetectInstall [Win32App] ===Step=== Detection rules [Win32App] Completed detectionManager SideCarRegistryDetectionManager, applicationDetectedByCurrentRule: False [Win32App] ===Step=== Check applicability [Win32App] applicationRequirementMetadata RequiredOSArchitecture: 2, client Is64BitOperatingSystem: True, nativeMachine IsArm64: True, applicability: ProcessorArchitectureNotApplicable. [Win32App] Applicability is ProcessorArchitectureNotApplicable for app ac853466-40a5-4c14-b096-235dc90e0228, report compliance message and skip further processing.
And the process stops there. But the other x64 win32 app deployment created with exact same settings on the portal did actually got past the Applicability stage on the same VM.
[Win32App] Processing app (id=9568913d-e8b1-41de-aac0-be38c6b8e011, name = CiscoAnyConnectSecureMobilityClient-4.8.02042-100.exe) with mode = DetectInstall [Win32App] ===Step=== Detection rules [Win32App] Completed detectionManager SideCarRegistryDetectionManager, applicationDetectedByCurrentRule: False [Win32App] ===Step=== Check applicability [Win32App] applicationRequirementMetadata.RequiredOSArchitecture is 0 or 3, skip check. [Win32App] applicationRequirementMetadata expected version: 10.0.17134, client version: 10.0.21286, applicability: Applicable. [Win32App] ===Step=== Check Extended requirement rules [Win32App] No ExtendedRequirementRules for this App. Skipping Check Extended requirement rule [Win32App] ===Step=== Download [Win32App] GRS is expired. kick off download & install Notified DO Service the job is complete. [Win32App] hmac validation is pass. [Win32App] Decryption is done successfully. [Win32App] Start unzipping. [Win32App] ===Step=== Execute retry 0 [Win32App] Create installer process successfully. [Win32App] Installation is done, collecting result [Win32App] lpExitCode 1603 [Win32App] hResultFromWin32 -2147023293
And it also failed.
[Win32App] Admin did NOT set mapping for lpExitCode: 1603 of app: 9568913d-e8b1-41de-aac0-be38c6b8e011 [Win32App] Set EnforcementStateMessage EnforcementState: Error, ErrorCode: -2147023293
Noticed that for the 2nd win32 app, the IME applicability check is a bit different than the 1st app it processed?
As of now, I don’t have an answer to why it is such, though both the apps actually do have the exact same settings configured on the portal.
If you have already worked on Windows 10 on ARM and know how to get win32 app deployment from Intune work on such devices, let’s catch up offline for a conversation!
PowerShell script deployment however executed succesfully.
Prepare to run Powershell Script scriptParams is cmd line for running powershell is -executionPolicy bypass -file "C:\Program Files (x86)\Microsoft Intune Management Extension\Policies\Scripts\00000000-0000-0000-0000-000000000000_d5d75f69-7e29-4a01-bb68-388843e96303.ps1" PowerShell path is C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe [Executor] created powershell with process id 1216 AgentExecutor 1/17/2021 7:07:59 PM 1 (0x0001) Powershell exit code is 0 Powershell script is successfully executed. AgentExecutor 1/17/2021 7:08:03 PM 1 (0x0001) Agent executor completed.
The End
Well, that was all for today.
I will update this post as and when I find time to work out the app deployment issues as described on this post.