Create historical reports using Azure Log Analytics and Microsoft Intune diagnostic data
By: Janusz Gal – Sr Product Manager | Microsoft Intune Azure Log Analytics gives Intune admins a flexible way to create custom reports from diagnostic data, especially when you need longer history or tailored calculations that go beyond what the Microsoft Intune admin center’s built-in reports provide. By using the Intune diagnostic data you’re already collecting, you can customize reporting for your organization’s unique requirements. In this post, you’ll walk through the steps to create a 30-day device compliance trend report. The resultant report can be run automatically, used in dashboards, or even further customized for a longer period or with additional data. Before we begin, if you haven’t configured a Log Analytics workspace in your tenant, review the following detailed information on the pre-requisites and costs on Microsoft Learn: Route logs to Azure Monitor using Microsoft Intune. In the Microsoft Intune admin center, navigate to Reports > Diagnostic settings, and add a new Diagnostic setting policy to send data to a Log Analytics workspace. Figure 1 Reports > Diagnostic settings, used to configure new or existing diagnostic settings. For a device compliance trend report, ensure the Devices log category is selected: Figure 2 Reports > Diagnostic settings > Selected configuration; Devices log selected. After configuring the setting, navigate to Reports > under Azure monitor, Log Analytics. Figure 3 Reports > Log Analytics; used to query log Analytics workspaces. In the New Query window, enter the following query: IntuneDevices | where TimeGenerated > ago(30d) | summarize Total = count(), Compliant = countif(CompliantState == "Compliant"), NonCompliant = countif(CompliantState == "Noncompliant"), InGracePeriod = countif(CompliantState == "InGracePeriod"), NotEvaluated = countif(CompliantState == "Not Evaluated" or CompliantState == ""), ConfigManager = countif(CompliantState == "ConfigManager") by bin(TimeGenerated, 1d) | extend ComplianceRate = round(100.0 * Compliant / Total, 2) | order by TimeGenerated asc This query will return daily device compliance trends over the past 30 days, from the IntuneDevice table. Figure 4 Reports > Log Analytics; results after running query. Select Chart > Chart type > Stacked Area to show a visual of the trending device state over time. Figure 5 Reports > Log Analytics > Chart > Stacked Area. If you’d like to create other reports but aren’t sure of the schema, one trick you can use is to run the following query in the above Log Analytics workspace to get all the column names: IntuneDevices | getschema Then to get all the values from those columns, you can modify the query to return the distinct values from a specific column such as CompliantState: IntuneDevices | distinct CompliantState Now that you have the query created in Log Analytics, you can save it to run anytime, pin it to a dashboard, or even create a new alert rule to let you know if compliance has gone below a certain threshold. To pin it as a dashboard, on the Query pane select the ellipsis (…) > Pin to > Azure dashboard. Figure 6 Reports > Log Analytics; pin query to dashboard flow. Then select the dashboard you’d like to use. Figure 7 Reports > Log Analytics; select dashboard to pin. Once pinned, simply navigate to Dashboard within the Intune admin center, and you’ll see the query pinned on the selected dashboard. Figure 8 Dashboard showing Log Analytics query. To show more than the past 24-hours, select the Customize Tile button and select Override the dashboard time settings at the tile level, with Timespan set to Past 30 days. Figure 9 Dashboard > Selected Query > Customize Tile button. If you’d like to always see the data in a chart form, select the edit icon on the pinned dashboard item and append the following to the end of the query: | render areachart with (kind=stacked) Figure 10 Dashboard > Selected query > Edit > modified query to show chart. After clicking Apply, the dashboard shows the following: Figure 11 Dashboard showing updated historical device compliance query as a stacked area chart. You’ve now seen end-to-end how to turn Intune diagnostic data into a 30-day device compliance trend report with diagnostic data and Log Analytics. From here, the next step is to operationalize it - save the query, extend the timeframe, join in additional diagnostic tables, or set an alert so you’re notified when compliance drops below your threshold. Better yet, see if you can pick one reporting gap your team is living with today and build it using this pattern. With the right tooling, Intune data can be shaped into views and insights that reflect your organization’s unique needs. Let us know if you have any questions by leaving a comment below or reach out on X @IntuneSuppTeam!Support tip: Aligning network policy with Microsoft Intune and Zero Trust
By: Jon Callahan – Sr Product Manager | Microsoft Intune Cloud services don’t just rely on the network. They redefine it. As organizations adopt Microsoft Intune and advance their Zero Trust strategies, many discover that traditional, perimeter-based architectures no longer align with modern security expectations or the connectivity needs of a distributed workforce. Zero Trust is built on the principle of "never trust, always verify,” where access decisions are enforced through identity, device health, and compliance signals. Microsoft Intune strengthens this model by extending security and management through the cloud. By removing dependencies on on-premises infrastructure, it strengthens network resilience and Zero Trust enforcement with policy-driven device management and secure connectivity to Microsoft endpoints. This is where friction occurs. Traditional enterprise networks were built around a castle-and-moat model of perimeter defense: build high walls around the perimeter and trust everything inside, rather than identity-based access. Centralized egress points, VPNs, proxy servers, and deep packet or TLS inspection worked well when apps, data, and users stayed inside the moat. Today, work and data are everywhere. Legacy network designs often force traffic into hairpinned routes (indirect paths through central gateways) that add latency, reduce performance, and increase management overhead for Intune, Microsoft 365, and other SaaS apps. The challenge deepens when network teams try to maintain allow lists for cloud services using static IP addresses. Microsoft’s endpoint IPs can change frequently, especially with CDN-backed services like Intune and Microsoft 365, to strengthen security, improve resilience, and scale globally. This is why Microsoft recommends domain-based egress policies, frequent updates based on the published endpoint lists, and bypassing SSL inspection for Microsoft-bound traffic that doesn’t support inspection. Enabling cloud services The shift to hybrid work environments shows the limits of perimeter-based networks. Users expect fast and reliable access to their apps and data whether at home, in the office, or on the go. To support this shift, organizations need to modernize their network architecture and policies. Local internet egress and optimized paths to trusted services like Intune are essential. Policies built on Zero Trust and cloud-native principles help ensure performance and security. In contrast, controls such as VPN-only access, TLS inspection, or centralized proxies often slow users down and block required endpoints. When networks get in the way, the impact is noticed: Device check-ins and compliance evaluations fail, leaving devices marked as non-compliant Enrollments stall or time out Apps download slowly, fail to update, or never install When these failures occur, users often blame Intune or their IT admins, even when the real issue is network policies. In a Zero Trust model, network policy works alongside identity and device-based signals to enforce access decisions. Network policy should enable cloud services, not obstruct them. Adopting cloud-native connectivity and Zero Trust enforcement protects users, devices, and data while improving reliability and user experience. This approach aligns with Microsoft’s Secure Future Initiative (SFI) and the principle of “Secure by Design,” which extend Zero Trust principles into the foundation of how services are built and operated. As part of this effort, Intune service endpoints are moving to Azure Front Door to enhance security, reliability, and performance while simplifying firewall management across Microsoft services. For details on required IP addresses and endpoints, see Support tip: Upcoming Microsoft Intune network changes. Outbound traffic management Aligning network policies with Zero Trust and cloud-native architecture can require trade-offs. Outbound traffic management is critical for Intune’s performance, but organizations differ in their compliance needs and tolerance for complexity. Below are three common models we see with our customers. Endpoint enforced access This model eliminates perimeter bottlenecks by moving enforcement closer to the user, device, and apps, which is the core of Zero Trust. Enforcement happens at the endpoint through identity, compliance, and device health signals, while the network provides fast, direct internet access with minimal restrictive filtering. Best for: Organizations ready to adopt a Zero Trust network architecture built on Intune and identity-driven signals, or those with minimal outbound filtering requirements. How to implement: Policy-based enforcement and compliance: Intune enforces and validates device health and measures device compliance and app protection policies for Microsoft Entra Conditional Access Identity-driven enforcement: Microsoft Entra Conditional Access evaluates signals such as user identity, device compliance, and risk level before granting access to cloud resources Threat protection: Microsoft Defender for Endpoint monitors device risk and blocks compromised endpoints from accessing cloud resources; enforce the built-in firewall on Windows and macOS devices Bypass traffic inspection: Don’t decrypt or inspect Intune and related Microsoft traffic using technologies like proxies, TLS inspection, deep packet inspection, or data loss prevention systems Use split-tunnel VPN and local internet egress: Route Intune and Microsoft 365 traffic locally to avoid unnecessary hairpinning Benefits: Establishes Zero Trust controls with identity, device, and threat-based enforcement Local internet egress and optimized paths to Intune and Microsoft 365 avoid latency and centralized paths No allow list or complex firewall rules to manage Avoids VPN, proxies, and TLS inspections and reduces the risk of interfering with user experience and device management failures This model requires strong endpoint management and identity controls to ensure Zero Trust enforcement. Domain enforced filtering When endpoint-only enforcement doesn’t meet your organization's requirements, Fully Qualified Domain Name (FQDN) filtering offers a middle ground by adding network controls while staying adaptable to dynamic cloud services. This approach should be paired with endpoint enforcement to maintain a Zero Trust architecture. Best for: Organizations that need outbound restrictions for compliance, while maintaining reliability and flexibility in cloud services. How to implement: Use domain-based rules: Filter traffic by FQDN rules that rely on DNS to adapt to changing IP addresses and CDN-backed services. Leverage automation: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date. Bypass traffic inspection for trusted services: Avoid decrypting or inspecting Intune traffic, which can break certificate pinning and cause service failures. Resolve locally: Use local DNS and Internet egress so devices connect to the closest Microsoft endpoint. Benefits: Builds on endpoint enforced Zero Trust controls Easier maintenance than IP-based filtering Automatically adapts to Microsoft's dynamic, cloud-hosted services Reduces service disruptions when automated Aligns with most regulatory and compliance frameworks This model requires more robust network automation and may introduce additional processing overhead compared to endpoint-enforced access. Domain and IP enforced filtering This model combines FQDN-based rules with IP filtering for the strictest assurance. It provides maximum control but introduces the most overhead. Like domain enforced filtering, this too should be combined with endpoint enforcement to maintain a Zero Trust posture. Best for: Organizations in highly regulated industries that require dual enforcement with domains and IPs to meet strict audit and assurance needs. How to implement for Intune: Combine domain with IP rules: Use FQDN alongside IP address ranges to filter traffic. Automate aggressively: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date. Bypass traffic inspection for trusted services: Exclude certificate-pinned services from TLS inspection to avoid breaking Intune functionality. Optimize performance: Architect your network to use local DNS and internet egress so devices connect to the closest Microsoft endpoint. Benefits: Builds on Zero Trust with the strictest network controls Provides dual verification for outbound traffic Helps satisfy strict regulatory and compliance requirements This model introduces the highest administrative overhead and complexity to maintain. It’s also the most likely to cause performance issues and service disruptions if not properly automated. However, for organizations with strict regulatory requirements, these trade-offs may be necessary to meet compliance obligations. Extending with cloud-first controls While traditional network models address outbound traffic at the infrastructure layer, a Zero Trust approach uses cloud-native security tools that eliminate many of these challenges. Issues like hairpinning, brittle IP allow lists, TLS inspection conflicts, and complex firewall rules stem from applying perimeter-era tools to cloud-based services. Cloud-first network and security tools reduce friction and strengthen Zero Trust. Cloud-delivered secure web gateway (SWG): Provides secure access to internet and SaaS apps while protecting against internet threats, building on the capabilities of traditional proxies (Microsoft Entra Internet Access) Zero Trust Network Access (ZTNA): Connects users securely from any device and any network without relying on VPNs or central tunneling (Microsoft Entra Private Access) Data loss prevention (DLP): Protects sensitive information across endpoints, Microsoft 365 apps, SaaS services, browsers, and on-premises file shares, with classification and policy enforcement (Microsoft Purview DLP) Cloud access security broker (CASB): Provides SaaS discovery, session control, and real-time policy enforcement (Microsoft Defender for Cloud Apps) Managing outbound traffic for cloud services is about more than connectivity. It’s about aligning network policies so they enable cloud services and embrace Zero Trust principles like identity, device health, and compliance signals over legacy perimeter defenses. Microsoft Intune supports through policy-driven device management and security that reinforce Zero Trust and cloud-native adoption. The result is an architecture that secures your environment and delivers the reliability and user experience needed for today’s hybrid work. Resources Intune network endpoints US government network endpoints for Intune China endpoints for Intune Support tip: Upcoming Microsoft Intune network changes Microsoft 365 network connectivity overview Azure Front Door Azure service tags Microsoft Secure Future Initiative (SFI) Microsoft Zero Trust As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam! Post updates: 11/06/25: Updated URLs for Automation category (see Domain-Enforced Filtering section).Microsoft Intune Advanced Analytics in action: Real-world scenarios for IT teams
By: Janusz Gal – Sr Product Manager | Microsoft Intune Microsoft Intune Advanced Analytics empowers IT admins and enterprise users to gain deep insights into device health, user experience, and organizational trends. Building on the foundation of Microsoft Endpoint analytics, Advanced Analytics offers enhanced device timeline reporting, flexible query options, anomaly detection, battery health monitoring, and resource performance tracking. IT admins can use Advanced Analytics to proactively manage their user devices, by turning raw telemetry into actionable insights, and optimizing IT support processes with near real time device information. In this blog post, we’ll review the capabilities provided by Advanced Analytics with example scenarios for how they can be used. Getting started Getting started with Advanced Analytics is easy! Once your license is in place and Endpoint analytics is enabled, Advanced Analytics features will become available in your tenant. For more details on the licensing requirements, review the following: What is Microsoft Intune Advanced Analytics. For those who haven’t enabled Endpoint analytics, now is the time. In the Intune admin center, navigate to Reports > Endpoint analytics. Select All cloud-managed devices in the dropdown (or a subset) and select Start to enable Endpoint analytics for your tenant. Figure 1 Endpoint analytics introduction pane in the Microsoft Intune admin center (Reports > Endpoint analytics). Some capabilities may take up to 48 hours for data to populate for Advanced Analytics analysis, such as anomaly detection, battery health monitoring, and inventory data shown in Device Query for multiple devices. Review Planning Advanced Analytics for a full list of prerequisites, a planning checklist, FAQ and more. Let’s take a look at the new capabilities available when you enable Advanced Analytics in Microsoft Intune. Custom device scopes Think of a subset of the organization you’d like to better understand and compare to the rest of the tenant. Possible examples include executive devices, maybe a specific country or region with a different budget, or even Microsoft Entra hybrid joined and cloud-native devices. With custom device scopes you can recalculate the whole set of Endpoint analytics reports based on scope tags and get the comparisons you need to make informed decisions. Let’s consider a scenario where a subset of the organization has Microsoft Entra hybrid joined Windows devices with decades of group policy being applied and you want to make the business case to invest the time in reviewing and building new policy in Intune. You can create a scope tag, for this example we’ll name it “Hybrid joined devices”, that you apply to hybrid joined devices, and then add that to the device scopes capability within Endpoint analytics. The manage device scopes setting can be accessed by selecting on the device scope selector on any filterable Endpoint analytics pane: Figure 2. Endpoint analytics device scope selection (Reports > Endpoint analytics > Overview). Figure 3. Manage device scopes pane for selecting and creating new device scopes (Reports > Endpoint analytics > Overview > Device scope > Manage device scopes). Under Endpoint analytics reports, navigate to the Startup performance report which showcases Core boot time and Core sign-in time. By default, this report is scoped to All Devices but is filterable using any tag including the one you just created: “Hybrid joined devices”. Figure 4. Startup performance report (Reports > Endpoint analytics > Startup performance). While results will differ for each organization, in the tenant shown here when you set the scope to “Hybrid joined devices”, you’ll see that Group Policy contributes 8 seconds to your Core-sign in time, and overall devices report 9 seconds slower boot times and 30 second slower sign-ins: Figure 5. Startup performance report, recalculated with Device scope. Just like that, you know that users are losing time on each reboot. Depending on how large the fleet is for your organization, that could be a significant amount and worth what it would take to modernize and plan to implement new policies. Of course, you can also use a custom device scope across the rest of the Endpoint analytics reports such as application reliability and work from anywhere. And with Advanced Analytics you also get two additional reports that can be sliced with device scopes – Resource performance and Battery health. Resource performance The resource performance report provides an analysis and score of CPU, memory, and storage metrics over time to identify underperforming devices. Let’s take the same scenario from before – reviewing the hybrid joined devices in your organization. If you have existing hybrid joined devices that are expecting a future device refresh, would it make sense to schedule that sooner because of their performance? When you review the resource performance score, you see how All devices are performing based on their CPU and RAM spike time scores – effectively, how often they are hitting their resource limits. Figure 6. Endpoint analytics resource performance report (Reports > Endpoint analytics > Resource performance). In Endpoint analytics, higher scores indicate that devices are providing better user experiences. For example, in the Resource performance report, a higher score indicates that devices are seeing less CPU spikes. Figure 7. CPU spike time score details pane (Reports > Endpoint analytics > Resource performance > CPU spike time score). You can view performance by specific models or devices using the navigation tabs at the top of the report. Periodically reviewing these results is helpful to ensure your devices are performing well within their ownership or refresh cycles. Better yet, you can use Baselines, which capture a snapshot of the scores for your tenant and allow you to track progress over time: Figure 8. Baselines selection (Reports > Endpoint Analytics > Overview > Baseline). You could, for example, directly see how the overall baseline scores improve a few months after a hardware refresh by checking a previous baseline against the current scores. This can help further justify hardware spending by showing quantifiable improvements to the user experience. For this example, since you know the hybrid joined devices are older than your cloud-native ones, you can reuse your custom device scope here to filter the resource performance report and compare the scores: Figure 9. Resource performance report recalculated via Device scope (Reports > Endpoint Analytics > Resource performance > Device scope set). Now you can also easily identify that your hybrid joined devices are performing worse than average, as they have a significantly lower resource performance score than All devices. Battery health monitoring Advanced Analytics also gives us access to the Battery health report which details capacity and runtime scores across the organization. Figure 10. Battery health report (Reports > Endpoint Analytics > Battery health). The top level report shows a battery capacity score and a battery runtime score, both of which provide a flyout with granular details on how devices are performing: Figure 11. Battery capacity score detail (Reports > Endpoint Analytics > Battery health > Battery capacity score). Figure 12. Battery runtime score detail (Reports > Endpoint Analytics > Battery health > Battery runtime score). Using these reports, you can easily identify devices that need a battery replacement, such as older devices or laptops that have been plugged in for years. These are great candidates to replace sooner – as ever-changing home or office work locations shift, you can improve user confidence in their devices by ensuring a fully charged battery lasts for hours. On the flipside – you can use the Battery health report to assess whether existing devices can have their lifespan extended. Maybe they are five years old but the batteries are still reporting more than 5 hours of runtime on a charge and greater than 80% health. For example, in the hybrid joined device scenario, you were looking for budget to refresh those devices sooner – if you can find existing devices with healthy batteries, you could also check their resource performance results and decide to keep them an extra few years if they are performing well. Device query for multiple devices Suppose you have used the previous capabilities – custom device scopes, resource performance reporting, and battery health reporting – to determine a group of devices within your organization that you want to perform some action on. As mentioned before, this could be extending their lifespan, planning a refresh, or investing in a tooling migration. If you need additional details from devices before making that decision you can use Device query for multiple devices. Device query for multiple devices provides insights about the entire fleet of devices using previously collected inventory data. And since it leverages the flexible and powerful Kusto Query Language (KQL), you can mix and match inventory attributes to get the list of devices that meet your requirements. For Windows devices, before you can use Device query for multiple devices you’ll need to create a Properties Catalog policy. Add the properties you would like to collect and assign the profile to the intended devices. All available properties are automatically collected for Android Enterprise, iOS, iPadOS, and macOS devices, so no extra configuration is needed. Figure 13. Configure and deploy a Properties Catalog profile. You can view collected inventory information for a single device under the Device inventory pane. After a device syncs with Intune, it can take up to 24 hours for initial harvesting of inventory data. Once you have the inventory information collected across the fleet, navigate to Devices > Device query to start querying. Figure 14. Device query for multiple devices (Devices > Device query). Expanding on the scenarios from before, consider a requirement to replace devices with high battery cycle counts. With Device query for multiple devices, you could join battery and CPU data, and better target planned replacements: Figure 15. Running a query (Devices > Device Query). Of course, you can use any of the inventory categories to find applicable devices including storage space, TPM details, enrollment information, and so on. For organizations with Security Copilot licensed and enabled, you can leverage Query with Copilot to generate the KQL queries for you using natural language: Figure 16. Copilot query generation (Devices > Device query > Query with Copilot). Once you have the results, you can export to a .csv to use elsewhere like sharing to the team handling procurement and hardware lifecycle management. Figure 17. Export device query results (Devices > Device Query > Run query > Export). Now that you have your list of devices, what if you need even more detailed information? Granular details from enhanced device timeline and Device query With the results from Figure 15, you were able to find a device with high battery cycles and a relatively old processor. At first glance this is a great candidate for replacement. With Advanced Analytics, you can explore further by navigating to Devices > Windows select a device and leverage the enhanced device timeline and Device query capabilities. The enhanced device timeline shows a 30-day history of events that occurred on a specific device including details on app crashes, unresponsive apps, device boots, device logons, and anomaly detected events: Figure 18. Device timeline pane showing multiple app crashes over the past two days (Devices > Windows > select device > User experience > Device timeline). From here, you have a much better and direct understanding of how a user’s device is performing. If a user frequently sees unresponsive apps, you are now reasonably confident that you’ve found a device worthy of further troubleshooting or replacement. Device query for a single device, on the other hand, let’s you investigate even further and query the device for real-time data such as Windows Event Log Events, Registry configuration, or Bios details. For the full list of properties refer to Intune data platform schema. Figure 19. Device query for a single device, returning process details (Devices > Windows > select device > Device query). With Device query and the enhanced device timeline, you can get all of the granular information needed to make informed decisions about a device. Find additional scenarios with anomaly detection Don’t have a specific goal or unsure of what needs to be resolved? Want to proactively address issues before users start reporting them? Use the Anomalies tab to identify deviations from normal behavior across your environment, such as a spike in application crashes. Figure 20. Anomalies tab showing multiple high severity detections (Reports > Endpoint Analytics > Overview > Anomalies). With the other capabilities provided by Advanced Analytics, you can investigate anomalies in several ways. To start, each anomaly provides a list of affected devices. By clicking through each of these devices, you can use Device query or the enhanced device timeline to get detailed information needed to troubleshoot properly. Figure 21. Anomaly detection report detailing affected devices (Reports > Endpoint Analytics > Overview > Anomalies > select affected devices). Medium and high severity anomalies include device correlation groups based on one or more shared attributes such as app version, driver update, OS version, and device model. Figure 22. Anomaly detection report detailing behavior and impact (Reports > Endpoint Analytics > Overview > Anomalies > select anomaly title). To investigate further, you could create a new custom device scope to recalculate the Endpoint analytics reports for affected devices, use the Resource performance report, or even the Battery health report if that is seemingly causing issues. While a common approach for organizations is an internal initiative that drives an investigation into analytics reports, anomaly detection is certainly a great starting point as well for improving user experience. What’s next Advanced Analytics is continuing to evolve with new capabilities to give you the insights you need on the user device experience. Stay tuned for further blog posts around additional Advanced Analytics and Intune reporting capabilities. If you have any questions or want to share how you’re using Advanced Analytics in Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune!
Intune Custom Compliance Policy - Struggling
Any assistance or guidance on this is greatly appreciated. For over a week I struggled with a custom compliance policy that will do the following. - Search for a specific installed software and version and produce the following results: - Application is not installed - Compliance Status set to "Not Applicable" - Application is installed but is not the desired version. - Compliance status set to "Not Compliant" - Application is installed, meets the version requirements - Compliance status set to "Compliant" - Multiple versions of application exist, one of which meet the requirements. Compliance status set to "Not Compliant" If I run the discovery script on a local device and output the findings it is 100% successful, every time. However, when applying the policy in Intune not every works correctly. Here are both the JSNO file and discovery script. -------JSON------ { "Rules": [ { "SettingName": "ComplianceStatus", "Operator": "IsEquals", "DataType": "String", "Operand": "Compliant", "MoreInfoUrl": "https://example.com/compliance-info", "RemediationStrings": [ { "Language": "en_US", "Title": "Software Compliance Check", "Description": "The required software version is installed and compliant." } ] }, { "SettingName": "ComplianceStatus", "Operator": "IsEquals", "DataType": "String", "Operand": "NonCompliant", "MoreInfoUrl": "https://example.com/compliance-info", "RemediationStrings": [ { "Language": "en_US", "Title": "Software Compliance Check", "Description": "The required software version is not installed or is outdated. Please install or update to the required version." } ] }, { "SettingName": "ComplianceStatus", "Operator": "IsEquals", "DataType": "String", "Operand": "NotApplicable", "MoreInfoUrl": "https://example.com/compliance-info", "RemediationStrings": [ { "Language": "en_US", "Title": "Software Compliance Check", "Description": "The software is not applicable for this device." } ] } ] } ------- Discovery Script _------- $softwareName = "Autodesk Single Sign On Component" $requiredVersion = [version]"13.7.7.1807" # Get the installed software information $installedSoftware = Get-CimInstance -ClassName Win32_Product | Where-Object { $_.Name -eq $softwareName } # Initialize the result hash $result = @{ SoftwareInstalled = $false SoftwareVersion = "0.0.0.0" ComplianceStatus = "NotApplicable" } # Process each instance if any are found if ($installedSoftware) { $result.SoftwareInstalled = $true $isCompliant = $false $multipleCopies = ($installedSoftware.Count -gt 1) foreach ($software in $installedSoftware) { $installedVersion = [version]$software.Version $result.SoftwareVersion = $installedVersion.ToString() if ($installedVersion -ge $requiredVersion) { $isCompliant = $true } } # Determine overall compliance status if ($multipleCopies) { $result.ComplianceStatus = "NonCompliant" } else { $result.ComplianceStatus = $isCompliant ? "Compliant" : "NonCompliant" } } # Return the result as JSON $result | ConvertTo-Json -Compress
iOS Microsoft Defender Compliance Policy not showing compliance despite successfull setup of the app
I am having an issue on multiple tenants and after a lot of try and error I am not getting it. All tenant enroll their devices through the Apple DEP in supervised mode and deploy the Microsoft Defender app using a VPP token with a device based license. The app is successfully installed on the devices and users are able to sign in to the app and the defender is showing everything is green. However the Compliance policy does not switch to compliant even after long waiting and the security center is not showing the device. Strangely this is not happening always... around half of the enrollments switch to compliant while the other half does not. Sometimes the issue also resolve by reinstalling the app. I have this issue on multiple tenants. I am using the Filter profile with auto enrollment (which also does not start always) but the VPN onboarding has the same issue. So if someone else had this issue and has an idea where this comes from: Please give me a comment.
Security Baselines
Hi, I'm having an issue after enabling the baseline securities. When we connect our laptop to the docking station via the Thunderbolt port, the peripherals (mouse, keyboard, and network connection) get blocked. We suspected the policy "Disable new DMA devices when this computer is locked," but disabling it didn't help. Does any body have any idea, which policy it might be blocking the peripherals ? this is a headache to find.
Migration from 3rd party MDM to Intune - Compliance Partnership issues
Hello Community, we are currently in the situation, that smartphones are managed via a 3rd party device management system, which is connected via Partner Compliance Management to Intune. We are in the process of migrating MDM from the 3rd party system to Intune. Users unenroll their devices (removal of the Management Profile and App), install the company portal and enroll into Intune. This works so far, but suddenly after some time we started having issues that the smartphones that got migrated switch into a not compliant and not managed state, but in Entra ID only. In Intune they are still compliant. This happened to devices that have been enrolled to Intune since several months, as well as devices that have been enrolled only a few weeks. Also not all at the same time, first 1, then 2, then suddenly 10ish a few days later... In the Entra ID device audit log we can see, that "Microsoft Intune" executed a "Device no longer managed" activity on the device. But it seems as the the Activity is always listed as Intune, no matter if its really initiated by Intune or via the Compliance Partnership in Intune. We cannot find any logfile that let's us nail it down to if this really triggered by the 3rd party mdm via the compliance partner interface, or maybe some weird hidden Intune Cleanup job, that sets this if devices are no longer synced from the partner management. As a workaround, we currently assign a Compliance Policy that is impossible to fulfill by the device, wait until the device also turns not compliant in Intune, then unassign the policy again. When the device now turns compliant in Intune again, it also synchronizes the status to Entra ID again and the Device Object in Entra is back in a compliant and managed state. Do you have any suggestions for that case? One idea was, to delete the Entra ID Objekt and have a new object created when the user enrolls his device to Intune again, but that would cause a lot more efforts in the rollout. (Currently the Entra ID Device Object stays the same). Thank you
