I have something to add to the thread. I sync'd the clocks on two laptops (to at least the second). I then used one laptop to monitor when I acknowledged our Legal "We're Watching You" dialog box, and then used the Event Viewer to determine when the "McAfee Endpoint Encryption Agent" service started. In all cases where I can reproduce SSO failing, the service is starting after I login (by a few seconds). In all cases when SSO is working, I've waited until the second computer sees that the service on the first computer has started.
I then verified that this service was required for SSO by stopping it, then locking and unlocking my computer. The unlock was done by McAfee, but I can see it starting the service. I then disabled the service and locked/unlocked and verified that it could not start the service (it's disabled) and I was presented with the Windows 7 logon screen instead of the McAfee logon screen, as I'd expect.
So - this may go beyond traditional Community support (I have a ticket open, this info has been added to it), but anyone know why this service is not starting up as quickly as it should, or at least why it's not developed in such a way that Windows waits for this service before starting the logon process and going through the Credential Providers?
Excellent bit of detective work that confirms there is a problem with the CP starting / waiting for the EEAgent service to start - at least at first logon (in your test, the CP started it OK at unlock). To answer one of your questions, it has been developed so that the CP should wait until it can talk with the EEAgent - in fact, because of this you will find many threads on the forum where people are experiencing a delay at logon because the Windows Service Control Manager is taking a long time to start the EEAgent service - and the CP waits for it.
The question of course is why this is not happening for you. You mention you have a 'legal' logon message before the logon... is it possible to disable that for a test to see if it is in any way involved?
It's not as simple as a delay - the CP starts (if necessary), queries and waits for positive confirmation that the EEAgent service is up and running and available to talk to... at least when it's working
1. Have you using "samaccountname" atribute in AD users synchronization task in fields: user name and display name?
2. Have you tried disabling "Require Endpoint Encryption logon" - just this one?
According to note for solution 1 in KB71003 it is better to have both fileds filled with samAccountName attribute. From my experience I know that there maybe problems with activation or SSO if these values are different (I had such support case). I know that they are not required by documentation, but it is better to have them configured to the same value.
Second thing where you got information that this option ("Require Endpoint Encryption logon") is required for SSO in Windows 7. I have machines with working SSO with this option disabled. From my expirience it is used for locking/unlocking machine.
And also my personal best practise is to disable EEPC password history if SSO and enable password change prevent option. If you using SSO then leaving default values on these option can lead to unnecesary user confusion and password desynchronization, also if you using SSO these option are realy not needed.