Forum Discussion
Win32 App Powershell 64bit registry access issue
Hi,
Please take a look at
Sysnative | Intune | 64 VS 32 Bits | Registry Keys (call4cloud.nl)What happens when you run a script with setting this option to yes instead of no
Hi, thank you for the links, however i have read those articles already.
And as i wrote, SysNative directory is not present Windows 10 anymore.
I cannot use a Powershell script as it is not bringing any files for installation an cannot be published for the user to install.
However i have tested the script to be run in 64 bit host and it correctly created the key and value.
I cannot use the script as a dependency for a win32 app however.
Hi,
You could create something like this and convert it (with the msi) to a intunewin file
Just like i I did with a win32 app to disable the oobe stage (for when you don't use autopilot)
:
https://call4cloud.nl/2020/10/the-curious-cage-of-hiding-the-oobe-stage/
I uploaded the app just a few seconds ago,first I need to spin up a clean windows 10 test vm. I will let you know the outcome. UPDATE 14:05: The registry keys were succefully created. Of course, I skipped the msi part but I this something you could use?
-----
$content = @'
$flexreg = (Get-ItemProperty "HKLM:\Software\FLEXlm License Manager").SW_D_LICENSE_FILE
#Start-Process -Wait -NoNewWindow "msiexec" -ArgumentList "/i","$pwd\DraftSight.msi","/qb","LICENSETYPE=3"
if (!$flexreg) {
New-Item -Path "HKLM:\Software" -Name "FLEXlm License Manager" -Force
New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value 'portnr@servername' -PropertyType STRING -Force
} elseif ($flexreg -like '*portnr@servername*') {
Exit
} else {
New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value $flexreg';portnr@servername' -PropertyType STRING -Force
}
'@
Out-File -FilePath $(Join-Path $env:ProgramData CustomScripts\testreg.ps1) -Encoding unicode -Force -InputObject $content -Confirm:$false
# register script as scheduled task
$Time = New-ScheduledTaskTrigger -AtLogOn
$User = "SYSTEM"
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\ProgramData\CustomScripts\testreg.ps1`" -Verb RunAs"
Register-ScheduledTask -TaskName "testreg" -Trigger $Time -User $User -Action $Action -Force
Start-ScheduledTask -TaskName "testreg"
- Woah. So you pack the script to a file, register a Scheduled task and execute it so that a new instance is executed in 64 bit. Is task scheduler using %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe due to system default?
This is quite a stretch to get it working. Registering a scheduled task for each powershell installation that needs to work with registry and cleanup the scheduled task (with detection script for example)
Don't take me wrong you seem to have a workaround, but its quite complicated.
But you gave me an idea. i have to test to call %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe from a batch file with start command.- Hi
Yes it's a little bit complicated... I just used this script which I had to control the oobe settings before the user logged on. Maybe it could be a little bit stripped down but it does the job 🙂 . The schedule part was meant for scheduling 🙂- If the schedule part is only for scheduling, i do not understand how can i use it without it, to go around the problem of starting powershell in 64 bit mode to access the registry. Could you please explain?
