We had similar messages in the SafeBoot connector log (10 min scheduled update from AD)
db010002 Unable to change the object's access mode
Couldn't see anything wrong with the connector, etc. so stopped and restarted the SafeBoot Database Server, and we could see the users added in the next scheduled sync...
Not seen any db type errors before so hoping this isn't the shape of things to come... So far we only have 230 users and 190 odd laptops
FYI - I've noticed that on some Dell laptops fail to boot after encryption with the SATA controller set to IRRT opperation, setting back to AHCI resolves the issue.
The error was reported on the client side. Everything looked find server side.
Your problem may actually on the server side. We saw this exact same thing when doing mass rollout. I think the checkin time of 10 minutes may be too much. I think what happens is the service gets bogged down and corrupted information gets pushed down to the systems. Once we restarted the Safeboot sevice everthing would go back to normal for awhile. If you havent already there is some documentation for turning indexing on the server that helped alot. There is also the ability to change the way a computer is lined up for sync. don't quote me on this but if the server is busy it puts the computer in line to wait. This can build up on the server. There was a setting that just said if I cant sync now just go away and try again on my next sync. Don't wait in line.
The end results was we did an emergency boot on the systems with the error which flushed out the corruption, and after turning on indexing and the dont wait in line I have rarely ever seen this occur again.
3/27/2009 9:41:42 AM Error [db010002]: Unable to change the object's access mode
Database related issue, means that something is keeping a lock on the object it is trying to sync with, and cannot change it therefore.
Try restarting the communication server, this will release any locks it has on the object(s), if that doesnt do the trick it most-likely due to the permissions on the sbdata folder, ensure that its not set to read only.
3/27/2009 9:41:42 AM Error [e0050043]: Unable to open client data store attribute
Indicates that a data store (eg. a useraccount object) on the local clientmachine is corrupted. Hence you wouldn't be able to log in with that user account anymore either.
To find out which user this is, will take way too much time.
Suggest you perform an Emergency Boot, this will recreate the entire safeboot filesystem (SBFS) and repopulate all (assigned) useraccounts to this machine, and therefore remove this message
Also, IRRT is indeed not supported still, this doesn't have anything to do with these messages however.
As for the Name Indexing comment mentioned earlier -- enabling this will indeed be suggestible, as this would increase server / database performance, and would reduce chances of corruptions and time-outs / locks upon objects.
Suggest you enable this.
A few things I'm planning on doing but first a few questions before I do them.
We originally were told that running Safeboot off a VMWare server session was ok but I was planning on pushing a move to a dedicated box. Any one have any thoughts on this?
In the meantime, I was planning on enabling named indexing but before I make a change like this, are there any cons to doing this? I have 800 users and I'd hate to have a problem with logins.
the index can only help - it can't make anything go bad.
as for the virtual>physical swap, the only thing this will do is increase performance if you put everything local. The limitation is not really VM, it's the tier2 SAN connection most people tend to tag along with it.
go to tier1 dedicated LUN's and it really should not matter if it's DAS or SAN.
>should< is the operative word though. I've never seen a SAN live up to the expectation of being as fast as DAS.
Hello Simon: I will be upgrading to v5.2.2 and I have a question or two concerning new version and E series laptops from Dell with SATA drives.
I hear that if already encrypted with SB v4.2 and hard drive is set to ATA---no worries when I upgrade, regardless of O/S. T or F?
I hear that if already encrypted with SB v4.2 and hard drive is set to IRRT, this will cause a problem when I upgrade client machine. T or F?
What happens if already encrypted with SB v4.2 and hard drive is set to AHCI, will this cause a problem when I upgrade client machine?
What is the solution if current machine is set to IRRT and it is a problem to upgrade at the setting? Decrypt and re-encrypt?
Will version 6 address this issue?
Is McAfee/Safeboot working on this issue? Will there be a patch perhaps?
We have similar machine base. We started with 5.1.3, and have opted to set the SATA mode for all devices to ATA. No IRRT, no AHCI, etc. and we've had pretty good luck. Now that we're going to 5.2x version, we may revisit that decision, hoping that everything plays nicer than it did.