Thanks for pointer, but I'm afraid none of that seems to help.
I have been tracing the password changes with Process Monitor and can only see safeboot (SbClientManager.exe) accessing the \Device\SafeBootFSVolumes\Disk0\DataStore\... files during the Windows password change process... This makes it look like it is aware of the password change happening...
I can actually see it reading an area that matched the safeboot user id e.g. \Device\SafeBootFSVolumes\Disk0\DataStore\00000001\00000367\ATTRIBS.DAT, however it doesn't appear to even try and write to this location, which I would assume would happen if the password change had been detected (and was going to be written to the local store)
As far as we are aware, nothing has changed. Our safeboot configuration has been stable for > 18months, and none of the device or user settings have been adjusted.
We have 350+ machines and 650+users andd haven't seen any issues until this week.....
I thought it might possibly be a recent MS update from our WSUS, but the issue happens on a freshly built machine which hasn't yet been updated by WSUS.... BTW the build process hasn't been modified in > 6months, so nothing changed their, either....
We have a call with McAfee, and have provided the logs and trace files... this has now been escalated... We'll have to await their repsonse but would appreciate anybody elses insights or suggestions
What about password strength policies in AD and SafeBoot? Did enforcement changed in either place?
Did you also check sbgina.ini?
Thanks for your prompt replies (quicker than McAfee support !! ;-)
No password strength policies in either... We are actually a Novell eDirectory environment (with mirror sync'd AD, which the safeboot connector works with - all fine here, user updates and deletions sync fine). The password policy is configured solely in eDirectory, as this is our primary logon (AD is background)... Again, no changes in last couple of years!
As regards SBGINA.INI again, nothing has changed - we haven't updated the Novell Client or the Safeboot client in months, so I can't see any reason for a change there - same sbgina.ini as was...
So you change Windows password via Novell or Windows?
99% of password changes are during login - grace logins, password expiry, etc. both novell and windows are changed at same time. Very occasional CAD:Change Password from workstation - again both changed. This has worked flawlessly for the past 18+ months!! Obviously something has changed, but nothing deliberate on our part...!
As I re-visited the forums I realised I hadn't completed this thread, sorry!
It turned out to be an issue with a bad 3rd party application install package... It was modifying the
and not keeping the SafeBootNP5 entry....
Fundamental issue is described in KB66709