Pushed the global protect client out through SCCM. Which works, but when the auto update is applied, we end up with the windows installer issue. the msiexec /Option error
I have checked to make sure no other installer is running, and there is nothing.
Has anyone been able to solve this issue?
Could you post the actual issue that you are running into? Generally with an application like GlobalProtect, we use a detection rule so that Software Center doesn't try and enforce a set version of GlobalProtect or Traps. That way you can do upgrades through the application itself without causing any install issues.
We have a detection rule in SCCM, which works well. Here is what i have discovered.
1. Push software during image with SCCM. eg. 5.0.1
2. Network engineer then ticks the box on the Palo to auto update
3. The laptop client detects there is a newer version being pushed out through the Palo
4. The old version is uninstalled as per the update_tmp.bat
5. Laptop then tries to install the new version from the palo.
6. The user receives the error of Windows Installer is missing parameters, or another install is running.
If you find where the new version installed, you can install it manually.
If i download the latest version, and push through SCCM it works.
So the problem is not with SCCM itself, it is the auto update that is pushed through the Palo. It won't update, if the initial install was through SCCM.
If you do the initial install through Palo, the update works
Palo Install -> Palo Update = Works
SCCM Install -> SCCM Update = Works
Palo Install -> SCCM Update Works
SCCM Install -> Palo Update = Not Work
There seems to be a problem with the uninstall -> install new version. I tried changing the update_tmp, but when you download the new version, it overwrites the bat file.
Do you change any parameters when you install via SCCM, because you can't modify that path and still expect the updates to function when pushed through the firewall. Left to it's own devices, installing the MSI through SCCM and performing future updates through the firewall itself 100% functions as intended across all of the environments that I manage, so that process in and of itself is not an issue.
This is the installation program with the parameters through SCCM
msiexec /i "globalprotect.msi" /q Portal="portal1" Portal="portal2" CONNECTMETHOD=”on-demand"
I even tried with:
msiexec /i "globalprotect.msi"
with the same issue.
Do i need to match every parameter that is set in the Palo?
Start-Process .\GlobalProtect64-5.0.4.msi -wait -ArgumentList '/q' Set-ItemProperty -Path "HKLM:\SOFTWARE\Palo Alto Networks\GlobalProtect\PanSetup" -Name "Portal" -Value "portal.mycompany.com"
The above PowerShell install script works flawlessly and works when upgrading the client from the the firewall itself. The registry key you are creating is simply what the agent actually reads to set the portal address.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!