Let’s start the New Year with a quick tip about the Intune Management Extension, which is used for running PowerShell scripts, in combination with a 64-bit platform. The Intune Management Extension is 32-bit and will run PowerShell scripts in a 32-bit environment. This is not always the desired behavior. Actually, many activities and/or cmdlets, require a 64-bit environment. In this blog post I’ll provide a simple workaround, to run the PowerShell scripts in a 64-bit environment, and I’ll show the behavior of that simple workaround.
The (example) script
Now let’s start by looking at that simple workaround. That workaround is actually a simple addition to a script that starts the same script, by using the 64-bit environment of PowerShell. This is achieved by starting with the following assumptions:
- The script doesn’t have to deal with parameters – This saves me from doing difficult with providing parameters to it;
- The script should only switch on a 64-bit platform running a 32-bit process – This makes sure that it won’t break on a 32-bit platform. That can be achieved by using $ENV:PROCESSOR_ARCHITEW643. That environment variable is set when running a 32-bit process on a 64-bit platform;
- The script needs the right location of PowerShell – This makes sure that this time the 64-bit environment of PowerShell will be started. That can be achieved by using SysNative. That alias is used to point a 32-bit process to C:\Windows\System32;
- The script needs the right location of the script – This makes sure that the same script is started again. That can be achieved by using $PSCOMMANDPATH. That automatic variable contains the full path and file name of the script that is being run.
These four assumptions bring me to the following small script snippet that can be added to the top of any script. For looking at the results, I’ve added an additional line at the beginning and the ending of the script snippet. Those additional lines write the environment of the process to a file.
“Begin: $ENV:PROCESSOR_ARCHITECTURE” >> “C:\Windows\Temp\Test.txt”
If ($ENV:PROCESSOR_ARCHITEW6432 -eq “AMD64”) {
Try {
&”$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe” -File $PSCOMMANDPATH
}
Catch {
Throw “Failed to start $PSCOMMANDPATH”
}
Exit
}
“End: $ENV:PROCESSOR_ARCHITECTURE” >> “C:\Windows\Temp\Test.txt”
Important: The Intune Management Extension will only report over the initial script. To also report over the newly started script, you might want to look into building something smart that will monitor the newly start script before exiting the initial script. The example above simply exits the initial script.
The (example) results
Let’s end this post by looking at the example script, mentioned above, when deployed via Microsoft Intune. The example script writes, at the beginning and the ending, an entry to a file named Test.txt. After a successful execution, it contains the following three entries:
The first entry is related to the beginning of the initial script, which is triggered by the Intune Management Extension. At that moment it’s started as a 32-bit process;- The second entry is related to the beginning of the newly started version of the script, which is triggered by the initial script. At that moment it’s started as a 64-bit process;
- The third entry is related to the ending of the newly started version of the script. At that moment it successfully went through the complete script as a 64-bit process.
More information
For more information about automatic variables in PowerShell, refer to the documentation About Automatic Variables.
Hi Peter,
So in my previous post I meantioned ‘new-localuser’ was not recognized.
Does this mean I can use your sniplet like below in a script (sorry my scripting is bad)
If ($ENV:PROCESSOR_ARCHITEW6432 -eq “AMD64”) {
Try {
&”$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe” new-local user “Peter”
}
Catch {
Throw “Failed to start”
}
Exit
}
Hi RKast,
No, not like that. Just leave the if-statement as-is and add anything you need to perform below the if-statement. The if-statement simply starts the same script again (and exits the old script), but then in a 64-bit environment.
Regards, Peter
Hi Peter,
Thanks for you prompt reply, I understand now 🙂
If i’m correct just add the command below the last line like below.
If ($ENV:PROCESSOR_ARCHITEW6432 -eq “AMD64”) {
Try {
&”$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe” -File $PSCOMMANDPATH
}
Catch {
Throw “Failed to start $PSCOMMANDPATH”
}
Exit
}
New-LocalUser “Peter”
That’s it, RKast!
Why wont my virtual Azure joined 1709 machine get the Intune Management Extension installed?
I’ve created a helloworld.ps1 user script and assigned it to users but the extension never gets installed, the eventlog doesn’t show errors.
Hi Steffen,
The Intune Management Extension should automatically install, once a PowerShell script is assigned.
Regards, Peter
Hi Peter,
Yeah I know, but it just doesn’t get installed. I have as mentioned a simple script attached to the user and also had a script for the machine, but that is no longer active. neither one of them kicked off the install. It’s a virtual machine, and I can see many of the other policies I have beeing applied.
Hi Steffen,
If the installation is triggered you should see more information in the Event Viewer (Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin), or a log file at C:\Windows\System32\config\systemprofile\AppData\Local\mdm\
Regards, Peter
Hi Peter,
I’m also seeing the behaviour described by Steffan. A device managed by InTune, where other InTune functions work correctly (install Office 365 ProPlus for example), however even with a Powershell script assigned, the InTune Management Extension just never installs.
Hi Ben,
Does it never install, or does it initially take a long time?
Regards, Peter
Hi Peter,
I managed to sort it out. I had manually enrolled my test devices early on since they weren’t automatically enrolling in MDM. After reviewing with a MSFT Tech I realised that automatic enrollment was the key. I guess it pays to read things more thoroughly, from the start in some cases.
https://github.com/MicrosoftDocs/IntuneDocs/issues/1238#issuecomment-404659889
Good to hear, Ben. Thanks for lettings us know!
Hi,
2 questions hope you can and will answer.
1) can we deploy PS script to computers?
2) if we deploy script1 to userA and he logs in on computer1 the script1 will run. But what happens if userA logs in o computer2 will the script also be runned on computer2 ?
Hi CU,
You can only assign PowerShell scripts to user groups at this moment.
Regards, Peter