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.
1 of 1 people found this helpful
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!
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.
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!