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.
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?
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.
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?
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.