Approved. Now What?
The CCB had approved Dev's change request: upgrade the enterprise print driver from v6.1 to v7.4 on all 400 domain workstations. Two-hour window, Saturday 1 AM. Straightforward.
"The CCB tells me what to change," Dev explained to his intern Priya. "My job is to figure out how to change it — and what to do when it doesn't go exactly as planned."
"Which it never does," Priya said.
"Which it never does."
What's Allowed to Run?
Before installing the new driver, Dev needed to update GlobalNet's application control policy. The company used an allow list — only explicitly approved executables could run on workstations. Everything else was blocked.
"The new print driver installer is PrintDrvSetup_v7.4.exe," Dev told Priya. "Until I add it to the allow list, it won't even start on anyone's machine."
He opened the application control console and added the new installer's hash to the allow list. The old installer would be removed from the allow list after deployment.
"What if we used a deny list instead?" Priya asked.
"With a deny list, everything runs except the things you've explicitly blocked. More flexible, but less secure. Our environment uses an allow list because we want tight control over what executes. Think of antivirus as a very large deny list — it blocks specific known-bad code while allowing everything else."
Stay Within the Lines
The approved change was specifically: upgrade printer drivers on workstations. That's it. Not print servers, not the print management application, not the GPO templates — just the workstation drivers.
"During my prep work," Dev noted in his implementation plan, "I discovered that print server print processor v3.1 has a compatibility warning with the new driver. I'll need to investigate."
He called the change manager on Friday afternoon. "The driver upgrade might require a print processor update on the servers too. Can we expand scope?"
"Does the driver install fail without it?"
"It installs — but some print queues generate a warning. Not a showstopper."
"Then proceed within original scope. Document the server issue and submit a separate change request. Don't expand scope in the window."
Dev agreed. Scope creep during a maintenance window was how small changes became major outages.
400 Workstations, 2 Hours
The driver upgrade required the print spooler service to be stopped on each workstation during installation. Brief downtime per machine, but staggered across 400 — easily manageable overnight.
Dev scripted the deployment using the software distribution system: push to 50 machines in Batch 1, verify success, then proceed to the remaining 350. "If Batch 1 fails, I stop and roll back those 50. I don't touch the other 350 until I understand why it failed."
For the print servers — which GlobalNet's 24/7 warehouse team depended on — Dev used a primary/secondary strategy: failover to Print Server 2, upgrade Print Server 1, verify, then switch back.
"That way there's no interruption even during the server-side work," he explained.
What Needs to Restart?
The driver install required: stop the print spooler service, install, restart the print spooler. No full OS reboot needed — just the service.
Dev documented three restart scenarios in his implementation plan:
- Service restart (fastest) — stop and start the Windows Print Spooler via Services.msc or PowerShell. 15 seconds per machine.
- OS reboot — required only if the installer flagged a pending reboot. None expected but included in the plan.
- Power cycle — not expected, but the plan documented what to do if a workstation failed to respond after a service restart.
"Restart procedures also tell you something important," Dev added. "If a system doesn't come back cleanly after a controlled restart, that's how you'd find out — better here than during an unplanned power outage."
The Sign That Says 'Don't Touch'
At 2:30 AM, Batch 1 completed cleanly. Batches 2-7 were running. Then Priya flagged a workstation: WS-WAREHOUSE-047.
"This one's running LabelMaster 2004. It's been on the ignore list for years. Nobody knows who maintains it."
Dev looked at the install log. The new driver had deployed, but LabelMaster was now throwing errors when printing. The old driver and LabelMaster had some compatibility quirk that wasn't in any documentation.
"This is exactly what legacy apps do," Dev said. "They run fine until you change something they depend on. And because nobody documented them, you discover the dependency the hard way."
He executed the workstation-specific backout for WS-WAREHOUSE-047 — restored the previous driver — and documented the LabelMaster dependency. That workstation would stay on v6.1 until a separate change request was approved to either upgrade or replace LabelMaster.
By 3:45 AM, 399 of 400 workstations were running v7.4. One documented exception. Backup plan executed successfully.
Update Everything — Including the Docs
After the change, Dev spent 45 minutes updating documentation. The network diagram now showed v7.4 on workstations. The asset management system was updated. The application control allow list was cleaned up — v6.1 installer removed. A new known-issue note was added to WS-WAREHOUSE-047's record.
"If I don't update the docs now," Dev told Priya, "the next person to work on this environment will have inaccurate information. And they'll trust it. And it will cause a problem."
He also pushed the change to the version control repository — a snapshot of all modified configurations so that any future issue could be diagnosed against a before/after comparison.
"Version control isn't just for code," he said. "It's for configurations, scripts, GPO templates — anything that changes and needs to be auditable."