“Windows has traditionally run on machines that are powered by x86 / x64 processors, but more recently, also runs on devices powered by ARM processors. ARM-powered devices are particularly interesting because the power-frugal nature of the ARM architecture enables these devices to offer longer battery life while delivering great performance.”
“Windows 10 enables existing unmodified x86 apps to run on ARM devices. Windows 11 adds the ability to run unmodified x64 Windows apps on ARM devices! This ability to run x86 & x64 apps on ARM devices gives end-users confidence that the majority of their existing apps & tools will run well even on new ARM-powered devices. For the best performance, responsiveness, and battery life, users will want and need ARM-native Windows apps, which means that developers will need to build or port ARM-native Windows apps.”
Source: Microsoft
“Beginning with Windows 10, version 2004, all new Windows 10 systems will be required to use 64-bit builds and Microsoft will no longer release 32-bit builds for OEM distribution.”
Source: Engadget
The Windows 11 ARM and the x64 apps saga
Based on the two statements, and due to my natural curiosity for things, I thought it’d be fun to deploy a Windows 11 ARM64 on my m1 Mac mini (since my ARM-based Lenovo for tests is taking ages to be delivered) and test Microsoft Intune’s management capabilities. As soon as I finished the build, I noticed my required apps were not installed (despite no errors during ESP).
So, I went into Intune and checked the newly enrolled device and 7-Zip (one of the required apps) was saying “not applicable”. Interesting. Then I checked the app itself on Intune and checked the device install status.
Wait, shouldn’t Windows 11 emulate both x86 and x64 apps?? Well, looks like that’s just Windows, but Intune Management Extension runs as an emulated x86 agent. So, in this particular scenario, the app was only made available for x64 architecture, and since Microsoft does not release new OEM builds for 32-bits, there was no reason for me to mark support for x86 architecture in Intune. Or so I thought.
That was until I tried to deploy this app to the ARM64 Processor. Because Intune does not yet support ARM64 architecture (more to that in a second), I need to change all the apps to support x86 if I want to use the emulated version of said app. But what makes it even more complex is that if the app itself is x64, like my 7-Zip, you still need to allow the x86 architecture so Intune offers the app to ARM64. Then it doesn’t matter if the app itself is x64 or x86, since Windows 11 can emulate both.
The Windows 11 ARM and the ARM64 built or ported apps
OK, now that I know how to install emulated apps on an ARM64 Windows 11 via Intune, how about deploying ARM64 apps, like VSCode?
Well, if the app is ARM64 you’d assume we only need to check the 32-bit (x86) architecture type right? Yes, otherwise that might also be offered to x64 machines, and that might cause even more confusion to end users where they have a x64 version of VSCode and an ARM64, which will fail to deploy.
How should I set it up in Intune? And what’s coming?
For now, if your environment does not have any 32-bit Windows running I would suggest:
- For apps you don’t want to offer ARM64, mark their architecture as only 64-bit on Intune.
- For apps you want to offer both X64 and ARM64 (emulated), mark their architecture as 64-bit and 32-bit on Intune.
- For apps you only want to offer ARM64, mark their architecture as only 32-bit on Intune.
If your environment is running 32-bit versions of Windows I would suggest:
- Adding all ARM devices to an Azure AD Group or using Intune Filters to exclude them from the 32-bit apps and then target the ARM apps using the same method.
If you want to have a sneak peek of what’s coming, Microsoft Graph API for Win32LobApp documentation is an excellent source. Under applicableArchitectures we can see the graph already supports extra values like arm,arm64 and neutral.
Similar to x86 and x64, ARM is 32-bit and ARM64 is 64-bit, but what I find intriguing is the neutral option. If you follow macOS land, you would have noticed that when Apple released M1 processors (and now M2), which are ARM-based, some developers created different installers (one installer for Intel Chip and one installer for Apple Silicon). However, they also created a Universal Installer (you can see the three examples under mac at VSCode Download Page. Universal installers are bigger in size because they have both versions within the same installer, and once executed the installer will pick whichever processor the device is running on. I wonder if neutral in Intune was conceived with the same idea.
These changes will be well received for environments supporting 32-bit Windows, which will not require the app to be advertised to 32-bit running operating systems because of ARM64 emulation requirements.
Playing with Graph Explorer
If you, like me, like playing with automation, you already heard of Graph Explorer and might be aware of what it’s capable of. If you don’t and would like to know more, I would suggest you start with Luise Freese’s blog. I’ve tried to change one of my existing apps via Graph Explorer to add one of the new entries (ARM64 specifically). And although the PATCH action completes, the entry is not added. When I run another GET on the app, the applicableArchitectures will still only show x86 and x64 (or one of them).
The steps used to test were:
- Go to Endpoint Manager Console, open a win32app and copy its mobile app id (the GUID address bar)
-
Click the button below and replace {mobileAppId} with the GUID from the step above and click Run Query
- Make notes of the applicableArchitectures
-
After that, you can click the button below and change the same info, but now run a patch by clicking Run Query to add ARM64 to the same app
Repeat steps 1 and 2 and the applicableArchitectures entry should match the one from step 3.
Thanks for reading.
Comments