I’m curious if anyone else deploys the Globalprotect client via Microsoft Intune/Endpoint. I am able to deploy the client on its own no problem, but I run into issues when I need to update the GP version.
The way Intune works is I assign the app to a group of users or devices, and it goes and auto installs to the scoped users/devices. It’s super handy for new hires as GP is already installed and ready when they login to their new PC. However, if I then unassign the user/device from the app, it uninstalls the software.
This is troublesome with the way Globalprotect updates itself. When I activate the new GP version on the Palo itself, any subsequent connection attempts are prompted that a new version is available and gives an option to download and install.
The tricky part is, Intune will still be pushing that old version to the PC and it will install again, leaving the user with two different GP versions. And again, I can’t unscope the old GP version without it fully uninstalling itself, forcing users to manually get the download from the GP portal.
I think if I unscope the install at the same time that I activate the new GP version, then immediately create a new install package with the new GP version it can work, but that requires lots of precise timing for the user to not have GP uninstalled while they are in the middle of working.
I think the answer is just don’t deploy GP with Intune, but I’m curious if anyone else does so successfully and how you handle updates.
IIRC, there is a setting in Intune to ignore the version, this would address the issue of Intune pushing out the older version when updated manually. Use this setting to deploy my RMM tool, but it then keeps itself updated.
Otherwise, why not just update the Intune package vs removing/re-adding user scopes?
If you’re using Intune you need to use it fully. Don’t try and use multiple platforms to control the same app. Use Intune to push updates by created a new app with the later version and setting it to supersede the previous version.
You don’t update the version on the Palo’s really ever as there is no point. Do all your GP version management in Intune and then it’ll work fine
Definitely watching. Our NOC team is requesting upgrades to 6.0.7 next week and this is our first GP using Intune. I discovered GlobalProtect in our PatchMyPC list of supported apps last week so this would make things so much easier if testing goes smooth this week.
I guess I glossed over that ignore version setting, I will give that a try next time. I also just realized that on the “Edit application” page in Intune, the name of the MSI file is a hyperlink that allows you to replace the file.
Intune just feels so rudimentary, it’s like cloud Group Policy. Coming from using PDQ Deploy for years, I feel like I have no insight as to what is actually done on the machine and when.
So with the ignore version set to “Yes” it only installs the software one time when the machine is initially Azure joined and never again, unless it detects the application completely missing?
Yeah Intune itself works pretty well for general deployment purposes but I have done 3 or 4 GP “upgrades” now with it, trying different orders of operation and not found a clean way to do so yet. Each time I’ve had users who had their VPN connection rug pulled on them.
The most recent upgrade I went in the following order. Activate new GP version on the Palo Friday evening. Early Monday morning I delete the old GP Intune package and make a new one with the desired GP version, scope it to the users.
This produced a terribly undesirable result on my machine and others. The uninstall (or new GP install, I’m not sure) caused my Win11 machine to restart with zero warning. Out of nowhere it said “Restarting” with the spinning and then did so.
When I was back up I had the new GP version which is nice, but that is not the way I want an upgrade to go.
That setting should install the software if it doesn’t detect it already being installed, which I believe you can customize the detection settings as well.
It doesn’t just run on AzureAD join, but continuously (based on Intunes logic/timing) on new/existing machines, so if you push a new rule out to existing machines, or a user removes the software, it will get installed.
Why do you need to delete the old package? Intune has supercedence that has worked for us at least pretty well.
To avoid clients getting restarted without warning we are using /qn /norestart with device restart behaviour “Determine behavior based on return codes”. In the deployment we also have “Restart grace period” configured