9 Replies Latest reply on Nov 25, 2009 10:40 AM by rbarstow

    SATA settings in bios for Safeboot

      We have about install safeboot on close to 2000 machines. We currently have about 800 in service and I'm starting to see 1 or 2 a week of issues who can't login to their machines. These are all Lenovo/Ibm Thinkpads from x60/t60 x61/t61 and x200/x400. We are using version 5.1.7.

      3/27/2009 9:41:42 AM Error [db010002]: Unable to change the object's access mode
      3/27/2009 9:41:42 AM Checking for user updates
      3/27/2009 9:41:42 AM Error [e0050043]: Unable to open client data store attribute
      3/27/2009 9:41:42 AM Checking for hashes updates
      3/27/2009 9:41:42 AM Error [e0050043]: Unable to open client data store attribute
      3/27/2009 9:41:42 AM Transferring local audit information to database
      3/27/2009 9:42:12 AM Error [db010002]: Unable to change the object's access mode
      3/27/2009 9:42:12 AM Checking for file updates

      Now I've heard some info that using SATA setting AHCI might be a possible reason. I'm looking for feed back from some other folks to see if we need to make a change. I haven't heard any thing definitive that this is a problem. Because most of these people are remote to me, I'm forced to remove and reinstall safeboot.
        • 1. RE: SATA settings in bios for Safeboot
          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

          HTH?!
          David
          • 2. RE: SATA settings in bios for Safeboot
            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.
            • 3. RE: SATA settings in bios for Safeboot
              The error was reported on the client side. Everything looked find server side.
              • 4. RE: SATA settings in bios for Safeboot
                Dvanmeter
                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.
                • 5. RE: SATA settings in bios for Safeboot
                  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.
                  • 6. RE: SATA settings in bios for Safeboot
                    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.
                    • 7. RE: SATA settings in bios for Safeboot
                      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.

                      Simon.
                      • 8. Re: RE: SATA settings in bios for Safeboot

                        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?

                         

                        Thanks MK

                        • 9. Re: SATA settings in bios for Safeboot

                          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.