Drive Fragmentation Monitoring

Purpose

The Drive Fragmentation Monitoring solution provides automated detection and optional remediation of disk fragmentation on Windows servers and workstations. It evaluates each eligible fixed rotational HDD against a configurable fragmentation threshold, creates tickets via the CWRMM Ticket Management for Monitors workflow, and optionally runs a defragmentation task when remediation is allowed.

The solution offers two operating modes per device:

• AlertOnly – The monitor creates and closes tickets, but no defragmentation is performed.
• AutoFix – The monitor triggers the DRV Frag Autofix task when fragmentation exceeds the threshold. The autofix script attempts defragmentation and manages ticket creation/comments/closure based on the outcome.

Servers are restricted to AlertOnly unless the endpoint-level DRV_Frag_Mode is explicitly Enabled - Autofix; workstations can use either mode at any hierarchy level.

All monitoring settings (mode, drives, threshold) are defined via hierarchical custom fields, resolved daily by the DRV Frag Monitoring Configuration Writer task, and stored in a local JSON file that the monitor and autofix scripts read. The monitor runs hourly; the autofix task is launched only when needed.

Key Capabilities

• Hierarchical Policy Management – Set Company-wide defaults and override them per Site or Endpoint.
• OS-Aware Targeting – Servers and workstations automatically use the appropriate _Svr / _Wks custom fields.
• Flexible Drive Selection – Monitor all drives, none, or specific drive letters (e.g., CDEF).
• Media Type Safety – Only fixed HDDs are analyzed; SSDs, SCM, removable, and unknown media are excluded.
• Automatic Ticket Lifecycle – Creation, comments, and closure are handled via webhooks to the ConnectWise workflow, producing clean tickets without duplicate spam.
• Device-Linked Tickets – The alerting endpoint is associated with the ticket by the Create ticket with associated device bot, which the workflow calls in place of the native Create Ticket action so the device is attached in the same API call that raises the ticket. A native workflow action cannot attach a device to a ticket.
• Automatic Remediation (AutoFix) – Up to 4 defragmentation attempts per incident (initial + 3 retries, 24 hours apart). After the final failed attempt, manual intervention is requested.
• Server Autofix Guard – Servers never autofix unless explicitly enabled at the endpoint level, preventing unintended defragmentation on critical systems.
• Fragmentation Caching – Reduces analysis overhead by storing recent measurements; the autofix script also writes its post‑remediation measurement so the monitor observes changes immediately.
• Concurrency Lock – An Autofix.lock file prevents the monitor from evaluating while remediation is in progress, avoiding state file conflicts.

Important Caveats & Behavior

• Configuration Refresh – The configuration writer task runs daily. Changes to custom fields take effect after the next scheduled run.
• Monitor Interval – Fragmentation is evaluated every hour. A new breach is detected within one hour.
• Threshold Semantics – A drive is considered breached when fragmentation percentage is greater than or equal to the configured threshold.
• Fragmentation Metric – Uses Win32_Volume.DefragAnalysis TotalPercentFragmentation, which differs slightly from the “total fragmented space” reported by defrag.exe. Review thresholds accordingly.
• AlertOnly Reporting – In AlertOnly mode, the monitor returns a failure string only on first detection to launch the autofix task once (which exits immediately). Subsequent cycles return success while the ticket remains open. This prevents repeated autofix launches.
• AutoFix Retry Budget – The maximum number of defragmentation attempts is 4. After that, no further automatic attempts occur; the ticket remains open for manual work.
• Server AutoFix – If a server would resolve to AutoFix but the endpoint override is not Enabled - Autofix, the mode is downgraded to AlertOnly. This is enforced in configuration and again in both scripts.
• Unknown Media – Drives with indeterminate media type are not monitored by default. To include them, set $includeUnknownMediaType = $true in both scripts.
• Ticketing Install Order – The workflow calls a custom bot, so the bot and its form must be installed and published before the workflow is imported. A workflow that references a bot which does not exist in the environment cannot be saved.
• Device Association Scope – The device is attached in the same call that creates the ticket. The Comment and Close actions do not alter the association, so retry comments and closures on an existing ticket leave the original device link intact.

Associated Content

Groups

Name	Purpose
DRV Frag Monitoring - Active	Dynamic group that targets Windows endpoints with monitoring enabled (AlertOnly or AutoFix) based on custom fields. This group receives the configuration writer task, monitor, and autofix automation. Note: Includes servers explicitly set to Enabled - Autofix at the endpoint level, as permitted by the server autofix policy.
DRV Frag Monitoring - Alert Only [Workstations]	View‑only group for workstations configured with AlertOnly mode. Used for reporting and visibility; no automation is applied to this group.

Tasks

Name	Purpose
DRV Frag Monitoring Configuration Writer	Runs daily to resolve hierarchical settings from custom fields and writes the local JSON configuration file. Also validates and stores the ticket webhook URL.
DRV Frag Autofix	Automation task triggered by the monitor when AutoFix is required. Performs defragmentation, manages ticket creation/comments/closure, and respects attempt limits.

Monitor

Name	Purpose
DRV - Frag Monitoring	Runs hourly, reads the local JSON configuration file, evaluates drive fragmentation, manages state files, fires ticket webhooks, and triggers the autofix task when necessary.

Trigger

Name	Purpose
CWRMM Ticket Management for Monitors	Webhook trigger that receives Create / Close / Comment payloads from the monitor and autofix scripts and starts the ticketing workflow.

Workflow

Name	Purpose
CWRMM Ticket Management for Monitors	Creates, comments on, and closes ConnectWise tickets based on webhook payloads. New tickets are raised by the create bot, so the alerting device is attached in the same API call. Required for all ticketing in this solution.

Bot

Name	Purpose
Create ticket with associated device	Custom RPA bot called by the workflow on the toCreate branch, in place of the native Create Ticket action. It raises the ticket with the alerting device attached as its primary asset in a single API call, covering the one operation a native workflow action cannot perform. Must be installed and published before the workflow is imported.

Form

Name	Purpose
Create ticket with associated device	The bot's input form, supplying the company, site, device and ticket details. The bot cannot run without it, and importing the bot brings the form in with it.

Custom Fields: Monitoring Mode

These fields determine whether a device is monitored, and if so, in which mode (AlertOnly or AutoFix). Blank values inherit from the next hierarchy level.

Name	Level	Type	Purpose
DRV_Frag_Mode_Wks	Company	Dropdown	Company baseline for workstation mode.
DRV_Frag_Mode_Svr	Company	Dropdown	Company baseline for server mode.
DRV_Frag_Mode_Wks_Site	Site	Dropdown	Site‑level override for workstation mode.
DRV_Frag_Mode_Svr_Site	Site	Dropdown	Site‑level override for server mode.
DRV_Frag_Mode	Endpoint	Dropdown	Endpoint‑level override for mode.

Custom Fields: Drive Selection

Specify which drive letters to monitor (e.g., All, None, CDEF). Blank inherits.

Name	Level	Type	Purpose
DRV_Frag_Drives_Wks	Company	Text Box	Company baseline for workstation drive selection.
DRV_Frag_Drives_Svr	Company	Text Box	Company baseline for server drive selection.
DRV_Frag_Drives_Wks_Site	Site	Text Box	Site‑level override for workstation drive selection.
DRV_Frag_Drives_Svr_Site	Site	Text Box	Site‑level override for server drive selection.
DRV_Frag_Drives	Endpoint	Text Box	Endpoint‑level override for drive selection.

Custom Fields: Fragmentation Threshold

Numeric percentage (1–100). Blank inherits.

Name	Level	Type	Purpose
DRV_Frag_Threshold_Wks	Company	Text Box	Company baseline for workstation threshold.
DRV_Frag_Threshold_Svr	Company	Text Box	Company baseline for server threshold.
DRV_Frag_Threshold_Wks_Site	Site	Text Box	Site‑level override for workstation threshold.
DRV_Frag_Threshold_Svr_Site	Site	Text Box	Site‑level override for server threshold.
DRV_Frag_Threshold	Endpoint	Text Box	Endpoint‑level override for threshold.

Custom Field: Ticketing Webhook URL

Name	Level	Type	Purpose
Ticket_Mgmt_Webhook_Url	Company	Text Box	Stores the workflow webhook URL. The configuration writer validates it and writes it to the local config file.

Implementation

Follow these steps in order.

Step 1: Create the Custom Fields

Create all 16 custom fields listed above. Ensure the names match exactly (including case and suffix) so that the configuration writer can resolve them correctly.

Step 2: Create the Device Groups

Create the dynamic groups:

• DRV Frag Monitoring - Active – main group receiving all automation.
• DRV Frag Monitoring - Alert Only [Workstations] – view‑only group for reporting.

Step 3: Create the Configuration Writer Task

Set up the DRV Frag Monitoring Configuration Writer task. This task will be scheduled to run daily against the Active group. It reads custom fields and writes the local JSON configuration file.

Step 4: Create the Autofix Task

Create the DRV Frag Autofix automation task. It will be linked to the DRV - Frag Monitoring monitor and triggered by failure strings.

Step 5: Create the Monitor

Import the DRV - Frag Monitoring monitor. Configure it to run hourly against the Active group, with criteria Contains → Failure:. In the monitor's Add Automation section, link the DRV Frag Autofix task.

Step 6: Set Up the Ticketing Workflow, Trigger, Bot, and Form

The solution requires the CWRMM Ticket Management for Monitors workflow and its trigger to handle ticket actions, plus the create bot and its form so each new ticket is raised with the alerting device attached. Complete the following in order — the bot must exist before the workflow is imported, because a workflow cannot be saved while it references a bot that is not present in the environment.

1. Install the Create ticket with associated device form from the ProVal - Content Community, selecting the Forms repository. Installing the bot in the next step brings the form with it, so this step is only needed if you are installing the form on its own.
2. Install the Create ticket with associated device bot from the ProVal - Content Community, selecting the Bots repository, then publish the bot. (See the bot document's Implementation section.)
3. Install the workflow and trigger from the Community (if not already present).
4. In the workflow's Trigger node, create a webhook instance named CWRMM Ticket Management for Monitors and copy the generated URL.
5. Set that URL as the Default Value of the Ticket_Mgmt_Webhook_Url custom field.
6. Open the Bot node on the workflow's toCreate branch and set ServiceBoard, Priority and Team to match your environment. These replace the Service Board and assignment settings that a native Create Ticket action would have carried. (See the workflow document's Configure the Bot Action section.)
7. Verify the workflow is published.

Step 7: Schedule the Configuration Writer

Schedule the DRV Frag Monitoring Configuration Writer task to run daily against the Active group. The monitor and autofix task require no explicit schedule; they run based on monitor criteria and trigger linkage.

Step 8: Configure Custom Field Values

Set the appropriate monitoring mode, drive selection, and threshold for your companies, sites, and endpoints:

• Company level: Set DRV_Frag_Mode_Wks / DRV_Frag_Mode_Svr to Disabled (or the desired baseline), DRV_Frag_Drives_* to All / C, and DRV_Frag_Threshold_* to 30 (or your preference).
• Site/Endpoint overrides: Use the Site and Endpoint fields to override settings where needed.
• To enable monitoring for a device, set the mode field (Company, Site, or Endpoint) to Enabled - Alert Only or Enabled - Autofix (for workstations) / Enabled - Alert Only (for servers, unless endpoint explicit Enabled - Autofix).

Step 9: Verify Operation

Run the configuration writer manually on a test device, then wait for the next monitor cycle. Confirm the configuration file appears in C:\ProgramData\_Automation\Script\DRVFragmentationMonitoring\. Check the monitor output and the ConnectWise ticket queue, and confirm the alerting device is attached to the ticket that was created.

FAQ

Q: How does the fragmentation monitoring work?

A local JSON configuration file is written daily by the configuration writer task. The monitor reads this file hourly, enumerates eligible fixed HDDs, applies drive selection filters, and compares fragmentation against the threshold. If a drive breaches the threshold and the mode is AlertOnly, a ticket is created via webhook. If the mode is AutoFix, the monitor returns a failure string, which triggers the autofix task to defragment the drive.

Q: What is the difference between AlertOnly and AutoFix modes?

• AlertOnly – The monitor creates a ticket when fragmentation exceeds the threshold and closes it when the drive recovers. No defragmentation is performed.
• AutoFix – The monitor triggers the autofix task, which attempts defragmentation. If the first attempt fails, a ticket is created; subsequent failures add comments; after the 4th failed attempt, a final comment is added and automatic remediation stops. If the drive recovers, the ticket is closed.

Q: Is the alerting device attached to the ticket?

Yes. A native workflow action cannot attach a device to a ticket, so the workflow calls the Create ticket with associated device bot in place of the native Create Ticket action, and the device travels in the same API call that raises the ticket. This is deliberate: a device attached by a separate follow‑up call does not carry through to the configuration on the ticket once it syncs to CW Manage, while a device supplied at creation does. If the bot or its form is missing or unpublished, no ticket is created at all and the monitor logs the webhook failure.

Q: The device is attached in CW RMM but the configuration is missing on the CW Manage ticket. Why?

This is the failure mode the create bot exists to avoid. A device attached to a ticket by a separate follow‑up call does not carry through to the configuration once the ticket syncs to CW Manage, while a device supplied in the original create call does. If you see it, confirm the workflow's toCreate branch calls the Create ticket with associated device bot rather than creating the ticket natively and attaching the device in a later step.

Q: Why are servers restricted to AlertOnly by default?

Servers are effectively restricted to AlertOnly in this solution. The dynamic group that receives the automation tasks (the DRV Frag Monitoring - Active group) only includes servers whose effective mode is AlertOnly—whether that value comes from the Company, Site, or Endpoint level. Servers with endpoint‑level DRV_Frag_Mode set to Enabled - Autofix are excluded from the group, so they never receive the configuration writer, monitor, or autofix task. The configuration writer still contains a server autofix policy as a safeguard, but because such servers are not in the group, it is never applied. Therefore, the automated solution never performs defragmentation on servers.

Q: How many defragmentation attempts are made?

Up to 4 attempts per incident: the initial attempt plus 3 retries, spaced 24 hours apart. After the 4th failed attempt, no further automatic attempts occur; the ticket remains open for manual intervention.

Q: Will the ticket close automatically when fragmentation drops below the threshold?

Yes. If the drive recovers, the monitor (or autofix script, depending on the scenario) sends a Close webhook to the workflow. The ticket is closed automatically.

Q: I changed a custom field. When will it take effect?

The configuration writer task runs daily. Changes take effect after the next scheduled run. You can manually run the task to apply changes immediately.

Q: Why are SSDs not monitored?

Defragmenting SSDs is unnecessary and can reduce their lifespan. The solution uses MSFT_PhysicalDisk.MediaType to identify HDDs (value 3) and excludes SSDs (value 4) and SCM (value 5). Unknown media is also excluded by default.

Q: Can I monitor only the C: drive?

Yes. Set the appropriate DRV_Frag_Drives field (Company, Site, or Endpoint) to C.

Q: How do I enable monitoring for a device?

• Workstations – Set the mode field at the desired hierarchy level to Enabled - Alert Only or Enabled - Autofix. The device will then be included in the Active group and receive all automation.
• Servers – Set the mode field to Enabled - Alert Only at any level (Company, Site, or Endpoint). Setting a server to Enabled - Autofix (even at the endpoint) will exclude it from the Active group, so no monitoring will occur for that server. Use AlertOnly for all server monitoring.

Q: The monitor output says "Configuration file not found." What should I do?

The configuration writer task hasn’t run yet. Run DRV Frag Monitoring Configuration Writer manually or wait for the next daily schedule.

Q: The autofix task ran but didn’t defragment. Why?

Check the mode in the configuration file. If it’s AlertOnly or Disabled, the autofix script exits immediately. Also verify that the drive is eligible (fixed HDD, included in drive selection, media type known) and that fragmentation is actually above the threshold.

Q: What happens if the webhook URL is missing or invalid?

The configuration writer leaves TicketWebhookUrl empty. The monitor and autofix scripts will skip ticket webhooks and log warnings. State files still track the incident, and webhooks will be retried once a valid URL is configured.

Q: Can I edit the configuration file manually?

Manual changes will be overwritten by the next configuration writer run. Always adjust custom fields to ensure consistency.

Q: The workflow is not creating or closing tickets. What should I check?

Work through this checklist:

1. The Ticket_Mgmt_Webhook_Url custom field contains the real webhook instance URL (not the placeholder).
2. A webhook instance was created in the workflow's trigger and the URL was copied from it.
3. The workflow is installed, published, and its Create Ticket action is configured with a valid Service Board.
4. The bot is installed and published with its form attached, and the bot node on the toCreate branch has its ServiceBoard, Priority and Team set.
5. The configuration writer task was run after the URL was set, so the config file contains the real URL.
6. The user who created the workflow has access to the affected device (see the workflow document for permission requirements).
7. Check the monitor or autofix script output for webhook failure messages.

Q: Why does the workflow work on some machines but not others?

The workflow executes under the context of the user account that created it. If that user lacks permission to a specific device, ticket creation or closure will silently fail for that endpoint. Create the workflow with a user that has access to all devices you intend to monitor.

Q: What does the workflow do with the Comment action?

For Comment, the workflow retrieves all open tickets matching the subject and device, and adds a note containing the body from the payload. It does not close the ticket, and it does not change the device association. This is used by the autofix script to add retry comments after failed remediation attempts.

Q: Will the workflow ever create duplicate tickets?

The workflow itself does not check for existing tickets; it creates a new ticket whenever it receives a Create action. Duplicate prevention is entirely the responsibility of the monitor and autofix scripts, which use state files to ensure Create is sent only once per incident.

Q: I have both the Active group and the Alert Only [Workstations] group. Why isn't a workstation with AlertOnly appearing in the Active group?

The Active group includes workstations with either Enabled - Alert Only or Enabled - Autofix. The Alert Only [Workstations] group is a view‑only subset; a workstation in AlertOnly mode should appear in both groups. If it is missing from Active, check the group criteria and custom field inheritance (Endpoint → Site → Company). Common mistakes: a Site or Endpoint field has Disabled, overriding a higher-level enablement.

Q: Can I run the configuration writer more than once a day?

Yes. The scheduled task runs daily, but you can manually execute it at any time to apply immediate changes to the configuration file.

Q: What happens if the fragmentation cache file grows too large?

The cache file stores one entry per drive letter (maximum 26 entries) and is overwritten on each monitor cycle with the current cache list. It does not grow indefinitely.

Q: Does the solution monitor network drives or removable drives?

No. Only local fixed disks (DriveType = 3) that are rotational HDDs are considered. Network, removable, optical, and unknown media are excluded.

---

Changelog

2026-09-07

• Device Association: The CWRMM Ticket Management for Monitors workflow now raises new tickets through the Create ticket with associated device bot instead of the native Create Ticket action, so the alerting device is attached in the same API call. A device attached by a separate follow‑up call does not carry through to the configuration on the CW Manage synced ticket, while a device supplied at creation does.
• New Components: Added the Create ticket with associated device bot and its form to Associated Content and to the Implementation steps.
• Install Order: Step 6 now installs the bot before the workflow, because a workflow referencing a bot that is not present in the environment cannot be saved.
• Configuration Moved: The service board, priority and team for new tickets are now set on the workflow's bot node rather than in a Create Ticket action.
• Added FAQ entries covering device association and the CW Manage configuration sync.

2026-08-26

• Initial version of the document.