Powershell snapin and registry
- FOG Version: 1.5.0
- OS: Debian 9.4
- Service Version: 0.11.15
- OS: Windows 7, 8.1 and 10 LTSB
I created a script to uninstall AVG Protection and then install Trend Agent Security. The script works perfectly in a Powershell window. By snapin, line 10 does not work. Do you have an idea ?
To see the script (sorry for french comment) : https://framagit.org/alexandre.LG/shared_on_inios/blob/8c62e0f109a5948e0d064cc9f17928922d17c208/deployTrendSecurityAgent.ps1
Thanks in advance for your help.
@tom-elliott Ah. I haven’t yet ever found a need to run x86 powershell on x64 machine.
@szeraax I meant you wanting, for some reason, to run a 32 bit powershell script from a 64 bit instance.
@tom-elliott Powershell as of… a year or two ago VASTLY prefers to be run in the system native bitness. Hence, we had all those issues when I was trying to Import-Module for stuff that was on the system, but available only to the 64bit version of powershell. I doubt that you would have ANY problems from powershell if client were to auto-target either.
@szeraax I doubt it. 32 bit installers usually have no issue installing in 64 bit systems, as you the the fog client installs and runs just fine, mostly, in 32 bit mode. You might run into issues using powershell or some scripts that might require a pure 32 bit mode but I can’t think of one that is that specific currently.
@joe-schmitt If you made it auto-target 64, would that potentially break people who use it to install 32bit programs?
@Szeraax the client itself is actually already 64 bit compatible. It gets installed as 32 bit because the
msitargets 32 bit. I suppose going forward I could either make 2 different installers (one for each architecture) or build a single installer that can target either.
@joe-schmitt Good point. 32bit client is having to escape the normal system. 64 bit client would use powershell.exe and get the correct one by default. Anything us plebs can do to help get a 64bit client out?
@Szeraax is correct. We do provide Snapin templates for both
Powershell 64 bitfor this reason. Eventually when we allow the client to install as 64 bit on machines, then this problem won’t exist.
@aruhuno I think that the problem is that if we just always use that path, then all x86 installations would fail (I don’t believe that a 32bit machine has a sysnative folder). If we put in a check that will attempt to use the 64 bit powershell if its running on a 64 bit machine, I think that would be good. For now, I just plan to use that path instead of powershell.exe.
It works with
Why FOG don’t use by default this path?
Thanks a lot for your help!
edit: can you mark the post from Joe as solution please?
@aruhuno the native path does exist, it’s just not tab accessible. Unless of course powershell isn’t installed I suppose.
My apologies for my absence.
I think you put your finger on the problem.
AVG don’t remove this key.
%WINDIR%\sysnative\windowspowershell\v1.0\powershell.exedoes not exist.
I test with
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exebut not working…
@aruhuno one more thought:
The client runs as 32 bit, so it launches a 32 bit powershell and thus registry paths are their 32 bit versions. (The same registry path run under 32 and 64 bit will sometimes be different).
I’d try setting the
Snapin Run Withto
%WINDIR%\sysnative\windowspowershell\v1.0\powershell.exeas that will launch your script in a 64 bit process.
Thread about 64 bit powershell snapins: https://forums.fogproject.org/topic/11628/snapin-template-powershell-cannot-load-modules-is-this-normal
Regarding the error at line 10, perhaps the reg key was already removed by the avg uninstall command at line 4, but I can’t see why it would be different in a window.
Also for line 25 to work, the “domain name\domain computers” group will need read and execute access to "\naswin\deploiement$"
From experience, calling msiexec under the system account can sometimes fail if you don’t have "ALLUSERS = 2 " in the arguments, it depends on the msi.
Wayne Workman last edited by
@aruhuno Typically this is because when ran manually, you are running the script as Administrator, but when the FOG Client runs the script, it runs the script as SYSTEM. There are limitations on what SYSTEM can do, this is by design of Microsoft for security related reasons. To figure out what’s wrong, I’d suggest redirecting the output for those lines to a log file, maybe it’ll reveal the error.