EEPC 5.2.0 - After logging into Endpoint and before getting to XP log on, I received "Unable to open client datastore attribute". After clicking on OK, the pc continues to boot and I am able to log on as normal. The pc is fully encrypted and there are no errors in the status. This is on a HP dc7900. Any ideas?
A. run HDD diagnostics - if they pass, then most likely it's something with the EEPC userID that is broken. You need to either recreate the userID token and sync or do an emergency boot if that fails to resolve the problem. If it is a userID problem, it probably happened because a connection was broken when trying to sync.
B. try deleting the userID(s) and create new ones and reassign to the machine and sync. if the same error happens, disable boot protection in the EEM and sycn. When the machine is decrypted, then re-enable boot protection and let it re-encryupt.
C. if it's still not working, then the sbfs is broken - you can only do an emg boot with SafeTech. Doing that will rebuild the sbfs and if it.
This info was provided to me by Simon Hunt on a past post.
We have found the Emergency Boot does not always repair this issue and have been forced to remove and reinstall EEPC to address this. Found this both 5.1.8 and 5.2.3
McAfee advises that there is supposed to be a fix in the forthcoming 5.2.5 to address the issue. We have asked if a machine currently suffering this error would be reparied if upgraded to 5.2.5 but no answer.
Again, question for you: Is this error permanent or sporadic (i.e. every time you run pre-boot, or sometimes)? What hardware did you observe it on?
Permanent errors. They show at every sync event in the client log. We are an HP shop, but we see the errors on every model so I don't know if it's hardware related. Sometimes an Emergency Boot fixes the machine, but more often than not it does not. The only resolution we have that works 100% right now is to decrypt the drive and remove/reinstall EEPC.
Nope, nothing special. We have run across NT compression issues, but have documentation in place for our support staff on how to identiy/deal with those.
This seems to be a local corruption issue that appears spontaneously. I have witnessed a coworker's laptop that had a 5.2.3 installation working for several weeks suddenly develop the problem. We have much information in to McAfee Support on this but so far no luck in identifying the root cause. This a huge problem as we have close to 3000 machines in the field currently reporting this error in their client logs. It doesn't stop the client from functioning, and they can recieve software updates perfectly fine. The piece that breaks is that the client is unable to accept user changes.
What you have is corruption within the SBFS but you already know that.
Here's what I've done to fix the problem - don't know if it's the "official" way or if it will work for you but it's worth a try. Also, I'm using version 5.2.3.
Boot a problem machine with the SafeTech disk.
Authorize and Authenticate.
Mount the SBFS as a drive - Z: for example (If you want, you can use the A43 File Management Utility to browse the contents of the SBFS. You'll see a folder called "DataStore". Within this folder is another folder named 00000001. Within this folder are all authorized SafeBoot users. Each sub folder will correspond to a user ID within the SBFS database. It's one or more of these folders that has corrupt data.)
Run a chkdsk on that drive
You'll be asked if you want to fix errors and locate bad sectors. Yes, you want to do that.
You may be asked to unmount the drive because it's in use. Yes, you want to do that as well.
If all goes well chkdsk will located the corrupted folders and truncate or delete them.
Now hopefully you have more than one authorized user of the machine because if there's only one and chkdsk truncates it then you'll have just caused yourself more grief! We have several "back door" logins that are part of all of our machines.
Anyway, once chkdsk finishes reboot and get yourself into Windows and do a sync. Your "Unable to open client DataStore attribute" error message should go away. You can also do an audit of the machine in the SBFS Database console and see if it's updating correctly. You can tell if you have a corrupted machine if the audit just shows "Checking for configuration updates" and nothing more. You should see when a user logs in, if they supplied an invalid password, password changes, etc...
I know you have 3000 machines that are experiencing errors and this would be a very arduous undertaking to do it the way I've described. I have about 360 and have had this problem on about a dozen so far. This procedure worked on the four or five I've tried it on. Haven't gotten to the rest yet. Good luck!
There is a special module available from Platinum support which will do the chkdsk on SBFS for you - you simply have to deploy it to your machines using the built in EEM file deployment system.
It's only available to customers directly experiencing a certain set of issues though - your Platinum person can help you with it.