1 2 3 Previous Next 28 Replies Latest reply on Feb 17, 2010 8:53 PM by SafeBoot

    DB000013 on client machine...

    R3k1awyk5

      Have an interesting situation to deal with this morning.  I had a user that was having issues logging into their machine this weekend.  A user-recovery fixed their issue, however in looking at their SBClientLog file, I noticed some bizarre behavior.

      Here is an excerpt of the audit log:

      2/16/2010 11:23:32 AM ------------------------------------------------------------------------------- ------
      2/16/2010 11:23:32 AM Starting SafeBoot Client Manager (v5.1.2)
      2/16/2010 11:23:32 AM Starting remote access server on port 5556
      2/16/2010 11:23:32 AM Starting synchronization
      2/16/2010 11:23:32 AM Applying cryption changes
      2/16/2010 11:23:32 AM SbFs total space = 20879360 bytes (19.91 MB)
      2/16/2010 11:23:32 AM SbFs free space = 14538752 bytes (13.87 MB)
      2/16/2010 11:23:32 AM Connecting to database: "SafeBoot Administration Database"
      2/16/2010 11:23:32 AM Address=eepc.homeoffice.XXXXXX.com
      2/16/2010 11:23:32 AM Port=5555
      2/16/2010 11:23:32 AM Authenticate=No
      2/16/2010 11:23:33 AM Error [db000013]: File not found
      2/16/2010 11:23:33 AM Checking for user updates
      2/16/2010 11:23:34 AM Error [db000013]: File not found
      2/16/2010 11:23:34 AM Checking for hashes updates
      2/16/2010 11:23:34 AM Transferring local audit information to database
      2/16/2010 11:23:34 AM Error [db000013]: File not found
      2/16/2010 11:23:34 AM Checking for file updates
      2/16/2010 11:23:34 AM Error [db000013]: File not found
      2/16/2010 11:23:34 AM Applying configuration
      2/16/2010 11:23:34 AM Synchronization complete
      2/16/2010 11:23:34 AM Automatically synchronizing again in 240 minute(s)
      2/16/2010 11:23:34 AM Applying cryption changes

       

      So I went looking in our EEM for the machine, and it appears that the machine object doesn't exist.  Because we routinely "clean up" our database of machines that haven't synched in 90+ days,  I checked the deleted items and still no luck.  So I went back to a backup that I made the last time we "permanently" deleted machines.  In the backup I found a machine object of the same machine name as our target machine.  I then exported the machine object from that database copy, and imported it back into our production database.  And tried to synch, and got the same message as above.

       

      Since then I've been trying to verify that the old machine object that I found was indeed the object for this client machine,  but haven't been having any luck.  Because the client is remote,  I can't use the Wintech tools on the machine, and I haven't been able to find a SBADMCL that will give me the local machines ObjectID.

       

      After doing some searching through McAfee's "lack-of" Knowledgebase, and through these forums,  I found some entry's about the 5.1.9 sbfiledb.dll issue,  so I tried replacing the client's sbfiledb.dll,  but am still having the same issue.

       

      Anybody have any suggestions on what to try next?

       

      I'd like to give McAfee props on their incredibly detailed error messages.  There's nothing like, "Hey, I can't find a file,  but I'm not going to tell you which one I'm looking for.  You have to guess..."  You might as well have just lumped this under "Unknown error"  like everything else...

        • 1. Re: DB000013 on client machine...

          During database maintenance period (off-line), scan groups for orphaned objects and perform cleanupmachinegroup.

          EEM Reporting tool will give you machine objectID's.

          • 2. Re: DB000013 on client machine...
            R3k1awyk5

            I don't think this is a case of an orphaned machine object.  When I Force a synch from the EEM to the machine object that I imported,  a new entry is created in the SDMCFG.ini client log,  so there has to be some amount of communication between client and server.

             

            Does anyone happen to know what files the client looks for when it is synchronizing?  Or does anyone know of a way to uninstall EEPC from a client machine without using EEM or Wintech?  If I could just uninstall EEPC, and start from scratch that would be fine.

            • 3. Re: DB000013 on client machine...

              If disk is not encrypted, you could try to run:

              sbsetup  -uninstall

              from client directory.

              • 4. Re: DB000013 on client machine...

                if the client is active, it means someone deleted that machine. It's as simple as that. To prove it, get the machine ID number (from the pre-boot recovery window) and go find that in your db.

                • 5. Re: DB000013 on client machine...
                  R3k1awyk5

                  Yup, Simon, you are right, someone (most likely me) did delete the object. We delete objects from our database on a regualr basis if they haven't synched in 90+ days.  Then twice a year, we create a full backup of the database, archive it, and then permanently delete all of the previously deleted objects.  As I stated in the original post,  I had found the machine object in a backup, and imported it back into the production EEM.  However,  when I try to synch the client,  I'm still getting the same "File Not Found" message.  Furthermore,  when I try to do a machine recovery on the client,  I get a "File Not Found" message when entering in the recovery code.  When I try to do a force-synch from the console, new entries are created in the SBClientLog.txt, so I know there is some communication between the server and client.  I did notice that when I imported the machine object into production from the backup, it was given a new machineID. I assume that synchs are done using the machineID since you can change a machine name locally and it will still synch to a machine object with the old machine name in the EEM.  Is there a way to import a machine object into the database and ensure that it gets the correct machine ID?  Or can you change an objects ID once it is imported?   I'm still also curious as to what files the clients are looking for when they synch...

                  • 6. Re: DB000013 on client machine...

                    yes, importing it was a mistake, you should have just copied the object directly back into it's directory in the master db, then a group scan to put it back into a group (renaming the dir to get rid of the .wpe extension). This is more "restoring from a backup" than import/export.

                     

                    A machine will pick up a new ID if it sees an object in the db with its name, and the right keys (and its objectID is wrong), but this is used only for offline install mode, otherwise we assume everything will keep the same id for its life.

                    • 7. Re: DB000013 on client machine...

                      Interesting...So shouldn't SDB import be prohibited for objects created with online install-set?

                      • 8. Re: DB000013 on client machine...

                        no, it's sometimes useful, but it's not a valid process for moving an object from a backup of the DB unless that object does not exist anywhere any more, and certainly not if an object exists with the same network name.

                         

                        plus, we can't tell if it's an offline created SDB, or if someone did what is happening here, exported and imported - the two create equal things.

                        • 9. Re: DB000013 on client machine...

                          Can you give example where that import (of online created object) would be useful?

                          1 2 3 Previous Next