The Swif.ai Windows Agent is a lightweight service that runs on your Windows devices to enforce security policies, inventory hardware and software, and execute remote actions (such as lock, wipe, or app install). This article explains how the agent behaves on managed endpoints and how it automatically recovers itself if something goes wrong.
1. What the Windows Agent Does
Once installed, the Swif.ai Windows Agent:
Runs as a background Windows service
Authenticates securely with the Swif.ai platform
Regularly checks in to:
Sync device inventory and health data
Receive and apply policy updates
Execute queued remote actions (lock, wipe, app install, etc.)
Monitors critical settings (e.g., OS version, security configuration, required apps) and reports drift
The goal is to provide reliable, always‑on device management with minimal user impact.
2. How the Agent Runs on Windows
2.1 Service installation
During installation, the Windows Agent:
Registers a Windows Service (typically running under a system account)
Stores configuration securely (including device identity and enrollment tokens)
Creates safe defaults for:
Check‑in interval
Log file location
Retry / backoff behavior when offline
The agent is designed to survive common events such as:
User log off / log on
Device sleep, hibernate, or restart
Network changes (switching Wi‑Fi, VPN on/off, etc.)
2.2 Normal operation
Under normal conditions, the agent:
Starts automatically with Windows
Checks in to Swif.ai on a regular schedule
Applies policy changes in the background
Uses minimal CPU, memory, and network bandwidth
If a device is offline, the agent:
Queues local changes
Retries connection on a backoff schedule
Applies any pending actions the next time it can reach Swif.ai
3. Self‑Recovery: How the Agent Heals Itself
The Windows Agent includes multiple safety and recovery mechanisms so that it can get back into a healthy state without manual intervention.
3.1 Service monitoring and restart
If the Windows Agent service stops unexpectedly (for example due to a transient OS issue):
Windows Service Recovery: The service is configured with automatic recovery (restart on failure).
Internal health checks: The agent performs internal health checks and can safely exit and restart if it detects a non‑recoverable internal error.
From the user’s perspective, this usually appears as:
A brief gap in check‑ins
Then an automatic return to normal operation, with no manual action required
3.2 Network and connectivity recovery
If the agent cannot reach Swif.ai (DNS error, proxy issue, VPN changes, etc.):
It does not break enrollment or device trust.
It retries connection using a safe backoff strategy.
When connectivity is restored, it:
Resynchronizes inventory and status
Fetches any missed policy or app updates
Replays queued remote actions
No device re‑enrollment is required in normal connectivity interruptions.
3.3 Configuration and policy drift
If local configuration becomes inconsistent with what the Swif.ai service expects (for example, partial policy application or a reverted setting):
The agent compares local state with server state on each check‑in.
If drift is detected, the agent re‑applies the expected configuration.
For application deployments, the agent can:
Retry failed installs or removals
Mark persistent failures for admin visibility, with error details
This continuous reconciliation mechanism ensures devices eventually converge to the intended state, even after temporary failures.
3.4 Safe handling of updates
When the Windows Agent itself is updated:
The agent verifies integrity of the downloaded update package.
The agent installs the update and gracefully restarts itself.
If an update fails:
The agent falls back to the previous working version where supported, or
Retries the update on the next check‑in, depending on the failure type.
The design goal is no permanent loss of management during an update.
3.5 CSP‑Based Automatic Sync Schedule
In addition to the agent's own check‑in mechanism, Swif.ai leverages Microsoft's DMClient Configuration Service Provider (CSP) to maintain a server‑managed sync schedule directly at the OS level.
How it works:
The Swif MDM server configures the Windows MDM enrollment's poll settings via the
DMClientCSP, setting devices to sync every 15 minutes in a continuous loop.These settings are applied through the standard MDM protocol (
./Device/Vendor/MSFT/DMClient/Provider/<MDM Provider>/Poll/IntervalForFirstSetOfRetries) — no agent involvement is required.On each device check‑in, the server verifies the device's current poll configuration. If the settings are incorrect or have been reset (for example, after a Windows update or enrollment change), the server automatically sends a correction command to restore the 15‑minute interval.
Why this matters:
Even if the Swif agent is in a bad state — crashed, partially installed, or not running — the OS‑level MDM sync continues independently.
This means the device will still contact the Swif MDM server every 15 minutes, allowing the server to detect the issue and push recovery commands (such as reinstalling or restarting the agent).
This eliminates scenarios where a device becomes "stuck" and requires manual admin intervention to re‑enroll or reinstall the agent.
This CSP‑based sync acts as a safety net beneath the agent's own sync mechanism, providing an additional layer of self‑recovery that operates at the Windows OS level.
4. How the Agent Recovers From Common Failure Scenarios
Below are examples of real‑world issues and how the agent responds.
4.1 Device reboot in the middle of a task
If Windows reboots while the agent is:
Applying a policy
Installing or removing an application
Executing a remote command
Then on the next startup:
The agent service starts automatically.
The agent re‑authenticates with Swif.ai.
The agent verifies:
Which tasks were completed
Which tasks are incomplete
The agent:
Marks completed tasks as done, and
Retries or resumes any incomplete tasks where safe
This avoids “stuck” devices after a reboot or power loss.
Additionally, the OS‑level CSP sync schedule (see Section 3.5) ensures that even if the agent does not start correctly after a reboot, the device will still sync with Swif.ai within 15 minutes via the MDM enrollment channel. This allows the server to detect the problem and trigger agent recovery automatically.
4.2 Partial uninstall or manual tampering
If a user or another tool:
Deletes some agent files
Tries to stop or disable the service
Changes local configuration outside of supported flows
The agent’s behavior depends on what remains:
If the service still exists and can start:
On next run, the agent validates its core files and configuration.
If it detects corruption, it can:
Trigger a self‑repair flow where available, or
Mark itself as unhealthy and surface signals to the admin console.
If the service is fully removed or non‑functional:
The CSP‑based sync schedule (see Section 3.5) continues to operate independently at the OS level, as it is tied to the Windows MDM enrollment — not the agent.
The device will continue checking in with the Swif MDM server every 15 minutes.
The server can use this channel to push agent reinstallation or recovery commands.
If the MDM enrollment itself is removed, the device will show as inactive/offline in Swif.ai, and an admin can choose to re‑enroll or consider the device unmanaged.
In supported environments, endpoint protection or software deployment tools can be used to automatically reinstall the agent if it is removed.
4.3 Long offline periods
If a device is offline for an extended period (for example, a laptop that’s powered off or rarely used):
The agent remains installed and ready.
When the device comes online again:
The agent authenticates using its stored device identity.
It performs a full sync of:
Device inventory
Pending policies and app changes
Outstanding remote commands
It then reconciles the device to the expected state.
As long as the device identity has not been revoked, no user action is required.
5. What End Users See (and Don’t See)
The Windows Agent is designed to be as unobtrusive as possible:
It runs silently in the background for standard policies and app changes.
In some cases, users may see:
Standard Windows installation prompts (e.g., for certain app installers)
Short‑lived notifications, depending on your organization’s configuration
Users generally cannot disable the agent if your organization has locked it down via policy.
If your organization pairs the agent with a self‑service or company portal experience, users may see more explicit information about:
Managed apps
Security requirements
Device compliance status
6. Admin Visibility and Troubleshooting
For administrators, the Windows Agent’s health and self‑recovery behavior is visible through:
Device status in the admin console (online/offline, last check‑in time)
Policy compliance and drift reports
Application management status, including:
Successful installs/removals
Persistent failures with error codes
Audit logs for:
Remote actions (lock, wipe, reset, etc.)
Policy changes
Agent updates
If a device appears unhealthy or stuck, recommended admin steps usually include:
Check the device page in the Swif.ai console for error messages.
Confirm last check‑in time and network connectivity.
If needed, remotely trigger a:
Policy resync
App reinstall
Device reboot
As a last resort, reinstall the agent on the device.
7. Security and Integrity
The Windows Agent is built with security and integrity in mind:
All communication between the agent and Swif.ai is encrypted.
Device enrollment uses secure, time‑bound tokens.
The agent only accepts commands and configurations from trusted Swif.ai backends.
Integrity checks during updates and critical operations help prevent corrupted or tampered binaries from running.
If a severe integrity failure is detected, the agent will:
Stop risky operations
Attempt a clean restart, and
Report its unhealthy status when it can reconnect
This ensures that the agent either runs in a known‑good state or fails safely.
8. Summary
The Swif.ai Windows Agent is designed to be:
Persistent – Survives reboots, network changes, and typical user behavior
Self‑healing – Automatically restarts, resyncs configuration, and retries work. A CSP‑based OS‑level sync schedule provides an additional recovery layer that operates even when the agent itself is non‑functional.
Safe – Applies policies and updates with safeguards and integrity checks
Low‑friction – Minimizes impact on end users while giving admins deep control
Together, these behaviors allow the agent to quietly maintain device compliance and management coverage in the background, and to recover itself from common failures without manual repair.