Recovering a workstation that is gone, and the order that gets someone working

Why this matters

This is the last lesson of the course and it is the one where everything else gets used at once. A machine is unusable — dead disk, failed upgrade, compromise, theft — and somebody cannot work. The question is not really "how do I fix this machine". It is "how do I get this person working again, and how soon".

Those are different questions with different answers, and keeping them apart is the whole skill in this lesson. The machine may take two days. The person can often be working in twenty minutes. A technician who only answers the first question leaves somebody sitting at an empty desk being told that progress is being made.

The lesson

Deciding between repair, restore and rebuild in the first ten minutes

The first ten minutes are for deciding, not for doing, and three questions settle it.

1. What is actually wrong? Use the boot-stage diagnosis from the troubleshooting domain: firmware, bootloader, kernel, or desktop. A machine whose firmware cannot see the disk is a different job from one with a corrupt user profile.

2. Where is the data, and is it safe? Before anything else. If the disk is failing, every minute of diagnosis is a minute of risk, and the correct first move is to image it or copy the data off. If the data is in the cloud or on a server, this constraint disappears and everything gets easier.

3. What does the user need, and by when?

Then choose:

• Repair when the fault is understood, bounded, and the machine is otherwise sound. The repair install, the driver rollback and the restore point are all in the earlier domain and all beat a rebuild.
• Restore when a tested image or backup exists and the fault is not understood, or when the machine is compromised. Restoring to a known-good point is faster than diagnosis and it ends with certainty.
• Rebuild when there is no image, when the machine is compromised and there is no clean restore point, or when the hardware is being replaced anyway.

The time-boxing discipline: decide in advance how long you will spend trying to repair before switching to restore or rebuild. Without that, an afternoon disappears into a diagnosis that was never going to pay, and the user loses a day they did not have to lose.

Image-based recovery, and what an image does and does not contain

An image is a copy of the whole machine — every partition, the boot configuration, the operating system, the applications, the settings — restored as a unit.

What it gives you: a machine back exactly as it was, in the time it takes to write the image, usually under an hour. No reinstalling applications, no reconfiguring, no hunting for licence keys. For an estate with standard builds, this is why imaging exists.

What an image does not contain:

• Anything since it was taken. An image from three months ago restores a three-month-old machine, and the user's recent work is not in it unless a separate data backup covers the gap.
• A guarantee of cleanliness. An image captured after a compromise reinstates the compromise. The date of the image against the date the problem started is the first thing to check.
• Hardware independence, always. An image from one model restored onto another may not boot without driver injection, which is a real constraint when the original hardware has failed.
• Encryption keys, depending on how it was made. An image of an encrypted volume needs its key like anything else.

The two kinds worth distinguishing: a reference image, built once and applied to many machines, which is clean and generic and needs the user's data and applications afterwards; and a machine image, a backup of one specific machine, which restores everything and carries the risks above.

Most organisations have the first and believe they have the second, and the difference is discovered on a day like this.

Rebuilding from installation media, and restoring data into a new profile

Without an image, the route is installation media and a data restore, and the order matters.

The sequence:

1. Rescue the data first, if it has not already been rescued. From the recovery command prompt, or by attaching the disk to another machine. The obvious folders plus the ones that are not obvious: browser profiles, mail stores, application data, the desktop, and anything outside the user profile.
2. Retrieve the encryption recovery key before touching anything, if the volume is encrypted. Without it the previous step is impossible.
3. Note the configuration: printers, mapped drives, VPN, certificates, specialist software and its licences.
4. Clean install from media, with the boot-mode and partition decisions from the first domain of this course.
5. Drivers, then updates, in that order, until the machine is current.
6. Applications, from their proper sources.
7. Data into the new profile.

That last step is where mistakes happen. Do not copy an old profile folder over a new one wholesale: profiles contain machine-specific and account- specific state, and overwriting a fresh profile with an old one reproduces the corruption you were escaping and can break the new account outright.

Copy data — documents, pictures, project folders — and copy specific application data deliberately, one application at a time, after confirming what that application expects. For mail, use the application's own import. For browsers, use the browser's own profile import or its sync.

Slower, and it ends with a machine that works rather than one that inherited the last one's problems.

Account, mail and licence recovery, which is usually the longer half

The machine is frequently the short half. What takes the rest of the day is everything that was not on it.

Accounts. Signing back in to the operating system, to the organisation's directory, to the applications. Where multifactor is involved, and the second factor was on a device that has also gone, this becomes an account recovery exercise — which is why the mobile provisioning lesson insisted that moving authenticators is a planned job.

Mail. A server-based mailbox reappears on sign-in and is the easy case. A locally stored mailbox is a file that must have been rescued, and if it was not, it is gone. Establishing which kind it is takes thirty seconds and it decides the whole afternoon.

Licences. Software tied to the machine, keys that were on the machine, an activation limit already reached by the machine being replaced. Some vendors release a seat automatically and some need a support ticket with a wait attached.

Certificates. A user certificate that was not exported is not recoverable, and anything encrypted with it is not either — which is the file-level encryption warning from the security domain arriving in person.

What makes this half fast: the asset record, the documented configuration, and the licence register from the documentation lesson. What makes it slow is their absence, and the difference is hours.

The habit worth building now: when you set a machine up, record what it would take to rebuild it. That note is read exactly once, on a day like this, and it is worth more than anything else you wrote about that machine.

Getting the user working temporarily while the real recovery continues

This is the part that distinguishes a good recovery, and it happens in parallel with everything above rather than after it.

Get them working first, properly recovered second.

The options, roughly in order of speed:

• A web browser on any machine, if their work is in cloud applications. This is frequently a five-minute answer and it is frequently not offered.
• A loan machine, signed in to their account. For an estate with roaming profiles or cloud identities, this is close to seamless.
• Their phone, for mail and messages, which keeps them contactable and informed while the rest is sorted.
• A colleague's machine with a second account, which is imperfect and far better than nothing.
• Their own machine in a degraded state — booted from external media, or with the disk read-only — for retrieving one document they need now.

And tell them the plan. "You can work from the browser on this loan machine this afternoon; your own machine will be ready tomorrow lunchtime, and your files are safe — I have a copy." That sentence is the difference between a frustrating day and a manageable one, and none of it is technical.

The closing thought for this whole course, because it is the right place for it.

Almost every fault in this exam is reversible. An operating system reinstalls, a permission is reset, an infection is removed, a phone is restored, an account is recovered. What makes any of them irreversible is not the fault — it is the absence of two things that had to exist beforehand: a copy of the data, and a record of what the machine was.

Both are created on ordinary days, by someone who has no idea which machine will need them. That is why the last domain of this exam is documentation, change control, safety and backup rather than anything technical, and it is why it is worth a fifth of the paper. The hardware exam teaches you to prove what a component is doing. This one teaches you that the outcome of every bad day was decided by what somebody wrote down and copied on a good one.