Anyone else seeing User-ID fail on some Win11 devices post-22H2? Our Palo Alto NGFW (PAN-OS 10.2) is missing specific engineering workstations. Agent shows "connected" but no user mapping.
* GP agent 6.1.x deployed via SCCM
* Firewall rules correctly using user-ID groups
* Traffic logs show IP but user is 'unknown'
Checked the obvious: agent logs, firewall User-ID agent status, no overlapping IPs. What's the actual ROI on troubleshooting this versus a scripted workaround? Leaning towards a local logon script as a stopgap.
—CR
Ask me about hidden egress costs.
Ah, the classic "agent says connected but the firewall says who dis?" scenario.
Scripted workaround is tempting, but you're just papering over the real problem, which is probably a WMI or registry permissions issue on those specific workstations. Seen it a dozen times with locked-down engineering images. That logon script will break the second they push a new security baseline.
Have you checked if those machines are missing the specific registry key the agent polls? HKLMSOFTWAREPalo Alto NetworksUser-ID AgentStatus. Sometimes the GP agent installs but the service can't write to it.
been there, migrated that
Your cost-benefit question is valid. A scripted workaround will create a secondary data source you'll need to maintain and reconcile, introducing technical debt. The missing mapping on specific engineering workstations suggests a systemic issue with the agent's data collection method on those images.
I'd examine the data flow before resorting to a script. The agent polls WMI for logged-on users. On locked-down workstations, the agent's service account often lacks the necessary permissions to query the `Win32_ComputerSystem` or `Win32_LogonSession` classes. Check the security filtering on your SCCM deployment; it might be installing under a context that lacks these permissions at runtime.
Have you compared the effective permissions on the WMI namespace `rootCIMV2` between a functioning workstation and a broken one? That's usually where the discrepancy lies.
Data doesn't lie, but folks sometimes do.
Totally agree on the WMI permissions angle, that's often the culprit on locked-down systems. It's easy to miss because the install succeeds but the runtime context fails.
One extra thing I've seen, especially with engineering VMs, is a group policy blocking remote WMI queries entirely, which breaks the local agent's own calls. Even a local logon script would hit that wall.
Have you tried running a `wbemtest` on a broken workstation to see if the default namespace is even accessible? That's saved me a few hours of guesswork.
Happy customers, happy life.