Friday afternoon, May 12, we were supposed to be reviewing a mailbox cutover schedule. Instead we spent the weekend doing WannaCry patch management across every estate we touch — including a distributed environment of 700-plus servers where MS17-010 status suddenly became the only conversation anyone wanted to have. This post is the field version of that weekend: what we checked, what we deployed through SCCM, and why one client's estate was almost boring while another's was a war room.
The short version: WannaCry is not a sophisticated attack. It is a worm bolted onto leaked exploit code, spreading over SMBv1 to machines missing a patch Microsoft shipped two months ago. Every hard question it raises is a patching-discipline question, and those questions were answerable in March.
We are writing this on Tuesday. The kill-switch domain has slowed the original strain, copycat variants are already circulating, and everyone's management chain is asking for a one-page status. Here is what went into ours.
The patch shipped in March. The panic shipped in May.
MS17-010 went out on March 14 as part of the normal Patch Tuesday cycle, fixing the SMBv1 vulnerabilities that the Shadow Brokers dump made public in April. That is the uncomfortable arithmetic of this incident: organizations had roughly eight weeks of runway, four of them after working exploit code was on the internet for anyone to read.
The estates that were calm this weekend had nothing clever going on. They had a monthly patching cadence that actually completes, a software update process in SCCM that someone owns as a job rather than a hobby, and compliance reporting that gets read. The March servicing wave went out on schedule, the stragglers got chased in early April, and by the time WannaCry landed, MS17-010 coverage was already north of 98 percent with a known, named list of exceptions.
The estates in trouble had patching as an aspiration: quarterly "when change management allows," with unknown coverage because nobody trusted the WSUS numbers. On Friday night, those teams were not deploying a patch. They were doing discovery under fire, which is the most expensive possible time to learn your own inventory.
Microsoft even shipped emergency fixes for Windows XP and Server 2003 on Saturday — out-of-support operating systems getting a public patch is how seriously Redmond took this. If your estate still contains those, treat that patch as a tourniquet, not a treatment.
Friday night: inventory before action
Our first hours were not spent deploying anything. Pushing patches at an estate you cannot enumerate produces confidence, not coverage. Across the 700-server environment we ran three passes:
- Patch status. An SCCM software update compliance query against the March and April cumulative updates, cross-checked against WSUS, because the two disagree just often enough to matter. Anything unknown-state got treated as unpatched.
- SMBv1 exposure. A compliance baseline evaluating
Get-SmbServerConfigurationon 2012 R2 and later, and the registry equivalent on 2008 R2, to find where SMBv1 was still enabled server-side. - Reachability. Firewall rule review for TCP 445 — from the internet (there was none, verified rather than assumed) and between internal segments, because the worm's real damage model is lateral movement.
The PowerShell for the SMBv1 check is nothing exotic:
# Server 2012 R2 / 2016
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
# Disable it where nothing legacy depends on it
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# 2008 R2 needs the registry instead
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
-Name SMB1 -Value 0 -Type DWord
By midnight we had a spreadsheet nobody would frame: patched-and-SMBv1-disabled, patched-but-SMBv1-on, and the red column — unpatched. The red column is where the weekend went.
SMBv1 is an eradication problem, not a patching problem
MS17-010 closes the vulnerability. It does not remove the thirty-year-old protocol that made the vulnerability so valuable. Our position since Friday, and honestly since the Shadow Brokers dump: SMBv1 should not exist in your environment, and the patch is not a reason to keep it.
The reason it survives is always the same short list. A multifunction printer that scans to a share using SMB1. A vendor NAS from 2009. An application server whose ISV went out of business. A pair of Server 2003 boxes running something the business swears it retired. Eradication means finding those dependencies before you flip the switch, which is why we stage it: disable SMB1 server-side on modern servers first (fast, low risk), then work the client side, then hunt the legacy devices that only speak SMB1 and put them behind ACLs until they can die properly.
One dry observation from this weekend: every environment we assessed had at least one "temporary" SMBv1 exception documented in 2015. Temporary is a load-bearing word in infrastructure. Audit yours.
Emergency deployment rings in SCCM, without breaking the estate
For the unpatched population we used the same ring structure the estate uses monthly — compressed from three weeks to about thirty hours. Emergency does not mean uncontrolled; it means shorter soak times and pre-approved change records.
- Ring 0 — canaries (about 20 servers). One of each OS build and each major workload class. Deployed Friday night with a mandatory deadline, reboot suppressed only where clustering allowed a controlled failover instead.
- Ring 1 — the general population. Saturday, in maintenance-window batches, ordered by exposure: anything with broad inbound 445 reachability went first, isolated segments went last.
- Ring 2 — the fragile list. Sunday into Monday. Database clusters, the ERP stack, anything with an application owner who needed to be on the phone during the reboot.
Mechanically this was one software update group containing the March rollups, three collections, three deployments with staggered deadlines, and a forced client policy refresh so we were not waiting on default polling intervals. The step teams skip under pressure is verification: a deployment that reports success against a stale collection is a lie with a green checkmark. We re-ran the compliance query after every ring and reconciled counts against the Friday inventory.
Total elapsed time from decision to 99-plus percent compliance on the 700-server estate: roughly 60 hours, most of which was waiting on maintenance windows we chose to respect. The worm does not respect them, but a self-inflicted outage on a hospital-adjacent workload is not a better outcome than the one you are defending against.
Why the disciplined estate was boring on Monday
The contrast between our clients this weekend was stark enough to be the actual lesson.
The estate that drills patching monthly spent the weekend confirming what it already knew. Their Friday-night status call took eleven minutes. The work was disabling SMBv1 in more places and double-checking a handful of appliances — hygiene, not firefighting.
The estate that treats patching as a quarterly negotiation spent the weekend discovering servers. Machines missing from collections. A subnet that never made it into a boundary group. Two hosts whose SCCM clients had been broken since January, faithfully reporting nothing. None of that is a WannaCry problem. All of it became urgent because of WannaCry.
Patching discipline is unglamorous precisely because its output is the absence of drama. Nobody gets congratulated for the ransomware that did not detonate. But the delta between those two weekends — eleven minutes versus sixty hours of sustained effort — is the most honest ROI figure we can offer for a functioning update program.
What we're changing anyway
Even the calm estate is getting changes out of this. Our post-incident list, in priority order:
| Change | Why |
|---|---|
| SMBv1 disabled by default in server builds | The patch fixed the bug, not the protocol |
| 445 blocked between user VLANs and non-file-servers | Worms need lateral paths more than they need exploits |
| Critical-severity out-of-band ring, pre-approved | Compress decision time to zero for the next one |
| Monthly compliance report to management, one page | Coverage numbers nobody reads are coverage numbers nobody funds |
| Broken-client hunt as a standing weekly task | An unreporting agent is worse than an unpatched server — it is an unpatched server you believe is fine |
We are also telling every client the same uncomfortable thing: this strain had a kill switch and a two-month-old patch. The next one may have neither. The window between patch release and weaponized exploit has been shrinking for years; WannaCry just made the trend legible to boards. If your patching cycle cannot reliably complete inside thirty days, that is now a business risk conversation, not an IT preference.
If you're facing this
If your weekend looked like discovery under fire — unknown MS17-010 coverage, SMBv1 everywhere, SCCM reports you don't trust — that is fixable, and faster than you'd think. We have run patching and eradication programs across estates of 700-plus servers and can get you to verifiable coverage with a ring structure that survives the next emergency. Get in touch; the next worm will not schedule an appointment.