Powershell snapin and registry

[aruhuno]

Server

• FOG Version: 1.5.0
• OS: Debian 9.4

Client

• Service Version: 0.11.15
• OS: Windows 7, 8.1 and 10 LTSB

Description

Hello,

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.

[Joe Schmitt]

@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 With to %WINDIR%\sysnative\windowspowershell\v1.0\powershell.exe as 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

[Wayne Workman]

@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.

[jbsclm]

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.

[Joe Schmitt]

@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 With to %WINDIR%\sysnative\windowspowershell\v1.0\powershell.exe as 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

[aruhuno]

My apologies for my absence.

@Wayne-Workman
I think you put your finger on the problem.

@jbsclm
AVG don’t remove this key.

@joe-schmitt
%WINDIR%\sysnative\windowspowershell\v1.0\powershell.exe does not exist.
I test with %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe but not working…

[Tom Elliott]

@aruhuno the native path does exist, it’s just not tab accessible. Unless of course powershell isn’t installed I suppose.

[aruhuno]

It works with %WINDIR%\sysnative\windowspowershell\v1.0\powershell.exe!
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?

[Szeraax]

@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.

[Joe Schmitt]

@Szeraax is correct. We do provide Snapin templates for both Powershell and Powershell 64 bit for this reason. Eventually when we allow the client to install as 64 bit on machines, then this problem won’t exist.

[Szeraax]

@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?

[Joe Schmitt]

@Szeraax the client itself is actually already 64 bit compatible. It gets installed as 32 bit because the msi targets 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.

[Szeraax]

@joe-schmitt If you made it auto-target 64, would that potentially break people who use it to install 32bit programs?

[Tom Elliott]

@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.

[Szeraax]

@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.

[Tom Elliott]

@szeraax I meant you wanting, for some reason, to run a 32 bit powershell script from a 64 bit instance.

[Szeraax]

@tom-elliott Ah. I haven’t yet ever found a need to run x86 powershell on x64 machine.