Error invoking Powershell script on Azure web apps via Kudu API

My team is running a bunch of Powershell scripts (like this) on web apps as part of our deployment process, for example to enable Solr (Sitecore configs). This was all working fine until this morning when we were getting the following error:

Invoking Kudu Api: https://mysite.scm.azurewebsites.net/api/command
@{Output=; Error=File D:\home\site\wwwroot\App_Data\Scripts\myscript.ps1 cannot be
loaded because running scripts is disabled on this system. For more
information, see about_Execution_Policies at
http://go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : SecurityError: (:) [], ParentContainsErrorRecord
   Exception
    + FullyQualifiedErrorId : UnauthorizedAccess
; ExitCode=0}
Kudu Api Successfully invoked.

Obviously following the link tells you all about Powershell security policies, and I could see that on our particular apps (and slots) via Kudu powershell, when running the command Get-ExecutionPolicy -List these were set to:

                                  Scope                         ExecutionPolicy
                                  -----                         ---------------
                          MachinePolicy                               Undefined
                             UserPolicy                               Undefined
                                Process                            RemoteSigned
                            CurrentUser                               Undefined
                           LocalMachine                               Undefined

whereas on the rest of our servers the LocalMachine value was set to RemoteSigned. There doesn't appear to be any way to change this via command line, or in the app properties. What's more I could run the desired Powershell script through the Kudu command line just fine, but the Kudu API wasn't working (so they must be different under the covers?).

After a lot of hunting around and bashing my head against the wall, I realised that somehow the web apps properties had been set to 32-bit mode, rather than their usual 64-bit. I have no idea why this affects the LocalMachine execution policy (or any of them for that matter), but this seems to be the fix for this particular issue.

Hopefully this helps someone out there!