Robert runs into a strange issue where his Win32 Intune PowerShell scripts were not creating registry keys in the right place – found out how he resolved the issue.
Let me set the scene initially by saying that I have been doing a lot of work with Intune and deploying applications over the last 6 months. Everything had been going really well, until that is I ran into a rather peculiar issue.
Where the heck is my REGKEY?! 😕
Yep you read it right, but again let me go back to what the actual problem is here.
Going back a few months, I spent quite a bit of time writing a custom PowerShell wrapper script which contains loads of useful functions that I reuse for a lot of application set ups and installs. Mainly it handles error logging nicely, but it does some other nice things as well (there may be another blog post on that, so keep watch!). So if for example I want to install some software that uses an MSI, I use a PowerShell script which calls my wrapper script and it logs the status out to a .txt file in a logs directory (which I have to say is super useful) – but (and I am getting to the point!) I had a few scripts where it would modify the registry, but it didn’t appear to be working in that the registry key never seemed to get created.
I checked the logs, and sure enough it said that everything was working:
I opened the registry, and went to check to see if I could find the registry key path for HKLM\SOFTWARE\Italik\Apps and it was nowhere to be seen!
OK I thought, maybe it is an issue with the actual script not reporting the status correctly. I then modified the script which would then check if the registry key HKLM\SOFTWARE\Italik\Apps exists, which it said it did:
Say what?! OK, now I am super confused! I must have spent 5-6 hours banging my head on a brick wall, and I don’t think I was searching for the right thing on Google as I couldn’t find any answer to my problem (except for maybe Google saying, “are you going crazy?!”).
I then started writing another script today, and ran into the same problem I had a few months back where it wasn’t creating the registry key correctly aaaargh 😡!
All we need is a little “perspective”… 🤔
OK, after taking a step back and thinking a bit more I tried to look at what was the common factor between the two scripts that were not creating the registry keys correctly:
- They were both PowerShell scripts that were attempting to modify the registry
- Both scripts were Win32 Windows Apps
- Both scripts were installing as the “system” rather than the user
Hmmm… OK; I wonder if the system context user is doing something weird here? Again, I checked a few things in my test lab and couldn’t find anything untoward. I then turned to Google again, and searched for the right thing this time!
I then found this really great blog post by Nathan Ziehnert, or AKA Z-NERD and full credit to him for the provided PowerShell script which I think has now finally made me sane again!: https://z-nerd.com/blog/2020/03/31-intune-win32-apps-powershell-script-installer
To summarise the issue I was seeing was that because I was running the script using the Intune Win32 app deployment it was running PowerShell as a 32-bit app and was therefore creating registry keys under the WOW6432Node registry key!
I never considered it would do that, and I never realised that the Intune application installer engine runs as a 32-bit application and due to that it runs PowerShell in a 32-bit context.
OK, so how do we get Intune to run PowerShell as a 64-bit app ❓
It is pretty easy, but Z-NERD has provided a great PowerShell script that is a modified version of Peter van der Woude’s original (original script can be found here: https://www.petervanderwoude.nl/post/using-the-intune-management-extension-on-a-64-bit-platform-for-a-very-happy-new-year/)
If you look on Z-NERD’s blog, he has posted his script on there and it basically allows you to run your PowerShell scripts in the 64-bit context simply by running the 64-bit version of PowerShell. But just in case the script is not available, here is a copy of that script:
| # Many thanks to Z-NERD for this, and this script is a copy of the one provided on his website | |
| # Here is a link to the original script: https://z-nerd.com/blog/2020/03/31-intune-win32-apps-powershell-script-installer/ | |
| # This is here just in case the post gets removed/lost 🙂 | |
| $argsString = “” | |
| If ($ENV:PROCESSOR_ARCHITEW6432 -eq “AMD64”) { | |
| Try { | |
| foreach($k in $MyInvocation.BoundParameters.keys) | |
| { | |
| switch($MyInvocation.BoundParameters[$k].GetType().Name) | |
| { | |
| “SwitchParameter” {if($MyInvocation.BoundParameters[$k].IsPresent) { $argsString += “-$k ” } } | |
| “String” { $argsString += “-$k `”$($MyInvocation.BoundParameters[$k])`” ” } | |
| “Int32” { $argsString += “-$k $($MyInvocation.BoundParameters[$k]) ” } | |
| “Boolean” { $argsString += “-$k `$$($MyInvocation.BoundParameters[$k]) ” } | |
| } | |
| } | |
| Start-Process -FilePath “$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe” -ArgumentList “-File `”$($PSScriptRoot)\Install.ps1`” $($argsString)” -Wait -NoNewWindow | |
| } | |
| Catch { | |
| Throw “Failed to start 64-bit PowerShell” | |
| } | |
| Exit | |
| } |
view rawintuneps-x64.ps1 hosted with ❤ by GitHub
Once I incorporated this into my Win32 app on Intune, it then ran PowerShell as a 64-bit process and my registry keys finally got created in the right place:
Success at last 🥳🥳🥳
Again a massive thank you to Nathan Ziehnert (or Z-NERD) for providing a lot of detail within his blog post and for posting a really useful script to be able to resolve the issue. 🙏