1 2 Previous Next 11 Replies Latest reply on Jun 17, 2010 1:27 PM by jvolltrauer

    Understanding the SBDATA file structure

      We have run into some issues where machines were unintentionallydeleted from the DB.  We do keep regular backups of the SBDATA directoryso we still have the user information.  My questions, does anyone know howthe SBDATA directory is organized.  If I know the machines account ID howdo I get it out of the backup?

        • 1. Re: Understanding the SBDATA file structure

          The simplest approach to this (recover deleted machine object) is to look in "System" tab and "Deleted Items" "Deleted machines" group.

          Use machine object ID for searching.

          Failing that, you could perform database maitenance (offline) to make sure no objects are orphaned.

          If still no suceess, restore your backup database to a separate system and look for that machine object using EEM or Reporting Tool or sbadmcl scripts.

          If all of this fails, contact McAfee Prof  Services for futher help.

          • 2. Re: Understanding the SBDATA file structure

            simplest way is for you to connect to your backup using the Endpoint Encryption Manager as a local connection, then find the machine you want to restore, export it, and import it into your live DB (assumes the two db's are close together in time etc!)


            Alternatively, you can actually copy the structures between databases, but that has other risks - In this case you can find the location of the object using object/information in the menu - we consider this "tinkering" though, so you are best off not doing it unless it's REALLY important. For machines, it's rarely needed, but as you can't move other object classes between db's it becomes useful if a rogue admin deletes some users for example.


            As peter suggests - you really want to do this under the guidence of your McAfee reseller's prof services team, as you can mess things up beyond hope. If McAfee support find you've been tinkering, they may not be too keen to help you out. 

            • 3. Re: Understanding the SBDATA file structure

              I'm doing this with an backup database and it's local so I'm not messing with production.  Much of this was me just wanting to get an understanding of the SBDATA folder and how things were situated.  If there is no easy answer, then I'll just continue mounting the DB to local machine and exporting the machine id's to file.


              On a side note, it appears that many of these machines that were deleted, never did an initial sync.  The error i see often is failure to connect to remote database.  I generally force a local sync on the machine using sbadmin and thing work as expected, but these old machines were missed.

              • 4. Re: Understanding the SBDATA file structure

                If the machine never synced, why do you need the object? It won't have anything useful in it and won't be related to an active machine?

                • 5. Re: Understanding the SBDATA file structure

                  Maybe objects are needed to perform recovery. Unless, of course, encryption never started and pre-boot was not established.

                  • 6. Re: Understanding the SBDATA file structure

                    I think we can infer from the fact the machine never did an initial sync, that there was never any pre-boot or encryption related to that machine - even if it was an offline install, there would be nothing of value in EEM which would help with recovery etc.


                    But, let's see what the OP needs those objects for - maybe it's something other than the obvious?

                    • 7. Re: Understanding the SBDATA file structure

                      I guess my reason for the SBDATA question was to see if i could save myself some time.  We have all had to copy/move/delete this folder at somepoint and the time taken to do these tasks can be substantial given the number of users/machines etc.  I just wondering if I had a machine ID, if I associate that with a folder/file in the SBDATA directory and just copy that.  It looks like that's just not possible.


                      Now I have noticed a large quantity of WPE directories in the SBDATA directory.  Is it safe to delete those?

                      • 8. Re: Understanding the SBDATA file structure

                        No, tinkering with the structures in SBData is not supported in any sense. You should leave it well alone.

                        • 9. Re: Understanding the SBDATA file structure

                          Tinkering and understanding how it works are 2 different things.  Thanks anyway.

                          1 2 Previous Next