Windows 10

Windows 10 on ARM64

I admit it, I still have flashbacks about Windows RT, the previous version of Windows that ran on ARM processors.  (Don’t remember that?  Read up on it here.)  That was a 32-bit version of the OS (with significant restrictions), running on older, slower processors.  The ARM processor platform has come a long way since then – it’s moved to 64-bit and has grown significantly faster.  So with the announcement of the Always Connected PC (sometimes called Always On Always Connected, or AOAC) in 2017, Windows again runs on ARM processors.

This time around, the devices ship with a full Windows 10 operating system.  Initial versions ran Windows 10 S, which could be unlocked to Windows 10 Pro for free.  Later versions ship with Windows 10 Home in S Mode, which can be unlocked to Windows 10 Home for free, and upgraded to Windows 10 Pro via the Microsoft Store for a fee.  So you can probably guess that these devices are more consumer-focused at this point, because commercial devices would ship with Windows 10 Pro (S mode or not) in order to support Azure AD Join, Active Directory Join, Windows Autopilot, etc.  Maybe that will change at some point in the future.

Here’s an overview of the devices that have shipped (so far) with each ARM64 generation:



HP Envy x2, Lenovo Miix 360, Asus NovaGo 

850Lenovo Yoga C630, Samsung Galaxy Book 2

Samsung Galaxy Book S (coming soon), Lenovo Project Limitless (prototype)

If you read the reviews of the older devices based on the 835 and 850 processors, they are not the greatest.  But the 8cx processors are pretty fast, so I’m hopeful – it would be nice to have a device with a very long battery life.

How else are these devices different?  Well, they have LTE connectivity, so they are “Always Connected.”  But for me, there are a few other differences.

Support for existing Win32 apps

If you have a Windows 10 device, you expect it to be able to run standard Win32 apps.  But those apps were created for x86/x64 processors.  So how can they run on Windows 10 ARM64 versions?  It does that using the Windows on Windows (WOW64) layer to dynamically translate 32-bit x86 instructions into ARM64 equivalents.  So you should be able to run your existing 32-bit apps on the devices.  There are some limitations (e.g. drivers), but most typical productivity software will work just fine.  (Security software often uses drivers, so you might not be so lucky there.)

ISVs could also choose to natively compile their existing 64-bit Win32 apps using ARM64 compilers in Visual Studio

No support for OS deployment tools

If you think you can create and deploy a custom WIM image for ARM64 devices using MDT or ConfigMgr OSD, it’s not quite that simple.  To support this on ARM64 devices, there would need to be native 64-bit version of the task sequence engine (used by both tools) and some other components (e.g. utility executables) that run in Windows PE.  The ADK does include ARM64 components, but the ARM64 version of Windows PE will only run ARM64 code, not x86 or x64 code.  You would also need driver packages, which may not be available.  So you’re better off with modern deployment processes, e.g. Windows Autopilot, that leverages the preinstalled OS from the OEM.

Support for Windows Autopilot and Intune

Once you unlock/upgrade one of these devices to Windows 10 Pro, you can use Windows Autopilot to deploy them.  They can be joined to Azure AD or Active Directory (Hybrid Azure AD Join).  They can be managed by Intune, or co-managed with ConfigMgr.  (ConfigMgr will install the 32-bit x86 ConfigMgr client.)  For the most part, this “just works.”  But there are some potential gotchas:

  • Intune and ConfigMgr have no knowledge of ARM64 apps, which makes it more challenging to say “these apps are only applicable to ARM64 devices.”
  • Intune and ConfigMgr may not realize that 32-bit x86 apps can run on ARM64 devices.
  • You might not have taken this into account when you wrote PowerShell scripts, VBScripts, or any other custom stuff.

You can work around these without any great difficulty (e.g. change architecture restrictions, target apps without using architecture, fix your scripts).  And certainly Intune and ConfigMgr could add additional ARM64 features to help with this.

My Experiences

Of course I had to try it out – more than once.  I initially used one of the first-generation 835-based devices, quite a long time ago, which formed the opinions I provided above.  But as we have a device lab that happens to have a second-generation 850-based device that I was able to borrow, I thought it would be good to give it another try.  As expected, the device was preloaded with Windows 10 Home in S Mode, but it was running Windows 10 1803.  I wanted to try out more advanced Windows Autopilot scenarios (e.g. white glove) so I had to go through a few more hoops:

  • Upgrade to Windows 10 1903.  (Windows Update doesn’t typically offer a new OS to a “brand new” device; it will wait a while.  I hurried that along by joining the device to the Windows Insider release preview ring, so I could get 1903 right away.  After upgrading to 1903, I was offered the 1909 preview, but I didn’t need to try that out right now so I stuck with 1903.)
  • Upgrade to Windows 10 Pro in S Mode.  This required putting in a new Windows 10 Pro retail product key.
  • Unlock the device to get out of S Mode.  I would have been OK with S Mode overall, but I needed a simple way to grab the hardware hash from the machine, and that means I needed to be able to run a PowerShell script.

After doing all of that, I grabbed the hash, registered it with Autopilot, and assigned a user-driven Azure AD Join profile to the device.  I then reset the OS and started “clean.”  The Windows Autopilot white glove process kicked off fine, joining the device to Azure AD and enrolling in Intune.  The Intune Management Extensions (32-bit MSI) installed as expected, and identified several apps that needed to installed.  Office 365 ProPlus was also targeted. 

While that stuff was being processed, I could poke around on the device to see that it has three different “Program Files” directories:

  • C:\Program Files.  This one has 64-bit ARM64 native apps.
  • C:\Program Files (x86).  This one has 32-bit x86 apps, which run in WOW as described previously.
  • C:\Program Files (arm).  This one has 32-bit ARM apps, which have their own WOW environment (just like 32-bit x86 apps have on a 64-bit Intel/AMD system).

It also has registry redirection in place, with three paths instead of the normal two that you would see on a 64-bit Intel/AMD system:

  • HKLM\Software for 64-bit ARM64 native apps.
  • HKLM\Software\WOW6432Node, for 32-bit x86 apps.
  • HKLM\Software\WowAA32Node, for 32-bit ARM apps.

By that time, I could see that every app I deployed either failed or was skipped as “not applicable.” 


That’s actually pretty much what I expected:  These are all 64-bit x86 apps.  The ones that failed weren’t configured to say that they only supported 64-bit, so Intune tried to install them.  The ones that say “not applicable” were marked as 64-bit only in Intune.  And then due another odd ESP behavior (see the 4th item on this list – still working on fixing that), I then had to wait an hour for everything to fail.

But still, that’s a success overall:  the device could be registered with Autopilot, joined to Azure AD, and enrolled in Intune without any issues.  TPM attestation worked well, as did the white glove flow (other than that odd ESP behavior).  If I added appropriate 32-bit x86 apps into Intune and set up the targeting appropriately, it’s highly likely that the device could be provisioned without issue.  The only bad part:  I thought I didn’t need 32-bit apps any more because the world had moved on to 64-bit OSes.  Well, here’s an exception.

I did manually install Office 32-bit on the device and used it a while as a productivity device.  It worked well for that – I could see myself using a device in this class for “typical” information worker tasks. 

Do you have to worry about any of this?

As I mentioned, these aren’t positioned as commercial devices yet – they don’t run Windows 10 Pro (S mode or not) by default.  But that could certainly change in the future.  So keep an eye on these (and keep those 32-bit apps around, just in case).  If you’re a gadget-type, you might want to pick one up and play with it.  The battery life is amazing.

Categories: Windows 10

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s