Server Going to Sleep: Critical Operations Interrupted

LIMEHAWK - Managed IT

Home>Incident Reports>Server Going to Sleep: Critical Operations Interrupted

Incident

Retail client called about their digital signage kiosks "going dark" during business hours. Three kiosks at the front of the store, all running the same menu/promo loop, all dropping to a black screen multiple times a day. Staff would wiggle the mouse to wake them, then three hours later do it again. The client's internal IT had already "fixed" it — they'd set the power profile to Never Sleep through Control Panel on each machine. It worked until the next Windows Update or GPO refresh, then the settings reverted and the kiosks went dark again. Customer-facing displays, visible downtime, annoyed store manager.

Root cause

Two things were fighting each other. Windows Update periodically resets the active power plan back to Balanced (Microsoft's default behavior after certain cumulative updates), and the domain's GPO was pushing out a baseline power policy that overwrote local changes on every gpupdate. The Control Panel fix works on the machine right in front of you, but it doesn't survive either of those events. We caught the active plan sitting on Balanced with a 30-minute display timeout and hibernate enabled at 180 minutes — exactly the defaults, every time.

- active plan: Balanced (not High Performance)
- sleep timeout: 30 minutes (default)
- hibernate: enabled, firing at 180 minutes
- GPO conflict: domain policy resetting local changes on refresh

Solution

The fix is to create a NEW power plan with a unique GUID, configure it the way you want, then set it active via powercfg. Because it's a custom plan Windows hasn't seen before, updates don't touch it. We also disabled hibernate at the system level with `powercfg /h off`, because hibernate is a separate mechanism from sleep and will still trigger even on a plan with sleep set to never.

What it configures

Script duplicates the High Performance plan, renames it, applies custom timeouts on AC power, disables hibernate at the system level, and sets the new plan as active. Because we own the GUID, Windows Update and GPO baseline enforcement both leave it alone — they only act on the built-in plans.

- display timeout: configurable (default: never)
- disk timeout: never
- sleep timeout: never
- hibernate: disabled completely (powercfg /h off)
- survives reboots, Windows Updates, and GPO refresh

Outcome

Deployed the script via RMM to all three kiosks, rebooted to confirm persistence, and verified the new plan was active on each. Zero sleep incidents since. Client mentioned the conference room PCs in their meeting spaces had the same problem during long Teams calls, so we rolled the same script out to 12 more machines. Same result — no more screens going black mid-presentation.

- kiosks fixed: 3 of 3
- sleep incidents since deploy: zero
- time per machine: 8 minutes
- later expanded to 12 conference room PCs

Key takeaways

Takeaway

Control Panel changes don't persist through Windows Updates.

Takeaway

powercfg with a custom plan GUID creates durable configurations.

Takeaway

hibernate is separate from sleep — disable it explicitly with powercfg /h off.

Takeaway

RMM deployment keeps the configuration consistent across the fleet.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)