One of our servers' Deleted Machines group has grown to roughly 5,000 machines large. Due to the nature of our environment, we frequently find that machines that were deleted end up needing to be restored quickly - the holiday season was a perfect example. Users with laptops that were left in the closet for months suddenly return to operation!
If I were to empty the Deleted Machines group, I know that I can accomplish this via restoring the last backup of the database, but our machines, user accounts, etc. change so often that this could be more of a hassle than necessary to restore one machine to operation. On the other hand, our backups take forever because these 5,000 machines each have extensive audit logs and each machine folder has numerous associated files.
Has anyone come up with a clever way to manage this type of situation? I suppose it would be possible to copy the Deleted Machines folder to another location on the disk (so it is no longer part of /SBDATA), but then we're in the situation of our day-to-day admins not being able to restore machines on the fly... any ideas?
That's pretty much what we do today - we go into Deleted Machines and restore one solitary machine as needed. However the problem is that we now have over 5,000 machines in there, the database is huge (from a "number of files" standpoint). We can't empty the Deleted Machines folder because that would eliminate our ability to restore machines "on the fly."
But have I misunderstood the situation? If we empty the Deleted Machines folder, then the only way to "restore" them would be to restore the database, or to try to figure out which folder corresponded to that machine record in the file structure, then copy it back under the correct structure in SBDATA, right?
you can archive off all the items from the "bin" by replicating all the .rmv directories out of the SBData directory. the progression is xxxxxxxx (normal) > xxxxxxxx.rmv (deleted) > xxxxxxxx.wpe (wiped).
Only when you clear the bin or permanently delete something is the content of the objects folder deleted.
As for where to find it, that's also pretty simple. The root structure (skipping initial zeros) is 1 for users, 2 for machines, then objects are grouped in blocks of 512, so machine 1 will be in directory sbdata\2\0\1 and machine 513 would be in sbdata\2\1\1 etc.
You can find out the machine ID from the recovery page, or the about box pre-boot.
You could also keep an older copy (or copies at various intervals) on a second server (or workstation, since there is no performance need) just used for recovering the lost sheep. You could issue the boot once code from the recovery server, reimport them into production (using the client hostname), and have them sync. The client will renegotiate to discover the new object ID (as long as the name and key matches). This is how we handle "recovering" out of date machines.
One way you can try to control this is by moving "old-ish" machines to a holding bin. You could schedule a task on the server to check for machines in that folder that are older than XX days and permanently delete them.
We also have a general rule though, that if a machine is past our retention threshold, too bad. In those circumstances, we just make them reimage. If a machine is several months old, it will be out of date for patches, updates, and AV sigs. At some point, you just have to ask how important the machine (and data on it) is if they can leave it turned off for that long. If they really use the machine that little, perhaps the company could save some money if they gave that equipment to another person. The lazy owner could be issued a pencil (colored if they need to make slides), paper, and calculator instead.
Yes, I'm sarcastic. Sometimes the business requirements are just ridiculous.
You would need to know an account on the machine as well as what their password was at that time, right? Do you find that customers have private system accounts (with no expiring password) or anything for this purpose?
Well, a good set up would be to have the endusers' account assigned as well as a SafeBoot Admin account for recovery purposes. if the enduser no longer knows it's own old password -- you can still do a user recovery (as the useraccount is still in the database I assume) - ofcourse you can also use the safeboot administrator account if it's assigned.
Using passwords that never expire, is ofcourse not so good of an idea securitywise.
Gotcha! I didn't realize you could do the user recovery once the machine is deleted, but that makes perfect sense. You'd just need to know at least one user account that is stored in the SbFS that is still active in the console.
Great ideas everyone - thank you for the input! Sounds like there's no 100% clean way to do it - unfortunately we have three reasonably large SB servers that we would need to set things up for if we went with the "backup server" idea, and there is some planning necessary for the archival portion so people know how to request a restore and that it won't be as quick as it used to be. I'm also down with the pad and paper idea.
One area where we have a lot of room for improvement - still have a lot of people deleting machines by mistake when they swap hard drives between two machines. Unfortunately it's not always the user's fault they end up in Deleted Machines. *sigh*