I have a situation where the simple act of enabling SSO in a in the policy of a system, causes that systems boot process to seemingly "pause" on a blank screen (well, blue background screen) for over 2 minutes in my "lab", and reportedly up to 5 minutes in our pilot user group. Turning off SSO results in a 5-second pause on this same screen.
I have tried many variables to determine what is causing this specifically... one of which was enabling the option to allow the user to cancel SSO - which provides an option at the pre-boot login page to disable SSO. IN this case, the delay of about 2:00 still happened - regardless of the choice of using SSO during that individual boot.
This has led me to the assumption that it is the modifications made to the Windows install when the SSO policy is enabled that is causing this issue. I am hoping that there may be a list somewhere, either by McAfee or by a veteran user, that would outline the changes made when SSO is enabled. The only one I know is that the msgina.dll is put aside and the system is configured to use the epepcgina.dll, located in the "%program files%\McAfee\Endpoint Encryption for PC v6\" folder.
I tried one quick thing - and copied that dll to the windows\system32 and re-pointed the windows registry to that location.... my thought was that putting system files in a folder that is not named within the standard 8.3 naming may be a bit of an issue.... I was incorrect. There was no change to the delay.
I am hoping this is not simply a gina issue, and may be something I can actually fix!
I know in our pilot deployment of 50 people, many have found this issue... but some have not. I am hoping I can track down the cause so at least I can have a fix for this unacceptable condition.
For the record, I am using:
- ePO 4.5 Management Console on Win2003
- WindowsXP SP3 running McAfee Agent 22.214.171.1249
+ MEE Agent 1.0.2
+ EEPC 6.0.2
+ VSE 126.96.36.1990
As part of my continued attempts to diagnose this (McAfee support is less than helpful so far), I have found that an upgrade to AV to the new 8.8 has reduced my boot delay to just under 1 minute on that same blank screen. Still a long way from the 5 seconds when I disable SSO, but there was obviously something not interacting well between the AV 8.7 and the EEPC SSO. Hopefully this is "my" issue (i.e: something weird on my domain, etc) and not just that the products don't work well together.
If I can get the delay further reduced, I will post again. The McAfee Support person noted that there is a normal delay on SSO... which I can understand a slight one, but any more than a couple of seconds more than what I would see without SSO seems odd and excessive.
A 1 minute "pause" is still a show-stopper for my users and will result in non-deployment, and disabling SSO is also not an option. If either of these things fail, the next step is product replacement.
At what point does this pause take place? Right after pre-boot login, after Windows Splash Screen, after startup scripts? I have about 45 machines running on Windows XP Pro SP3 with EEPC 6.0.2 and do not have this pause on any machines, that I know of.
The problem is that Windows usually lets you login well before all the misc drives have loaded. BUT it won't let a third party GINA start until all the drivers are done, because there may be some dependencies etc.
This is most noticiable when dealing with a machine built from an image which was created on some other hardware, or created to support a whole range of hardware - in this case you may have dozens of unnecessary drivers slowing things down.
The solution is usually to tighten up your image by uninstalling excess drivers - you can find them using this Microsoft article.
Thanks - thats great info and make perfect sense. I will use this to feed my own testing and timings that I provide back to my project leadership.... I have to come up with a nice way to test when the OS is "ready for use", because we all know of the "not done booting yet" syndrome of windows... but I will want an objective measurement of the timing.
I will post back all items I find to help in my "delay reductions".
P.S: I have been directed that there may be a hotfix for EEPC 6.02 that may assist... I am attempting to acquire now through support!Message was edited by: David Roy on 1/31/11 11:29:52 AM CST
I have still been trying to reduce the delays.
Here are my recent results, using a fresh WinXP install machine in my lab:
1) WinXP with SP3 and AV 8.7 installed - no EEPC was a 3 second pause at the blue screen (seen between windows logo and windows login prompt)
2) Installed EEPC 6.0.2 with SSO enabled and the delay became 140 seconds at the same screen.
3) Installed Hotfix for EEPC which was recently released, it did not really reduce my boot delay. Now 139 seconds... most likely just normal variance.
4) Upgraded AV to new version 8.8, same EEPC settings with hotfix and SSO enabled. Delay reduced dramatically to only 61 seconds.
Looks like my answer is the AV Upgrade. The 1 minute delay is seemingly explained with the waiting for full windows driver/startup completion before allowing access to the Windows GINA .
Will still be working on this for a while and will update again if I have any further information or guidance from support!
Hopefully this experience helps others in a similar situation.Message was edited by: David Roy on 2/4/11 1:53:09 PM CST
Windows GINA limits explain some delay, and the AV 8.8 updated significantly reduced the overall delay to one that is "sell-able" to end users.
Sorry for such a long time efore posting my "final" on this.
In the end, my large customer chose to NOT deploy SSO options with their EEPC 6.0.2, but they did install EEPC to all of their laptop computers, extending their deployment based on a good overall experience - if they ignored the SSO issues.
We took many steps to try and get this working properly for the customer, including sending systems (from which all customer data was sanitized) to McAfee to review under the support contract.
In the end, we found multiple issues with unrelated customer products running Windows Services that did not interact well with the SSO GINA add-ins. In one case, after one offending service was located, the boot time went from nearly 5 minutes, to under 2 minutes... just by disabling a windows service.
While I cannot blame McAfee for third-party product issues, the fact that it took several months and constant contact with the support organization... then it taking the customer and the contractor (me) to determine that the customer environment was simply not suited for SSO is frustrating. I doubt we are the first enterprise customer to experience this, and as such, we should be gaining from the global knowledge of McAfee.
My opinion: SSO option will work in a WindowsXP desktop environment if, and only if, you already have a managed desktop with images that do not have problems with the SSO GINA add-in. If implementing in a non-managed desktop environment, you will nopt be able to reliably deploy SSO to all users without creating significant boot delay issues in at least a small portion of users.
In the interim, my customer has chosen to wait on SSO until their deployment of Windows7 managed-desktop images is deployed in the next year.
EEPC 6.1 has dramitic enhancements to login performance. Some is caused by unnecessary drivers (as Simon stated), but there were also some things we could do to optimize our software. Those were discovered and implemented in 6.1, so test it out ... I think you'll be impressed with the new performance improvements!