Stop the WMI Repair Ticket Loop with Proactive Remediation

#The Old Way vs the New Way

The old way looks like this: a user opens Software Center or the Company Portal, clicks install, and gets a spinning wheel followed by a failure. The technician remotes in, checks the Software Center log, sees a WMI-related error code, opens an elevated command prompt, runs winmgmt /verifyrepository, confirms corruption, runs the repair manually, reboots the machine, and closes the ticket. Three days later the same user, or someone on the same image, raises the same ticket. Multiply that by a fleet of ten thousand endpoints and you have a permanent, low-grade drain on L1 and L2 capacity that never shows up as a single big incident but quietly eats hours every week.

The new way removes the human from the diagnostic loop entirely. A scheduled, SYSTEM-context script pair runs on every managed endpoint, silently checks WMI repository health, and repairs it before the failure ever reaches a user’s screen. The ticket is engineered out of existence because the fault is corrected before the symptom is generated. This article builds that pipeline using Microsoft Intune Proactive Remediations, backed by a Microsoft Graph API deployment so the whole thing is version-controlled and repeatable rather than a one-off console click.

#Prerequisites and Permissions

• Microsoft Intune tenant with Endpoint analytics / Proactive remediations enabled (requires Windows Enterprise E3/E5, Microsoft 365 E3/E5, or the Intune Suite add-on).
• An account assigned the Intune Administrator role, or a custom Endpoint Security Manager role with Microsoft.Intune/DeviceHealthScripts read/write permission, for building and assigning script packages.
• Application permission DeviceManagementConfiguration.ReadWrite.All on an app registration if you deploy via Graph API rather than the portal.
• PowerShell 5.1 or later on target endpoints (default on Windows 10 1607 and later).
• A pilot Azure AD security group, for example Ring0-WMI-Pilot, containing no more than fifty non-critical devices for the first fourteen days.
• Read access to the Log Analytics workspace or Intune run reports used for monitoring remediation outcomes.

#Implementation Steps

1. Action: Write the detection script that checks WMI repository consistency without making changes.

   Expected result: Exit code 0 when the repository is consistent, exit code 1 when corruption is detected, triggering the paired remediation script.

   Evidence to capture: The console output line and exit code from a manual test run on a known-bad pilot device.

   Terminal

   1# Detect-WmiRepositoryHealth.ps1
   2# Run as SYSTEM via Intune Proactive Remediations
   3
   4try {
   5    $verify = winmgmt /verifyrepository 2>&1
   6    Write-Output "WinMgmt output: $verify"
   7
   8    if ($verify -match "inconsistent") {
   9        Write-Output "WMI repository is INCONSISTENT - remediation required"
   10        exit 1
   11    }
   12    elseif ($verify -match "consistent") {
   13        Write-Output "WMI repository is healthy"
   14        exit 0
   15    }
   16    else {
   17        Write-Output "Unable to parse winmgmt output - flagging for remediation as a precaution"
   18        exit 1
   19    }
   20}
   21catch {
   22    Write-Output "Detection script error: $($_.Exception.Message)"
   23    exit 1
   24}

   Expected output on a healthy device:

   Terminal

   1WinMgmt output: WMI repository is consistent
   2WMI repository is healthy

2. Action: Write the remediation script that repairs the repository in the least destructive way first, escalating only if required.

   Expected result: Repository is salvaged, or reset if salvage fails, WinMgmt service restarts cleanly, and a registry timestamp is written for audit purposes.

   Evidence to capture: The registry key value and the Application event log entry for WinMgmt service restart, timestamped to the run.

   Terminal

   1# Remediate-WmiRepositoryHealth.ps1
   2# Run as SYSTEM via Intune Proactive Remediations
   3
   4$logPath = "C:\\ProgramData\\KBYRemediation\\wmi-repair.log"
   5New-Item -ItemType Directory -Path "C:\\ProgramData\\KBYRemediation" -Force | Out-Null
   6
   7function Write-Log {
   8    param($Message)
   9    $stamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
   10    "$stamp $Message" | Out-File -FilePath $logPath -Append -Encoding utf8
   11}
   12
   13try {
   14    Write-Log "Attempting salvage repair"
   15    $salvage = winmgmt /salvagerepository 2>&1
   16    Write-Log "Salvage output: $salvage"
   17
   18    Start-Sleep -Seconds 15
   19    $recheck = winmgmt /verifyrepository 2>&1
   20
   21    if ($recheck -notmatch "consistent") {
   22        Write-Log "Salvage insufficient - performing full reset"
   23        Stop-Service Winmgmt -Force -ErrorAction SilentlyContinue
   24        winmgmt /resetrepository
   25        Start-Service Winmgmt
   26    }
   27
   28    Restart-Service Winmgmt -Force
   29    Start-Sleep -Seconds 10
   30
   31    $final = winmgmt /verifyrepository 2>&1
   32    Write-Log "Final verification: $final"
   33
   34    New-Item -Path "HKLM:\\SOFTWARE\\KBYTechnologies\\WmiRemediation" -Force | Out-Null
   35    Set-ItemProperty -Path "HKLM:\\SOFTWARE\\KBYTechnologies\\WmiRemediation" -Name "LastRunUtc" -Value (Get-Date).ToUniversalTime().ToString("o")
   36    Set-ItemProperty -Path "HKLM:\\SOFTWARE\\KBYTechnologies\\WmiRemediation" -Name "Outcome" -Value $final
   37
   38    if ($final -match "consistent") {
   39        Write-Log "Remediation successful"
   40        exit 0
   41    }
   42    else {
   43        Write-Log "Remediation failed - manual escalation required"
   44        exit 1
   45    }
   46}
   47catch {
   48    Write-Log "Remediation script error: $($_.Exception.Message)"
   49    exit 1
   50}

3. Action: Package both scripts as a Proactive Remediation script pair in the Intune admin center under Reports > Endpoint analytics > Proactive remediations > Create script package.

   Expected result: A script package exists with run context set to SYSTEM, “run script in 64-bit PowerShell” enabled, and both scripts attached.

   Evidence to capture: The generated script package ID from the portal URL or Graph response.

4. Action: Create the same script package via Microsoft Graph so the definition lives in source control rather than only in the portal.

   Expected result: A 201 Created response containing the new deviceHealthScript object ID.

   Evidence to capture: The full JSON response body saved to your automation repository’s deployment log.

   JSON payload

   1{
   2  "displayName": "WMI Repository Health - Detect and Repair",
   3  "description": "Detects and repairs a corrupted WMI repository before Software Center or Intune app installs fail.",
   4  "publisher": "KBY Technologies - Ops Playbook",
   5  "runAsAccount": "system",
   6  "enforceSignatureCheck": false,
   7  "runAs32Bit": false,
   8  "detectionScriptContent": "BASE64_ENCODED_DETECTION_SCRIPT",
   9  "remediationScriptContent": "BASE64_ENCODED_REMEDIATION_SCRIPT",
   10  "roleScopeTagIds": ["0"]
   11}

5. Action: Assign the script package to the pilot group with an eight-hour recurring schedule.

   Expected result: The Intune run summary shows scheduled executions across the pilot ring within the first schedule window.

   Evidence to capture: A screenshot or exported CSV of the per-device run status showing detection and remediation counts.

6. Action: Forward remediation outcomes to your Log Analytics workspace by writing to the standard Intune telemetry pipeline, which already surfaces script results, or by shipping the local log file via your existing agent-based log collector.

   Expected result: A Kusto query against the remediation table returns events matching the registry timestamp written in step 2.

   Evidence to capture: The query result set, including device name, outcome, and timestamp.

   Terminal

   1# Sample KQL run against the Log Analytics workspace
   2DeviceHealthScriptResults
   3| where ScriptName == "WMI Repository Health - Detect and Repair"
   4| where TimeGenerated > ago(7d)
   5| summarize Remediated = countif(RemediationOutcome == "Success"),
   6            Failed = countif(RemediationOutcome == "Failure")
   7            by bin(TimeGenerated, 1d)

7. Action: After seven clean days in the pilot ring with zero regressions, reassign the script package to production device groups in waves of twenty-five percent per day.

   Expected result: Fleet-wide coverage within a working week, with the run report showing a declining remediation-needed percentage as corrupted repositories are cleared out.

   Evidence to capture: Daily coverage percentage exported from the Intune run report.

8. Action: Configure your ticketing system to auto-tag or auto-suppress tickets referencing known WMI-related install failure codes (for example 0x80041002 or 0x8004100E) if a successful remediation event exists for that device within the preceding twenty-four hours.

   Expected result: Matching tickets are automatically closed or annotated rather than routed to a queue.

   Evidence to capture: The auto-closure rule log and a sample resolved ticket showing the correlation.

#Verification and Expected Evidence

Confirm the pipeline is working end to end before trusting it at scale. Pick one device from the pilot ring with a known-corrupted repository and run the detection script manually over PowerShell remoting.

1Invoke-Command -ComputerName PILOT-WKS01 -ScriptBlock {
2    & "C:\\ProgramData\\KBYRemediation\\Detect-WmiRepositoryHealth.ps1"
3}

Expected output before remediation:

1WinMgmt output: WMI repository is inconsistent
2WMI repository is INCONSISTENT - remediation required

Trigger the remediation script directly, then re-run detection. A healthy result plus a populated registry key confirms the loop closed without technician involvement:

Get-ItemProperty -Path "HKLM:\\SOFTWARE\\KBYTechnologies\\WmiRemediation"

Expected output:

1LastRunUtc : 2024-11-04T09:12:47.0000000Z
2Outcome    : WMI repository is consistent

Cross-check the Intune portal run report for the same device and confirm the status reads “Remediated – Success” for the same time window. That three-way match, local registry, event log, and portal report, is your minimum evidence bar for sign-off.

#Rollback

If the remediation script introduces a regression, for example a dependent agent that relies on custom WMI classes losing its provider registration after a repository reset, unassign the script package from the affected group immediately rather than disabling the schedule tenant-wide. This limits blast radius to the group already affected while you investigate.

• Remove the group assignment in Intune admin center > Proactive remediations > select the package > Assignments > remove the target group.
• Re-register any custom WMI providers affected using the vendor’s supplied MOF or registration tool, since /resetrepository returns the repository to its default namespace state and drops non-default provider registrations.
• Communicate the rollback in the change record with the specific device count and the failure signature observed.
• Do not re-enable the schedule for that group until the root cause of the regression is understood and the remediation script has been updated to detect and skip devices running the affected dependent agent.

#Failure and Escalation Conditions

This automation is safe to run unattended within a defined tolerance. The following conditions should wake a human technician rather than being left to retry silently:

• The remediation script exits with code 1 (repair failed) on the same device twice in a row within a 24-hour window.
• WinMgmt service fails to start after a reset, evidenced by Service Control Manager event ID 7000 or 7009 in the System log.
• More than five percent of the pilot ring reports “Remediated – Failure” in a single scheduled run.
• A dependent management agent (SCCM client, monitoring agent, backup
  The KBY Lexicon

  Backup

  A causally disconnected, point-in-time copy of system state, tagged with a consistency marker, that lets you recover from logical corruption or data loss independent of the source system's health.

  Read Full Context
  agent) reports loss of WMI-dependent functionality within one hour of a remediation event on the same device.

Escalate to L3 Windows engineering with the device name, the full content of C:\\ProgramData\\KBYRemediation\\wmi-repair.log, and the Intune run report ID. Minimum permission for the escalated engineer is local administrator plus WMI Control Manager access; no domain-level or Global Administrator rights are required for the repair itself.

#Measuring Ticket Deflection

Establish a baseline before deployment by pulling four weeks of ticket history filtered on categories such as “Software Center install failed”, “App deployment error”, and any ticket text matching WMI-related error codes. Record the weekly average count and the average technician handling time per ticket.

1# Example baseline pull against a ServiceNow instance table export (CSV already retrieved)
2awk -F',' '$3 ~ /0x80041002|0x8004100E|WMI/ {count++} END {print "Baseline weekly tickets:", count/4}' tickets_last_28_days.csv

After the production rollout completes, repeat the same query over the following four-week window and calculate the deflection percentage:

1deflection_pct=$(echo "scale=1; (1 - (post_count / baseline_count)) * 100" | bc)
2echo "Ticket deflection: ${deflection_pct}%"

Track this alongside the Log Analytics remediation success rate so you can attribute deflection to the automation rather than to seasonal ticket volume changes. A realistic target for a mature fleet with a WMI corruption pattern is sixty to eighty percent deflection within the first full reporting month, with the remainder representing genuinely novel failure modes that still warrant human diagnosis.