Windows patching is often described as an installation problem: identify updates, deploy them, reboot systems, and confirm success. In a multi-client managed-services environment, installation is only one stage of a much larger operating process.
Before patching begins, engineers must determine what Microsoft released, which operating systems are affected, whether known issues introduce unacceptable risk, whether security advisories change the urgency, and whether the planned maintenance window remains appropriate. After execution, the organization must determine which devices were reached, which updates were installed, which systems require a reboot, which devices failed, and whether enough evidence exists to demonstrate that the service was delivered.
I designed a patch intelligence and assurance capability to connect those stages. The platform centralizes research, preserves human approval, supports different patch-execution tools, normalizes endpoint results into a shared evidence contract, and generates a consistent interactive report for operational review and client delivery.
The Real Problem Was Fragmented Decision-Making
When every engineer independently researches the same monthly updates, the organization pays for the same investigation repeatedly. Conclusions may differ because people use different sources, interpret advisories differently, or overlook operating systems that are not present in their usual client environments.
Execution created another form of fragmentation. Some clients were patched through an endpoint-management platform. Others were patched through Ansible Automation Platform or Semaphore using custom playbooks. Each tool exposed different data and collection mechanisms, even though the business needed the same answers after every maintenance window.
- What Windows systems were in scope?
- Which updates were applicable this month?
- Were there known issues or relevant security advisories?
- Which devices were successfully patched?
- Which updates remain missing?
- Which systems are pending reboot or require remediation?
- Can the result be presented consistently regardless of execution tool?
The architectural opportunity was to treat those questions as one governed lifecycle rather than separate scripts and reports.
Architecture at a Glance
Retrieve monthly update, known-issue, and security-advisory information.
Engineers select relevant operating systems and review current risk.
NinjaOne, SCCM/WSUS, AAP, or Semaphore performs the authorized maintenance work.
Tool-specific output is transformed into a common evidence schema.
Interactive reports support review, client delivery, and exception handling.
Centralizing Patch Intelligence
A scheduled Azure DevOps pipeline runs a PowerShell collection process each week. The process retrieves current Windows update information, known issues, and security advisories, then maps the results to supported Windows operating systems and produces an interactive HTML report.
The report is published through a dedicated Patch Intelligence SharePoint site within the broader service-assurance and governance platform. Engineers can select operating systems such as Windows Server 2025 and immediately narrow the report to the information that matters for their assigned clients:
- KBs released for the current patch cycle
- Known issues associated with those updates
- Relevant security advisories and vulnerability context
- Microsoft support and release-information references
This does not automatically declare an update safe. The pipeline reduces collection and correlation effort; authorized engineers retain responsibility for interpreting the evidence and approving the patching decision.
Why an Interactive HTML Report
A custom application and database could provide richer search, historical analytics, and workflow state. That would also introduce an application runtime, data model, authentication layer, deployment lifecycle, monitoring requirements, and additional operational ownership.
The current workload is read-heavy and published on a predictable cadence. A generated HTML artifact is inexpensive, portable, easy to host in the existing SharePoint experience, and capable of performing client-side filtering without another application service. For this stage of the platform, that tradeoff delivers most of the required value with very little infrastructure.
One Governance Model, Multiple Execution Platforms
The execution layer intentionally supports more than one tool. One client environment uses NinjaOne, another may use SCCM or just WSUS, while other environments use Ansible Automation Platform or Semaphore with custom Windows patching playbooks.
| Execution Path | Evidence Source | Normalization Path |
|---|---|---|
| NinjaOne | A custom device attribute stores patching results for each managed endpoint. | A PowerShell process retrieves device attribute values through the API and exports the shared CSV structure. |
| SCCM | A custom SCCM script collects patching results and device information for each managed endpoint. | A PowerShell script retrieves the JSON formatted script output results from SCCM and exports the shared CSV structure. |
| AAP / Semaphore | Ansible gathers the corresponding facts and patch results directly from remote Windows hosts. | The playbook output is written into the same CSV structure used by the NinjaOne workflow. |
The common CSV contract is the boundary between execution and reporting. The report generator does not need to understand how each platform installs updates. It only needs a consistent evidence schema.
The Common Evidence Contract
The normalized dataset represents the operational facts required for review. Exact production fields vary, but the model includes concepts such as:
- Client and device identity
- Operating-system name and version
- Collection and maintenance timestamps
- Installed updates and remaining applicable updates
- Last boot information and reboot state
- Overall patch outcome
- Exceptions, collection failures, and remediation notes
- Source execution platform
NinjaOne custom attribute ─┐
├─> Normalized CSV ─> Interactive HTML report
Ansible host evidence ─────┘This pattern decouples the client deliverable from the automation platform. A client can move between execution tools without requiring a new reporting architecture, and additional tools can be integrated by producing the same contract.
Client Reporting as Operational Evidence
A separate PowerShell process transforms the normalized CSV into an interactive HTML report. The report presents summary status, device-level results, filtering, installed and missing updates, reboot requirements, and exceptions in a format suitable for post-maintenance review.
Consistency matters. If the client-facing deliverable changes completely depending on whether the work ran through NinjaOne or Ansible, internal review becomes harder and the service experience becomes tool-dependent. A shared report provides the same interpretation layer across both paths.
The report is not merely a prettier log. It is a curated evidence product that helps answer whether the patching obligation was fulfilled and where follow-up work remains.
Integration with Service Assurance and Governance
The Patch Intelligence site is one component of a broader service-assurance and governance system built across several connected SharePoint sites and automation services. Patching begins as a service responsibility, becomes scheduled operational work, passes through intelligence and approval, executes through an appropriate platform, and ends with evidence and exceptions.
Service obligation
↓
Recurring maintenance responsibility
↓
Patch intelligence and risk review
↓
Authorized execution
↓
Endpoint evidence collection
↓
Normalized client report
↓
Exception remediation and proof of deliveryThis closes an important gap between task completion and assurance. A completed automation job does not necessarily mean every endpoint was reached, every applicable update was installed, or every exception was resolved.
Security and Trust Boundaries
- Source integrity: intelligence is collected from authoritative vendor sources and preserved with relevant references.
- Credential handling: automation credentials and API tokens are kept out of generated reports and source-controlled configuration.
- Least privilege: API access and remote collection permissions should be limited to the operations required by each integration.
- Client isolation: evidence is processed and delivered within the appropriate client context.
- Data minimization: client reports include operationally relevant patch evidence without exposing unrelated system information.
- Human authorization: intelligence informs the decision, but automation does not silently accept patch risk on behalf of the organization.
Reliability: Distinguishing Failure Types
A mature assurance model must distinguish between different kinds of failure:
| Failure | Meaning | Required Response |
|---|---|---|
| Intelligence collection failure | The platform could not retrieve or interpret a source. | Block or qualify the research result and investigate the pipeline. |
| Patch execution failure | The execution platform reported an installation or reboot error. | Create or assign remediation work. |
| Evidence collection failure | The endpoint result could not be retrieved or normalized. | Treat the device state as unknown rather than successful. |
| Report generation failure | Evidence exists, but the client deliverable was not produced. | Regenerate from the normalized dataset without repeating patch execution. |
| Business reconciliation failure | Expected devices or obligations are missing from the final evidence. | Reconcile scope against service and inventory records. |
Separating these states prevents a reporting problem from being mistaken for a patching failure and prevents missing evidence from being interpreted as success.
Architectural Tradeoffs
- CSV as the interchange contract: simple, transparent, and portable, but weaker than a versioned schema and durable data service for concurrency, history, and relational queries.
- Generated HTML: inexpensive and easy to distribute, but less capable than a continuously available analytics application.
- Weekly intelligence collection: appropriate for the operational cadence, but urgent out-of-band advisories may require an additional trigger.
- Custom NinjaOne attributes: make evidence accessible through the management platform, but require freshness checks so stale data is not mistaken for current results.
- Direct Ansible collection: provides current host evidence, but offline or unreachable systems must remain explicit exceptions.
- Human approval: preserves accountability and client context, but requires clear ownership and timely execution.
How I Would Evolve the Platform
- Define and version the common evidence schema.
- Add automated reconciliation between expected maintenance scope and reported endpoints.
- Track intelligence source freshness and visibly mark partial collection.
- Persist historical results for trend analysis and recurring exception detection.
- Generate work items automatically for unresolved patch and evidence exceptions.
- Add signed or hashed report artifacts where stronger evidence integrity is required.
- Measure research time saved, reporting time saved, endpoint coverage, and remediation closure.
- Introduce a durable API or data platform when history, concurrency, or cross-client analytics justifies the additional complexity.
What This Project Demonstrates
The important result is not a particular PowerShell script, Ansible playbook, SharePoint page, or endpoint-management product. It is an operating model that connects research, risk acceptance, execution, evidence, reporting, and follow-up.
The platform allows shared intelligence to be collected once and reused across teams. It allows different patching tools to participate in the same assurance lifecycle. It gives client reporting a stable contract rather than coupling it to the current execution platform. Most importantly, it makes exceptions visible instead of allowing automation success to substitute for proof.
Lessons Learned
- Patching is a governance problem as much as an installation problem.
- Centralized intelligence reduces duplicated research and inconsistent decisions.
- Automation should inform human risk decisions, not conceal them.
- A common evidence contract decouples reporting from execution tooling.
- Unknown is a valid operational state. Missing evidence must not be treated as success.
- Client reporting is part of service delivery. Logs alone do not communicate outcomes effectively.
- Tool independence is created at system boundaries. The normalization layer is more durable than any individual integration.
- Completion and assurance are different. A successful job still requires reconciliation against expected scope.
Final Thoughts
What should be patched?
↓
What risk is known?
↓
Who authorizes execution?
↓
Which platform performs the work?
↓
What evidence did each endpoint return?
↓
Can the organization prove the obligation was fulfilled?
↓
What exceptions still require ownership?Those are not NinjaOne questions or Ansible questions. They are questions about governance, platform architecture, operational evidence, and accountable service delivery.
Tags: Patch Governance, Patch Intelligence, Windows Patching, Platform Engineering, PowerShell, Ansible Automation Platform, Semaphore, NinjaOne, SharePoint, Azure DevOps, Service Assurance, Security Operations, Reporting Automation
Published: September 29, 2026
Author: Robert H. Osborne
