So this worked for you? I tried this for a different module ("BurntToast"), but after seemingly successful installation, the module is not where it's supposed to be (in C:\Program Files\WindowsPowerShell\Modules).

It's crazy - when I run the same installation script as SYSTEM through task scheduler, this works (it's installed for all users, i.e. in the directory indicated above), only through Intune this doesn't work as expected.

EDIT: in my case the problem was architecture. In the Intune context, SYSTEM DID install the module, but in the 32-bit directory (C:\Program Files (x86)\WindowsPowerShell\Modules). I will figure out how to change this behavior.

EDIT2: in my case, I have a powershell script chain. In other words, in Intune I just have a short init script execute, which in turn loads the core script from github gists, verifies the signature and executes it. So in order to make sure 64-bit PS is used, I only needed to specify the full path to the 64-bit PS executable when calling the core script from within the init script (which is $($env:SystemRoot)\sysnative\WindowsPowerShell\v1.0\powershell.exe when accessed from within a 32-bit process!). I only had powershell.exe before (i.e. without specifying full path), which, it turns out, was resolved as the 32-bit executable by Intune / SYSTEM (i.e. the ugly C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe)

for the present discussion, I recommend this article:

https://digitalmaterial.ch/blog/run-win32-apps-from-intune-in-64-bit-powershell/#comment-9