We recently used that capability while investigating a workstation issue that could potentially affect multiple devices. Manually inspecting every computer would have been slow and, more importantly, would have produced inconsistent results.
Instead, we began treating Intune as the distribution layer for a lightweight endpoint data-collection system. PowerShell performs the local inspection, the results are written as structured data, and Azure provides a centralized location where those results can be reviewed.
The pattern is simple, but it opens up some useful possibilities for IT operations.
The Problem With Troubleshooting One PC at a Time
Traditional workstation troubleshooting is usually reactive.
A user reports a problem. IT connects to the machine, checks logs, runs commands, inspects installed software and hopefully identifies the cause.
That works well for a single incident.
It becomes much less effective when the question changes from:
"What is wrong with this computer?"
to:
"Do any of our other computers have the same condition?"
At that point, remote sessions and screenshots don't scale particularly well. Even if every device is checked, small differences in how the investigation is performed can make the resulting information difficult to compare.
For the endpoint issue we were investigating, we wanted to inspect runtime-related information across a larger group of Windows devices. Some machines were known to have experienced the issue. Others had not.
That distinction was valuable. We didn't just need information from broken computers. We needed a baseline from the broader environment.
Intune Already Solves the Distribution Problem
If the computers are already managed by Microsoft Intune, much of the infrastructure needed for this kind of investigation already exists.
Intune can deliver PowerShell to managed Windows endpoints without requiring an administrator to establish an interactive remote session with every computer.
That makes it possible to standardize the collection logic.
Instead of asking a technician to run several commands manually, the script can determine exactly what information should be inspected, normalize the result and produce the same output structure on every endpoint.
The architecture we used follows a straightforward flow:
Microsoft Intune → Windows endpoint → PowerShell collector → JSON result → Azure Blob storage
Each component has a narrow responsibility.
Intune determines where the collector runs.
PowerShell performs the local inspection.
JSON provides a predictable data format.
Azure provides a central destination for the results.
That separation keeps the system relatively easy to understand and adapt.
Collect Data, Not Screenshots
One of the most important design choices was producing structured output rather than relying on conventional text logs.
Human-readable logs are useful during troubleshooting, but they become cumbersome when information needs to be compared across many devices.
JSON gives each collected value a defined place.
A health record can include information such as:
- Device identity
- Collection timestamp
- Operating system details
- Installed software or component versions
- Architecture-specific information
- Relevant DLL or file versions
- Other health indicators needed for the particular investigation
The exact fields depend on the problem being investigated.
The important part is consistency.
If every device reports the same schema, comparing endpoint state becomes substantially easier than reading individual logs.
It also means the collector can evolve. New health checks can be added without redesigning the entire delivery mechanism.
Centralizing the Results in Azure
Collecting data locally only solves half the problem.
The results need somewhere to go.
For this project, we used Azure Blob storage as the centralized destination for endpoint health records. Each device can submit its structured result so that the data can be reviewed without reconnecting to the endpoint.
This creates an important separation between collection and analysis.
The endpoint does not need to determine whether it is "good" or "bad." Its job can simply be to report what it sees.
The central side can then compare those observations.
That is especially useful during an investigation because the definition of an unhealthy system may change as more evidence becomes available.
A version that initially looks suspicious, for example, may turn out to be widespread on completely healthy devices. Conversely, a component difference that seemed insignificant on one computer may become much more interesting when it appears consistently across affected systems.
Collecting facts first preserves that flexibility.
Start Read-Only
We deliberately approached the initial collector as a read-only tool.
This is an important distinction.
Once PowerShell is being distributed across a fleet, it would be technically possible to combine detection and remediation: find an unexpected condition and immediately change it.
But doing so during an investigation can destroy some of the evidence you're trying to collect.
There is also a significant difference between having confidence in a repair on one affected workstation and having enough evidence to automatically perform that repair across many endpoints.
A safer progression is:
Observe → compare → understand → remediate
First determine what the environment actually looks like.
Then identify which characteristics correlate with the problem.
Once a reliable condition has been established, remediation can be evaluated separately.
This also reduces the risk of turning a diagnostic script into an unintended configuration-management system.
Before-and-After Data Is Particularly Valuable
Endpoint collection becomes even more useful when a known repair is involved.
If a device is captured while it is experiencing a problem, repaired, and then captured again, those two records provide a controlled comparison.
Instead of documenting that "the repair worked," IT can examine what changed in the machine's reported state.
During our runtime investigation, this became particularly useful because we could collect health data before performing a successful repair and then compare the endpoint afterward.
That provides a reference for evaluating other devices.
The technique is broadly applicable.
For example, the same pattern could be useful when investigating differences in installed components, software versions or other machine-level configuration where the state before and after remediation matters.
Collection Cadence Matters
There is also a difference between inventory and monitoring.
A one-time script answers:
What did this computer look like when the script ran?
Repeated collection begins to answer:
How is this computer changing over time?
That distinction matters when diagnosing conditions that may recur.
A device can look perfectly healthy immediately after remediation. If the same component later changes, a historical record becomes much more useful than a single snapshot.
The appropriate cadence depends on what is being observed. Not every piece of endpoint information needs frequent collection, and more data is not automatically better.
The objective should be to collect information often enough to answer a specific operational question without generating unnecessary endpoint activity or an unmanageable volume of records.
Assignment Groups Make the Model Expandable
Intune assignment also makes it possible to start small.
A collector can initially target a limited set of test devices. Once its output has been validated, the assignment can expand to additional managed computers.
That is preferable to designing every diagnostic tool as an immediate fleet-wide deployment.
It also allows devices to be added later without rebuilding the underlying collection process. The deployment mechanism and the health logic remain separate from the list of endpoints being evaluated.
That is useful when an investigation evolves from one affected workstation to several, and eventually to the question of whether an entire managed environment should be checked.
Security Still Matters for Diagnostic Tools
A read-only collector may sound low-risk because it isn't changing endpoint configuration, but centralized reporting introduces its own security considerations.
Endpoints need a controlled mechanism for submitting results to the destination, and that access should be limited to what the collector actually requires.
Credentials or access mechanisms embedded in deployment scripts also need to be treated as credentials, not as harmless configuration simply because the script is distributed through a management platform.
The same principle applies to the data itself.
Collect only what is necessary to answer the operational question.
A runtime-health investigation, for example, does not require collecting user documents or unrelated personal information. Device identity, component versions and relevant system state may be sufficient.
Good monitoring starts with deciding what you do not need to collect.
Monitoring Does Not Have to Mean Another Agent
Organizations already have plenty of endpoint agents.
Security software, remote-management platforms, update tools and application-specific services can all add processes and complexity to a workstation.
For targeted operational questions, another permanently installed agent may not be necessary.
If Intune is already managing the endpoint and PowerShell can inspect the required local state, a lightweight collector may be enough.
That doesn't make Intune a replacement for a full monitoring or RMM platform. Those systems solve much broader problems.
It does mean that organizations should consider the capabilities already available in their Microsoft environment before introducing another endpoint component for a narrowly defined requirement.
Turning Troubleshooting Into Telemetry
The most useful lesson from this work was the shift in perspective.
We began with a technical problem on individual Windows computers. The immediate objective was troubleshooting.
But once we had a repeatable way to inspect the relevant machine state, the same work became a telemetry problem.
The progression was straightforward:
Identify a useful diagnostic → automate the diagnostic → standardize its output → distribute it through Intune → centralize the results
That is a reusable engineering pattern.
The next time an issue appears on a workstation, the question does not necessarily have to be, "Can we remote into another computer and check?"
It can become, "Can the managed devices tell us?"
Why This Matters
Microsoft Intune becomes more useful when it is treated as part of an operational platform rather than simply the place where device policies are configured.
It already has a trusted relationship with managed Windows endpoints. PowerShell provides access to a large amount of local system information. Azure provides straightforward options for centralizing structured results.
Combined carefully, those pieces can help IT teams investigate fleet-wide questions using consistent evidence.
The important part is keeping the purpose narrow.
Collect the data needed to answer a real question. Keep diagnostic collection separate from remediation until the evidence supports making changes. Use structured output so that results can be compared. Protect the reporting path. Expand deployments deliberately.
Those practices are more important than the individual PowerShell commands involved.
Next Steps
The runtime-health project that prompted this approach is one example of a broader opportunity.
The same collection model can be adapted when there is a legitimate need to understand a particular aspect of managed Windows endpoint state. Rather than beginning with a new agent or a series of manual remote sessions, organizations already using Microsoft Intune can first ask whether their existing management infrastructure can provide the visibility they need.
For CBITS, that means continuing to treat endpoint management and troubleshooting as connected disciplines: solve the immediate problem, but also look for the repeatable process that makes the next investigation faster, safer and easier to understand.