Maintaining a Consistent Baseline on Shared Endpoints with Cloud-Managed Reboot-to-Restore

Shared machines rarely stay the way you built them. Every session leaves something behind, and after enough of them, no two endpoints match. Here’s why that drift happens, and how cloud-managed Reboot-to-Restore holds every machine at the same defined state. 

Why Shared Endpoint Baselines Drift

Drift is the accumulation of incremental changes over time. A user installs a browser extension, another changes a display setting and a technician applies a one-off fix to an individual machine. Applications update on different schedules, causing versions to diverge. None of these changes are necessarily problematic on their own. Over time, however, they create a fleet where endpoints differ, so the same fix may not produce the same outcome across machines.

Enforcing a Consistent Baseline With Cloud-Managed Reboot-to-Restore

Reboot-to-Restore holds an endpoint at a baseline defined by the administrator. While a machine is frozen, changes to the protected drive are temporary and cleared at the next restart. The disk returns to that baseline, not to whatever the last session left behind.

Cloud management means those settings are defined as policies in a hosted console. An agent on each endpoint retrieves its policy over an outbound internet connection, so there’s no on-premises server and no requirement for machines to be on the corporate network. Two components make this possible:

• Write Redirection and Cache Discard

Reboot-to-Restore software uses a kernel-level filter driver below the file system, operating at the level of disk sectors. It doesn’t classify changes as wanted or unwanted because it doesn’t inspect their content. The driver handles all data and system changes the same way.

The process works in three stages:

• Stage one: A write aimed at the protected volume is intercepted and redirected to a cache in free space on the drive, leaving the original sectors unchanged.
• Stage two: Reads during the session check the cache first, allowing changes to appear normal. Software installs, files save and settings apply.
• Stage three: At restart, the driver discards the map of redirected sectors and releases the cache, causing reads to resolve to the original sectors again.

Restore time does not scale with the amount of data written because the system doesn’t scan, compare or roll back changes. The session record is simply discarded. The limitation is that the volume needs sufficient free space for the cache, and anything meant to persist must be written outside the protected area.

• Centralized Policy Control Across Endpoints

Write redirection holds one machine at its baseline. Policy control applies that same baseline across all endpoints. Each endpoint runs an agent tied to a group and a policy, and the policy defines the baseline. This includes which drives are protected, whether the machine is frozen, and when maintenance windows run. You edit it once, and endpoints apply the changes at their next check-in.

It also controls how endpoints receive and report their configuration:

• The check-in interval is configurable, and you can trigger a refresh instead of waiting for the next scheduled check-in.
• Group assignment occurs during agent installation, so a new endpoint inherits the appropriate baseline without manual setup.
• The console reports each endpoint’s state, including whether it’s frozen or thawed, its applied policy and its last check-in.

That last one earns its keep. The most common way a protected fleet drifts is when a machine is thawed for maintenance and never refrozen. Changes persist from that point on, often without detection until an issue occurs. Tracking thawed state per endpoint helps catch it, and refreezing is a console action. 

Discover Deep Freeze Cloud

Deep Freeze Cloud applies Reboot-to-Restore protection from a hosted console. Define a baseline once, assign it by group and check the freeze state of every endpoint in one place.

Discover Deep Freeze Cloud to see how it fits your shared systems.

FAQs

Does Write Redirection Slow a Machine Down?

Writes are redirected to the cache, so overhead is small. Free space matters more, because the cache needs room for a session’s changes.

How Fast Does a Policy Change Reach Endpoints?

At the next check-in, on the interval you set. A manual refresh moves it sooner on machines that are online.

Can Machines Outside the Office Be Managed This Way?

Yes, as long as the agent can reach the console over an outbound internet connection. It doesn’t need the corporate LAN or a VPN.