5 Replies Latest reply on May 7, 2010 1:17 PM by peter_eepc

    Best Strategy for Handling Deleted Machines?



      I'm running a v5 Server Environment with mostly v4 clients (a migration project is in place to begin upgrading clients to v5 as we speak).


      At present, there are many thousands of machines in our Deleted Machines group. This causes the group to take over 15mins to open and is frustrating for Admins. I'd like to simply permanently delete all the machines but we often find ourselves having to restore machines when we identify users who's machines have been off the network for an unusually long amount of time.


      My initial thoughts are to back up the database and then use a Dev server to point at the backup. Then permanently delete all the Deleted Machines on the Live Database, confident that they are backed up on the Dev Server.


      The plan would then be for Admins to connect to the Dev server when they need to restore a Deleted Machine that no longer appears on the Live Server. They would locate the machine, export the configuration and then import that SDB file into the Live Database.


      However, my first test has shown that on importing such a file from backup to live, the newly imported machine object is given a new ID? Is this simply because the ID exists already in Deleted Machines on the Live (ie. I haven't removed any Deleted Machines from Live yet) or am I going down the wrong road here?


      Any advice appreciated!

        • 1. Re: Best Strategy for Handling Deleted Machines?

          First of all, why new object ID of imported machine bothers you?

          Secondly, simpler strategy would be to undelete machine objects to separate machine group, export machine to SDB and save it's audit log to file. Then permanently delete undeleted machine. If there is a rare case that machine object is needed, import it.

          Much simpler approach and no backup/Dev database is required. You can publish archived machines list and their audit logs, to make admin activities simpler.

          • 2. Re: Best Strategy for Handling Deleted Machines?

            Would the new object ID now not match the Object ID on the local machine that has SB installed? I assumed that a mismatch of Object ID between client and database would mean recovery / reset would not work using the newly imported object?


            Unfortunately, our database does not have enough licences avaliable to restore all the Deleted Machines to new machine groups but we could perhaps do 500-1000 at a time as long as they were deleted after handling.


            So your suggestion, if I understand it correctly, is to move all the Deleted Machines to new Machines Groups, then export each machine configuration, resulting in a folder full of SDB files held elsewhere on the server. When the time came that a deleted machine needed to be restored, the SDB file could cimply be searched for and re-imported into the Dbase?

            • 3. Re: Best Strategy for Handling Deleted Machines?

              What is important for continued machine cennectivity is machine key, not object ID. So restored machine should retain original machine name, will have the same key, but different object ID.


              You can script the whole machine archive process, so you would process one machine at a time. You can repeat it automatically, if you save deleted machines list and create batch from it.

              Where you store archived SDB's, audit logs and processes machine lists (original names and ID's) is entirely up to you. Make sure you have a backup of those.

              • 4. Re: Best Strategy for Handling Deleted Machines?

                Ah ok. So I thought it was vital that the Object ID's matched in order for the local client to synch with the correct object? So by restoring a deleted machine, even if it gets a new ID, it will start to resume synch with the original client machine? What impact does this have on the ID stored locally on the client? ie. when you select Options>Recover on the client the ID and DB are displayed in the bottom left, would this change to match the server object ID or remain mismatched? I ask because we have often found it useful to use  Options>Recover to identify the correct machine on the Server, especially where multiple duplicates exist or the machine has been renamed without our knowledge.


                When you say "store archived SDB's, audit logs and processes machine lists (original names and ID's)" it sounds like I need to do a little more than simply "Export Configuration" with "include all users" and "include all files". Am I also needing to run some SBADMCL scripting to export the audit logs (DumpMachineAudit) and Object Names?


                Is it possible to generate a machine list of all machines in deleted items whilst they are still in deleted items?

                • 5. Re: Best Strategy for Handling Deleted Machines?

                  I'm yet to test recovery on imported objects. I will get back to you when I have it. Now I have it:


                  If restored machine object has the same name as previously used by the client, you can sync without problems. Client will update machine object ID to match imported machine new object ID.


                  Only after client machine ID update you will be able to perform machine recovery operations. If client did not sync yet, you will get object not found error (EEM or webHelpdesk recovery).


                  Export only machine object basic info. I.e. no users or files with it. Reassign users and put machine into proper group (apply group properties) as part of import process. I think it is safer to do that way.


                  Yes, use SBADMCL scripts and run them on database server. Unfortunately SBADMCL will not process many commands in deleted machines group. Use manual EEM Objects tab and Save list operation. From that you can create your batch job, processing each deleted machine object with appropriate SBADMCL script.



                  Message was edited by: peter_eepc on 5/7/10 2:17:23 PM EDT