The 100-Machine Intake: A First-Week Workflow for Machines You Didn't Build

The intake problem nobody budgets for

Every IT admin knows the day: a merger closes, a department refresh lands, or a remote office ships you its hardware, and suddenly you own a hundred Windows machines you did not build, did not configure, and cannot vouch for. Nobody hands you a security baseline with the keys. You get boxes, a spreadsheet of hostnames that is already out of date, and a deadline.

The instinct is to start fixing things. Resist it. The first job of an intake week is not remediation — it is establishing ground truth. You cannot prioritize what you have not measured, and you cannot prove improvement without a baseline. Here is a first-week workflow that scales from ten machines to a hundred without turning into a month of one-off tickets.

Day 0: inventory before judgment

Before a single setting gets changed, answer three questions about every machine: does it exist, can you reach it, and what is it running? Pull hostname, OS build, domain or workgroup membership, last patch date, and logged-on user into one list. Machines that do not respond get their own list — unreachable is a finding, not an excuse to skip them.

This is also the moment to freeze scope. Write down, in one paragraph, what "intake complete" means for this batch: every machine audited, every critical finding triaged, every fix verified by a second scan. If you do not define done up front, intake never ends — it just dissolves into business as usual with a guilty conscience.

Days 1–2: baseline audit on every machine

Run a full audit on each machine and store the output centrally. WinSentinel's free audit runs the full suite on a single machine — every module, no limits — so the per-machine scan is the same thorough pass whether you are auditing one laptop or a hundred. That consistency matters: when every machine is measured with the same yardstick, the results are comparable, and comparable results can be triaged instead of argued about.

Do not filter the output yet. A first-pass audit is a survey, not a verdict. Collect everything — hardening gaps, credential exposure, persistence surfaces, legacy protocols — and let the second pass do the judging. Admins who prune findings during collection always prune the finding that turns out to matter.

Day 3: triage into three buckets

With baselines in hand, sort every finding into three buckets:

• Stop the bleeding. Internet-exposed RDP, local admin accounts with shared passwords, SMBv1 still enabled, unpatched critical CVEs. These get fixed this week, no debate.
• Scheduled hardening. Audit policy gaps, legacy TLS, weak firewall rules, unsigned WDAC policies. Real risk, but fixable in planned change windows over the following month.
• Accepted and documented. The legacy app that requires an old protocol, the lab machine that cannot be patched. Accepting risk is legitimate — but only when it is written down, dated, and owned by someone. An undocumented exception is just a finding you chose to forget.

Sort machines the same way. Most batches split into a clean majority, a messy middle, and a handful of machines so far gone that reimaging beats remediation. Naming the reimage candidates on day 3 saves the week — nobody wastes days hand-fixing a machine that should have been wiped.

Days 4–5: fix in waves, verify by rescan

Fix one bucket across all machines before moving to the next. Fixing all of RDP hardening everywhere, then all of local-admin cleanup everywhere, is faster than fully remediating one machine at a time — you build muscle memory, your change notes stay uniform, and a bad fix shows up as a pattern you can roll back instead of a mystery on one box.

Every fix gets verified by a rescan of the affected machine, not by a checkbox in a ticket. "I changed the setting" is a claim; "the second audit no longer flags it" is evidence. At the end of the week, your deliverable is not a list of things you did — it is the before-and-after audit delta across the whole batch.

After week one: the fleet view

Intake ends, but the machines keep drifting. This is where fleet orchestration earns its keep: a central node that keeps every machine's audit current, rolls findings up into one posture view, and alerts when a node regresses — a setting reverted, a new admin account appearing, a machine falling behind on patches. The single-machine audit tells you the truth about one box; the fleet layer tells you the truth about all of them at once, continuously, without you having to re-run intake week by hand every quarter.

That distinction is the whole game. Intake is a project with an end date. Fleet posture is a habit. Do the project properly once, and the habit becomes cheap: the next batch of machines inherits the baseline, the triage buckets, and the fix waves you already proved. The hundred machines you did not build become a hundred machines you can defend — and the next surprise shipment becomes a routine week, not a crisis.