GlobalProtect client not consistent

[BruceBennett]

I am building out a test environment using GP as always-on/prelogon. The issue that I am seeing is that one test user, this seems to work fine and another test user it does not. Both users are running the same PC type and same Windows 10 updates into the same AD environment for in office authentication. Current GP version 4.1.12 (I am trying to resolve this issue before updating to GP 5.0.x, that update is going to be a test against the locked down nature of the PCs in the environment).

PC 1: Once logged into Windows, GP uses Windows SSO and authenticates to the portal/gateway and the PC is on-net.

PC 2: Once logged into Windows, GP pops up a window with the user account listed but requires a password to continue with the authentication. 

I am not sure where to look to see what the difference in how GP is functioning on the two PCs. I feel like I have gone through the systems logs thoroughly, but I must be missing something since both PCs are functioning differently.

[Remo]

I assume on PC1 the user clicked the global protect login option on the windows logon screen while the user on PC2 has not done that. For SSO to work ypu have to use the GP login option. This can also be forced by AD group policy.

[BruceBennett]

@Remo 

That is a good question, because I don't see "the global protect login option on the windows logon screen". Looking at the windows login screen from both PCs, PC1 does show a "GlobalProtect Status:", while PC2 does not. I do not remember taking any different steps between the two PCs, but definitely does stand out as a difference between the two. I thought that part of the configuration was pushed down from the portal configuration, so I am obviously missing a step or something on PC2.

My goal is to be able to push this down to the users with the least amount of interaction possible.