IntuneManagement/ReleaseNotes.md

Release Notes

4.0.0-beta1 - 2026-09-23

This is a beta release. 4.0 is a full rewrite of IntuneManagement. The feature set is broadly familiar, but nearly every internal has changed. Test it against a lab tenant before pointing it at production.

Version 3 remains the supported release. It stays on the default branch and keeps getting fixes until 4.0 leaves beta. 4.0 lives on the v4 branch until then, and the in-application update check will not offer it to a 3.x installation while it is a pre-release. Run 4.0 alongside 3.x if you like: they keep their settings in different places and neither reads the other's.

BREAKING CHANGES

These are the things that stop working if 4.0 simply replaces 3.x in an existing setup.

• Every pipeline and scheduled job has to be rewritten. The 3.x silent mode - Start-IntuneManagement.ps1 -Silent -SilentBatchFile <file> driving a BulkExport.json or BulkImport.json exported from the forms, with %Date%, %DateTime% and %Organization% in paths - is gone, and 4.0 does not read those files. The launcher switches (-TenantId, -AppId, -Secret, -Certificate, -JSonSettings) are gone with it. The replacement is the public commands: Connect-IMIntuneManagement for the credentials, Start-IMGraphBulkExport / -Import / -Documentation for the work, and Import-IMSettingsStore for a settings file kept in source control. A 3.x nightly export becomes:

  Import-Module .\IntuneManagement.psd1
  Connect-IMIntuneManagement -TenantId $tenant -AppId $app -Secret $secret
  Start-IMGraphBulkExport -ExportFolder "C:\Export\$(Get-Date -Format yyyy-MM-dd)" -ExportAssignments $true
  

  See Docs/Examples.md for the other operations.

• Settings do not carry over. 3.x keeps its settings under HKCU\Software\CloudAPIPowerShellManagement; 4.0 uses HKCU\Software\IntuneManagement, and it does not read the 3.x JSON settings file either. The first start of 4.0 has a blank configuration: custom app id, export folders, documentation options and every other setting are entered again. That is also why the two versions can run side by side without touching each other.

• The cached sign-in does not carry over. The token cache lives in a per-version data folder (%LOCALAPPDATA%\IntuneManagement in 4.0), so the first start of 4.0 is a fresh sign-in, on every machine.

• Two export folders changed case. AutoPilot is now Autopilot and HardwareConfigurations is now hardwareConfigurations. Import matches folder names case-insensitively, so a 3.x export still imports; but a script that builds a path to one of those folders, or a Linux file system, sees two different names. Every other export folder keeps its 3.x name, and the JSON inside is compatible in both directions - 4.0 exports can carry properties 3.x did not write, which 3.x ignores on import.

• Two policy types are not in 4.0, both already disabled in the 3.x code:

  • Intune Locations (managementConditions). Microsoft removed the object from Intune; it only ever served Android device administrator compliance policies.
  • The iOS DEP enrollment profile, which 3.x carried commented out and never listed. Neither has been exportable from a current 3.x, so no export folder is orphaned.

• Scripts that imported the 3.x extension files will not run. 4.0 is a single module, IntuneManagement.psd1, with a documented public command surface; the Extensions\*.psm1 files are gone. Only commands listed in FunctionsToExport are supported, and they are prefixed IM. Anything else is internal and may change without notice.

Not breaking, but different: interactive sign-in opens the system browser by default. See Browser sign-in on every platform below for the reason, the one requirement it puts on a custom app registration, and how to turn it off.

New features

• Runs on Windows, macOS and Linux. A second UI backend built on Avalonia runs the full application outside Windows. The original WPF backend remains the default on Windows and is unchanged in behaviour. Select a backend with the IM_UI_BACKEND environment variable (WPF, Avalonia, or None for headless automation). PowerShell 7.4 or later is required for the cross-platform UI. See Docs/CrossPlatform.md.

• A supported automation API. Every bulk operation available in the UI is also a public command that runs headless with no UI loaded: bulk export, import, copy, delete, assignments, scope tags and documentation. This is the intended path for DevOps pipelines and scheduled runs.

• Two authentication providers. Selected per connection with -Provider:

  • MSAL (default) - interactive browser sign-in, the WAM broker on Windows (off by default; turn it on only when the app account is your Windows account), client secret, certificate, and device code.
  • OAuth - a pure PowerShell implementation with no SDK and no DLL dependency. Supports client secret, certificate, managed identity, workload identity federation (AKS, GitHub Actions OIDC), device code and ROPC.

  Multiple tenants can be signed in at once; each Graph call resolves its own token.

  A token acquired elsewhere can also be supplied directly with -Token (a BYO token). That is the only way to reach APIs Microsoft does not expose to public client applications. A BYO token cannot be refreshed - when it expires, supply a new one.

• Browser sign-in on every platform. Interactive sign-in opens the system browser on Windows, macOS and Linux, by default. It is the default because it is the one place every sign-in method works: passkeys, FIDO2 security keys, Windows Hello and phishing-resistant policies, none of which the embedded window can complete, and it reuses the browser session you already have. The requirement is the http://localhost redirect URI on the app registration; the default Microsoft application has it, a custom one may need it added. The setting Use system browser for login turns it off, in which case Windows uses the embedded window, or WAM when that is on. When no browser can be launched - a server session, a container, an SSH shell - the sign-in falls back to device code automatically rather than hanging. Device code can also be requested directly with -DeviceCode, which supports MFA, FIDO2 and security keys because the browser step happens on another device.

• Light and dark themes that follow the OS. Both UI backends ship light and dark themes, and by default the whole application follows the desktop theme - the Windows app theme, the macOS appearance setting, and the GNOME colour scheme on Linux. It switches as soon as the OS setting changes, with no restart. Light or Dark can also be selected explicitly with the AppTheme setting. Linux desktops other than GNOME have no common way to report this, so they default to Light unless a theme is chosen.

• Access marking uses the user's Intune role, not only the app's scopes. The menu already marked policy types the app's token could not use. It now also asks Intune what the signed-in user's role allows (getEffectivePermissions), so a user with a read-only Intune role sees the affected types in orange even when the app holds ReadWrite scopes. The Profile popup gains a Permissions button listing the token, role and effective level per type, and Get-IMGraphEffectivePermissions returns the same for scripts. Intune Administrator / Global Administrator skip the lookup. After a PIM activation or a new role assignment, click Refresh in the Profile popup - the answer follows the token. Setting UseRbacAccessMarking (default on) turns it off. See Docs/EffectivePermissions.md.

• Graph API call log. A Graph Calls view lists every Graph request the session has made - method, URL, status code, duration and size - with filtering and refresh. It makes a slow export or an unexpected permission error diagnosable without turning on verbose logging or reading the log file.

• Settings and automation. Settings can be read from and written to the registry, a JSON file, or an in-memory store that touches nothing on the machine. A run can import a settings file from source control, execute, and leave no trace. Settings resolve per tenant or globally. See Docs/Settings.md.

• Documentation engine. Policies can be documented to HTML, Markdown, Word, JSON, CSV, or Confluence storage format. Output providers, per-@odata.type handlers and input providers are all registries, so a new output format or a new policy type is an added file rather than an edit to a central switch. Enrollment notifications, Windows Hello for Business, Windows Restore and both Android enrollment profile types document with their portal labels for the first time, and the tenant-default enrollment policies - five of them share the name "All users and all devices" - are titled by their type.

• Cross-tenant migration only creates what the policy actually uses. Import creates referenced Entra groups and assignment filters in the target tenant and rewrites assignment ids to match, and AD-synced source groups are recreated as cloud groups. The change from 3.x is scope: only the groups a policy actually references are created. 3.x imported every exported group, even when a single policy referenced one of them.

• Bulk scope tags. Add, replace or remove scope tags across policy types or whole policy groups, with an orphan-cleanup mode that removes references to scope tags that no longer exist.

• Bulk assignments. Add, replace or remove assignments across policy types or groups, including include and exclude targets, assignment filters, app install intents and health-script schedules.

• Graph batching and parallelism. Requests are batched, and on PowerShell 7 batches can run in parallel. Both are settings. On a large tenant this is the difference between a 26-minute and a 4-minute full export. See Docs/GraphBatching.md.

• Multi Admin Approval support. When a tenant requires approval for a Graph write, the pending-approval response is detected and the approval code is returned to the caller rather than surfacing as an opaque HTTP 403.

• Continuous Access Evaluation. Claims challenges are handled and the request is retried transparently.

Behind the scenes

• PowerShell classes throughout. Policy types, policy objects, authentication providers, compare providers and documentation handlers are now PowerShell classes with real inheritance. A policy type inherits its export, import, copy, compare and documentation behaviour from a base class and overrides only what differs, instead of each feature carrying a switch statement over every object type. Adding a policy type is a new subclass file - there is no central list to edit.

• Self-registering extension points. Authentication providers, documentation output formats, per-object-type documentation handlers and compare providers all register themselves when they load. Adding one is adding a file.

• One engine, two user interfaces. The WPF and Avalonia backends implement the same contract and contain no feature logic of their own, so both call exactly the same code underneath. That is also what makes the headless automation API possible.

• An automated test suite. The engine is covered by an offline suite, and by an online release gate that exercises the full import, export, update, scope tag, assignment, documentation, copy, compare and delete lifecycle against a live tenant before a release is published. Both run in the development repository; this package is the application, without the test assets.

Known limitations in this beta

• The Avalonia backend is new. It has been exercised on Windows, macOS and Linux, but far less than the WPF backend has been over the life of 3.x.
• Application content cannot be exported unless the encryption information is available. Graph has no API for downloading decrypted app content, so an app whose encryption info the tenant no longer exposes can be exported as a policy but not as an installable package.
• Inventory Policies will fail to list. Microsoft does not allow public client applications to call that API. It works with a BYO token - see Two authentication providers.
• APIs that require additional licensing will fail for tenants without the licence. The object type is still listed; the request returns an error rather than an empty result.
• A few policy types have no dedicated documentation renderer yet: Apple enrollment types, iOS app provisioning profiles, Inventory Policies, Entra and Intune branding, Terms and Conditions, Windows quality update policies and Windows 365. They document as their basic information plus one row per property. The Document unsupported types option turns that off, in which case they are skipped with a log entry rather than written out empty.
• Copying a built-in administrative template can drop presentation values for settings that use them. Custom (ingested) ADMX is unaffected.
• The ADMX Files policy type supports View, Import and Export only.
• Types under Intune Info are read-only by design - Export and View only.