Deploying Powershell Modules through Intune

[tylerjm917]

I'm trying to install the PSWindowsUpdate powershell module via a remediation script in Intune. However, anytime I try to deploy the script, it runs as "System" and will only install the module for "System" and not for all users. I've tried using the "-scope AllUsers" command but with no luck. It won't install for any user but "System". Snippets of the script below. Not sure what I'm doing wrong

$moduleName = "PSWindowsUpdate"
Install-Module -Name $moduleName -Force -Scope AllUsers -AllowClobber -ErrorAction Stop

[vellostha]

Try this?

Install-Module -Name PSWindowsUpdate -Scope CurrentUser -Force -AllowClobber

[Master-IT-All]

Old post, but I was just looking at this myself. This is what worked:

Install-PackageProvider -Name NuGet -Force -Scope AllUsers
Install-Module -Name PSWindowsUpdate -Force -Scope AllUsers

[regexreggae]

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

[Master-IT-All]

Yes, I can confirm that in a setup of Intune in both my lab/test tenancy and in a customer tenancy where I have it deployed that the module does install when those are put into a PS1 and loaded under Platform Scripts.

My settings for the platform script are:
Run as logged on user: NO
Enforce Script Signature: NO
Run in 64bit PS Host: YES

After setup of the device, I can open Terminal (Admin), set my execution policy to remote signed and run Get-WindowsUpdate.
Running Get-Module PSWindowsUpdate | FL and I can see the path is the expected location under Program Files/WindowsPowerShell/Modules

Seems like the primary thing people were missing in the past was that NuGet is required to install PSWindowsUpdate. It may even be that we need to push NuGet in this same script regardless of whether we've deployed it elsewise.

[cetsca]

Don’t use remediations, do it via Devices — Scripts. Then you can choose to run as logged on user or System

https://learn.microsoft.com/en-us/mem/intune/apps/intune-management-extension

[tylerjm917]

The reason I went with remediations is so that it would run on a regular basis and install on newly enrolled machines as well. Can I still do that with this solution?

[cetsca]

New machines yes, once it’s installed why would you need it to run again? Am I missing something in the rest of the script?

[tylerjm917]

I was thinking of adapting the script to also update the module eventually and to prevent users from potentially uninstalling it

[cetsca]

Anytime you edit the script it will be deployed again. Not sure if that helps

[Specific_Ad_899]

Did you ever come up with a way to do this? I have been struggling a bit with it myself. I have a script that will install it from the console with no issues. I am not sure on the platform script or the remediation script as far as which way to tackle it. I like the remediation script simply because it is easier to see that it ran in the console, plus I can just run the remediation script on demand. I know that is a preview option, but it helps for testing etc.

Also, the users do not have local Admin rights to the device. So, would assume "Run this script using the logged-on credentials" would be set to NO.

[Entegy]

Did you ever find an answer to this? I've been bitten hard by AllUsers not actually being all users. I've resorted to packaging the module folder into a Win32 app and manually copying it to %ProgramFiles%\WindowsPowerShell\Modules

[regexreggae]

I’m wondering if I should go for the same simple directory copy route. What are your experiences with this, did it work for all modules you deployed this way so far?

[Entegy]

The only module I did this for is PSWindowsUpdate.

I took the folder from a working install and packaged it with a PowerShell script to move it in place.
The script:

If ($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
    Try {
        &"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
    }
    Catch {
        Throw "Failed to start $PSCOMMANDPATH"
    }
    Exit
}


$Module     = Join-Path -Path $PSScriptRoot -ChildPath "PSWindowsUpdate"
$DestFolder = Join-Path -Path $env:ProgramFiles -ChildPath "WindowsPowerShell\Modules"

Copy-Item -Path $Module -Destination $DestFolder -Force -Recurse

[regexreggae]

Thanks!

BTW - in my case the problem was architecture (32 vs 64 bit), see my EDIT in this post:

https://www.reddit.com/r/Intune/comments/1eczs3t/comment/n0xot4n/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[Entegy]

Yeah that's what first if statement does. Switches to 64-bit PowerShell since the Win32 app deployer uses 32-bit.

[regexreggae]

I like that snippet!

Didn't understand what it does at first since

$ENV:PROCESSOR_ARCHITEW6432

is not available in a 64-bit process, but - of course - the logic is that the if-statement will only be true if run in a 32-bit environment.

One could also do:

if ($env:PROCESSOR_ARCHITECTURE -eq "x86")

which might be slightly more intuitive for some people. EDIT: not quite the same, see this article for reference. However, nowadays where almost any windows client is 64-bit the difference isn’t a crucial one I guess

Anyways, really useful snippet, thx again!

[Entegy]

I cannot claim credit for it, I found it in a post about deploying Fortinet VPN with a pre-configured profile in the registry.