Unable to create Win32 apps in Intune
I am unable to create a very basic Win32 application in Intune. I get green check marks across the board but when I try to create the application I get an error message saying "Save Application Failed. TypeError: Cannot read properties of null (reading 'id')". Any suggestions?
Reporting on Device CPU and Memory
I have a requirement to produce a monthly report on all our Intune managed Windows devices and the applications they have installed. I have written a script that is able to report on UPN, Device Name, Manufacturer, Model, Serial Number, OS, Total HHD and Free space along with all the applications installed. I am however unable to output the devices CPU and Memory details. I have tried using the Get-MgBetaDeviceManagementManagedDevices with the ProcessorArchitecture and PhysicalMemoryInBytes parameters but these just report 0 or NULL. What is the best way to report on the CPU and Memory from Intune?
SSID connection using intune pushed profile kept prompting manual login
Hi, anyone encountered an issue where users connecting to an SSID with 802.1X authentication using an Intune-pushed Wi-Fi profile (with credential caching enabled) are still being prompted to enter their credentials manually? However, it works fine by configuring the network connection protocol manually. Thank you.Windows App Management in Microsoft Intune
Audit every managed and unmanaged app per device with more metadata, including publisher, architecture, estimated size on disk, install location, uninstall commands, to help troubleshoot PCs and expose shadow IT before it spreads. Pull curated Win32 apps straight from the Enterprise App Catalog or upload PowerShell scripts to control exactly how each app installs. Stage rollouts in rings with Intune deployments, to gradually deploy, pause or cancel any deployment in flight; and auto-trust every app you push using App Control for Business with Managed Installer, which also works with Autopilot as you provision new devices, now with up to 25 apps. Keep your fleet of apps up-to-date automatically as vendors publish new versions through the Enterprise App Catalog, or trigger updates on demand from the Guided Upgrade Supersedence report. Nicole Zhao, Microsoft Intune Product Manager, shares how to put these built-in enhancements to work across every managed device. *Intune Deployments is currently in private preview. Capabilities shown are subject to change and not yet generally available. Identify shadow apps across your managed devices. Microsoft Intune’s app inventory now surfaces publisher, architecture, size on disk, install location, & uninstall command per device. See how it works. Auto-trust every app you deploy through Intune. App Control for Business with Managed Installer tags your deployments as safe and scopes trust to specific user groups. Check it out. One toggle, continuous app updates. The Enterprise App Catalog in Intune pushes vendor releases to managed devices automatically, or surfaces them in a Guided Supersedence report for manual review. Try it now. QUICK LINKS: 00:00 — Built-in app management 00:51 — App Inventory Visibility 01:42 — Enterprise Application Management (EAM) 02:28 — PowerShell Script Installer GA 03:09 — Ring-Based Deployment Plans 04:44 — Managed Installer Auto-Trust 05:39 — Enterprise App Catalog Auto-Update 06:12 — Guided supersedence 06:50 — Wrap up Link References Go to https://aka.ms/IntuneAppManagement Check out https://aka.ms/RSAC26-Intune-Blog from the RSA Conference for additional security context and guidance when managing apps with Microsoft Intune. Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -Controlling the application layer on devices, delivering the right apps, keeping them secure, up to date, and protected has always been one of the toughest challenges as you manage IT environments. This is nothing new, but what is new is how much easier Microsoft Intune now makes it. With the latest built‑in app management enhancements, you can more easily discover apps across your environment with clearer visibility into your full app inventory per device, simplify app preparation and deployment through pre-packaged apps or with scripted installs, as well as safer, gradual app roll-outs using ring-based deployments. -Ensure only trusted apps run by automatically trusting deployed apps through App Control for Business with Managed Installer, and keep devices automatically on the latest versions as vendors release updates, using the new auto-update capability with your Enterprise App Catalog. It all starts with knowing what apps people have running on their managed devices. And that’s where the latest improvements to app inventory in Intune give you the full up-to-date picture with minimal latency. -Here, for each device, you can see a comprehensive list of inventoried applications, including both managed and unmanaged apps. Importantly, we’ve added more app metadata to help you make better decisions about your apps or start troubleshooting. For each app, you can see the publisher name, architecture, and now even estimated size on disk, as well as installed location, uninstall command, and languages, as long as that information was registered in Windows. For shared devices, we’ve also improved the per user app information to include all users on the device. This gives you clear visibility into which applications exist in your environment, to help you identify unknown or shadow applications that may be running against your policy and governance controls. Next, for getting the right apps deployed, let me show you how we’ve made it easier to bring apps into your managed catalog. -Here, Enterprise App Management, or EAM, is designed to simplify app lifecycle management. I’m going to start by creating an app. Unlike the consumer-focused Microsoft Store, which uses community-driven WinGet app types for app discovery, EAM provides a curated list of enterprise-ready Win32 apps. You can find these apps by choosing the Enterprise App Catalog app type and Confirm. From there, you just need to search for the apps you want. In this case, I’ll look for Blender, and then under Configuration, you’ll find available architectures and versions. You’ll see that it pre-populates the app information. And in the Program tab, the install and uninstall command lines are pre-populated, as well as the exit codes. -Now, this used a command line installer type, but something new to give you even more control is the script installer, which is now generally available. This lets you use PowerShell script to control the installation of your Win32 apps. So, I’ll change the installer type to be a PowerShell script, and that will expose a control to upload a custom script as a PS1 file. Next, I’ll choose the Blenderinstaller script from File Explorer. It conveniently enters the name field for me and then mounts the script to give a preview of the pre-installation commands it runs. This gives you precise control over the install behavior of your apps using script-based installation. And as we progress, the rest of the steps for getting this app deployed to your managed devices should be pretty familiar. -Next, for app roll-outs, Intune’s policy-driven deployment lets you introduce application changes gradually using Deployment Plans. This helps avoid issues from misconfigured, compromised, or unintended app updates, giving you more control over the roll-out process. Let me show you how to create a deployment. You’ll start in Deployments, which you’ll find under Managed Devices. At the top, you’ll see two tabs: Deployments, which lists the app payloads targeted for existing roll-outs; and Deployment Plans, which are reusable deployment schedules that you create with ring timing, as well as assigned groups. I’ll move to the Deployments tab and select Create. Then I’ll give it a name, Global Secure Access Client, and description, East Coast rollout, Next, I’ll select a payload. I’ll choose Win32 and Add Payload, and select Global Secure Access Client. -Now I’ll configure the deployment schedule, which is the key step when setting up this deployment. Here I can either build rings manually, where you’ll add time offsets per ring, or I can load an existing deployment plan. In this case, I’ll load a plan. From here, I can choose the plan I want. I’ll pick the East Coast retail store rollout plan. I’ll choose a start date and add a time. Once the plan loads, all the rings are added with their timelines and associated groups or exclusions. For example, this one has a one-week offset between each ring. When I move to the last Review step, this dialog on top tells me that, once created, I can pause, resume, or cancel the deployment at any time. -From there, I can review my deployment and confirm by hitting Create. Now my app will roll out based on this defined schedule. Let’s look at the latest capabilities for keeping your apps trusted. First, App Control for Business with Managed Installer in Intune means that apps you deploy using this method are automatically tagged as safe apps, without manual allow-listing. It lets you upload your app control policies as XML files or leverage built-in controls to automatically trust apps from the managed installer. -There’s also a new option to target the Managed Installer to specific groups where you enable Intune Managed Extension as Managed Installer and scope the managed installer to specific users with inclusion and exclusion policies. Additionally, with Managed Installer enabled during Autopilot device preparation, you can ensure apps are trusted right from the start as you provision new devices. And using device preparation policies, Autopilot also supports an increased app limit of up to 25 apps. Of course, you can combine these capabilities with Windows Defender Application Control together with Intune to allow only trusted and approved apps to run on your managed devices. Now let’s look at new ways to keep apps on the latest version. -First, with the new auto-update capability using the Enterprise App Catalog, you can have Intune automatically keep apps up-to-date on your managed devices. When you add a new app using the Enterprise App Catalog, as part of the initial configuration in the Updates tab, you can choose between Automatically Update and Update with Supersedence. This is a one-time setting that allows Intune to automatically install updates as they are published. From there, once you confirm, you’ll see that, by design, many of the subsequent settings have been streamlined to just Scope tags, Assignments and Review + Create. -And if you want more control over app updates, our second option, Guided Upgrade Supersedence, automatically surfaces available updates of your deployed apps without you having to go look for new versions of each app manually. You’ll see that, under Apps in the Monitor blade, you’ll find a new report called Enterprise App Catalog apps with updates. By clicking into one of these apps, you’ll see that there is an update button in the upper left corner. This lets you supersede existing app versions for that app on managed devices in just a few clicks. You’ll see that all of the necessary information is pre-populated. And this is the same with the program tab and subsequent tabs in the app deployment workflow, including the supersedence relationship. -Everything you’ve seen today is about simplifying control of your application layer, making apps easier to discover, deploy, trust from day one, and keep automatically up to date, so you can deliver the right apps securely and consistently across your environment. To find out more, check out aka.ms/IntuneAppManagement Keep watching Microsoft Mechanics for the latest tech updates, and thanks for watching!Autopatch - Microsoft 365 Apps Update Rings
I’m trying to understand how the UpdateDeferredVersions registry value is updated in an Intune Autopatch scenario, specifically the version and FileTime values. Registry path: HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Updates Example value: UpdateDeferredVersions = 16.0.19725.20170:13420719560293 | 16.0.19822.20180:13421142577563 I’ve observed the following and would appreciate any clarification: When I modify deadline or deferral settings via Autopatch (policy changes), the FileTime value does not update. Is there a delay or specific trigger (e.g., policy refresh, scheduled task, CDN sync) that updates this FileTime? How exactly is this FileTime calculated? Is it tied to when the build was released, assigned, or when the policy was applied? Is there any supported way to force or influence this FileTime update? Or is this value simply tracking when the build cap was issued, with deferral logic calculated relative to that timestamp? Additionally, I’ve noticed that updates only seem to apply when the FileTime is approximately 4 days behind the current date, is this expected behavior with Autopatch deferral logic? I was able to successfully test this updating FileTime 4 days behind ((Get-Date).AddDays(-4)).ToFileTime(). Any insights into how this mechanism works under the hood (especially with Click-to-Run + Autopatch interaction) would be really helpful. Below is Autopatch group settings for Microsoft 365 update rings that we set in our environment: Test - Deferral 0 - Deadline 0 Ring 1 - Deferral 1 - Deadline 0 Ring 2 - Deferral 2 - Deadline 0 Last - Deferral 4 - Deadline 1 Thanks in advance!Autopilot V1 vs “Device Preparation” (V2): Great direction — but is it enterprise-ready yet?
We evaluated Autopilot v2 but decided to stay on Autopilot v1 for large‑enterprise scale. Group Tags + dynamic groups are still essential for our device naming, segmentation, and governance model. We intentionally limit apps in EAS to speed up provisioning, so EAS‑based app deployment in v2 isn’t a compelling advantage for us. v2 looks promising, but until there’s stronger parity for enterprise‑scale targeting and naming, v1 remains the better fit. Curious how others at scale are balancing provisioning speed vs. segmentation without Group Tags.Protect org data on BYOD Windows / macOS devices
Hi All I hope you are well. Anyway, I have a need to protect org data on: Window personal / BYOD devices MacOS personal / BYOD devices What's the best way to achieve this? My thinking is: 1 X Conditional Access policy that blocks 1 X Conditional Access policy that allows via Edge, no persistent session, no downloads etc Device filter on both policies that target unmanaged devices Any other suggestions? SK
Intune enroll on redhat 10 KDE
**intune-portal 1.2603.31 fails to authenticate on RHEL 10 KDE Plasma — Misconfiguration(0) in gtk4/actions.rs** **Environment** - OS: Red Hat Enterprise Linux 10 - Desktop: KDE Plasma (Wayland, XDG_SESSION_DESKTOP=plasma) - intune-portal: 1.2603.31-1.el10.x86_64 - microsoft-identity-broker: 3.0.1-1.el10.x86_64 - xdg-desktop-portal-kde: 6.4.5-1.el10_1.x86_64 - webkitgtk6.0: 2.50.4-2.el10_1.x86_64 **Summary** The Intune portal fails to complete authentication on KDE Plasma. The same machine, same user account, and same tenant works correctly under GNOME on the same RHEL 10 install. The only difference between the working and non-working sessions is XDG_SESSION_DESKTOP (gnome vs plasma). **Error** The portal throws the following Rust error when attempting to start a login: ``` [intune-portal/src/gtk4/actions.rs:103:29] e = Error { context: "Starting a new login", source: Misconfiguration( 0, ), } ``` The OneAuth logs show: - `No accounts found in the OneAuth account store` - `Auth params authority is empty` - `MATS device telemetry disabled` This results in a [4kv4v] error in the Microsoft auth window with Code: 0. **Additional findings during investigation** 1. On RHEL 10, the KDE portal service is named `plasma-xdg-desktop-portal-kde.service` rather than the expected `xdg-desktop-portal-kde.service`. This means it is not auto-discovered without explicitly starting it, which is a secondary issue. 2. Overriding `XDG_SESSION_DESKTOP=gnome` at launch does not resolve the Misconfiguration(0) error, suggesting the portal reads the session desktop variable at startup rather than at auth time. 3. The auth flow reaches the broker, the broker starts MSAL, but the portal fails to pass authority parameters, so the login flow never presents a credential prompt to the user. **Steps to reproduce** 1. Install intune-portal 1.2603.31 on RHEL 10 2. Log into a KDE Plasma Wayland session 3. Launch intune-portal and attempt to sign in 4. Observe Misconfiguration(0) error — no login prompt is shown 5. Log out, log into GNOME on the same machine 6. Launch intune-portal — authentication completes successfully **Expected behaviour** Authentication should work on KDE Plasma in the same way it does on GNOME. **Workaround** None found. Using GNOME is the only current option on this machine.
