09-04-2026 06:26 PM
Can someone at PAN explain the design decision here?
The GlobalProtect portal exposes an impressive collection of settings—some useful, some spectacularly niche. The MSI also accepts enough properties to make deployment engineering its own part-time job. Yet enabling Connect Before Logon/PLAP somehow requires administrators to run this separately on every endpoint:
PanGPS.exe -registerplap
There is apparently no documented MSI property, no portal Agent setting, and no checkbox during installation. Just a privileged, post-install command that customers are expected to discover and then deploy separately.
This is especially baffling because PLAP is precisely the kind of feature enterprises need to deploy centrally. Its entire purpose is to help remote users establish connectivity from the Windows sign-in screen—often because they changed their domain password elsewhere and can no longer sign in with cached credentials. At that point, asking us to bolt a custom registration script onto the installation feels less like enterprise management and more like an Easter egg hunt.
Meanwhile, the installer has historically been quite enthusiastic about installing the regular SSO credential provider unless explicitly told not to. So the component we don’t want touching the Windows sign-in experience gets an MSI option, while the narrowly scoped Network Sign-In provider we do want requires an undocumented-looking command-line ritual afterward.
For 2000+ endpoints, “just run -registerplap” is not a deployment strategy. Yes, we can build a SYSTEM-context remediation script, check the registry, run the command, verify it, log the result, and wait for a reboot. We can also write our own installer if sufficiently provoked. The question is why customers should need to manufacture lifecycle management for a supported GlobalProtect feature.
Could PAN please add at least one of the following?
A documented MSI property such as REGISTERPLAP=YES.
A Portal Agent setting that instructs PanGPS to register PLAP locally.
A supported deployment option that registers PLAP while explicitly leaving the standard SSO credential provider disabled.
Proper detection, remediation, and removal documentation for enterprise deployments.
GlobalProtect already has centralized configuration and an enterprise installer. Making PLAP centrally deployable seems like it should have been part of the feature—not a scavenger hunt left to every customer with more than one computer.
