Intune On-Demand Proactive Remediation API Reliability for Large-Scale Usage
Hi Team, We are testing the Intune On-Demand Proactive Remediation API: POST /deviceManagement/managedDevices/{managedDeviceId}/initiateOnDemandProactiveRemediation In our environment, the remediation package works correctly, and the API generally triggers the remediation as expected. However, during repeated testing, we noticed that a small percentage of requests do not seem to reach the endpoint. For example: 20 remediation requests sent 18-19 execute successfully 1-2 never trigger on the target device Devices are online and managed by Intune Added a 30-second delay between requests, but the behavior still occurs intermittently Before adopting this in production for a large client base, we'd like to understand: Has anyone observed similar behavior? Is this API reliable for triggering remediation across multiple devices in parallel? Are there any known limitations, queueing mechanisms, throttling considerations, or best practices? Is there a recommended way to verify that a remediation request was actually delivered to the device? Since this API is still in the beta/preview stage, is there any information on its roadmap or GA timeline? Note: For additional context, detailed test results, observations, and environment information, a PDF containing the complete analysis has been attached. Any guidance or real-world experience would be greatly appreciated. Thank you. https://learn-attachment.microsoft.com/api/attachments/1ad5bea4-9038-4b25-9a2a-a9e66a870f6a?platform=QnA https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-initiateondemandproactiveremediation?view=graph-rest-beta
From Domain-Joined to Microsoft Entra Joined: A Low-Disruption Migration Framework
How the right in-place migration approach can preserve eligible user profiles, establish Intune management, and accelerate the move away from on-premises Active Directory. Cloud-native endpoint management is relatively straightforward when a Windows device is new. The harder problem is the installed base: hundreds or thousands of working laptops and desktops that already contain user profiles, local files, applications, certificates, security controls, and years of configuration. Resetting and re-provisioning those devices is a valid route, but it can introduce significant coordination, user downtime, application rebuilding, and service-desk demand. This often creates a practical gap between an organisation's cloud strategy and its ability to move the existing fleet. Can an existing domain-joined or hybrid Microsoft Entra joined Windows device move to Microsoft Entra join without being wiped or re-imaged? For eligible devices, the technical answer can be yes, when specialized migration tooling, careful preparation, and a controlled recovery model are used. However, an important support distinction must be made at the outset. The Microsoft support boundary matters Microsoft recommends Microsoft Entra joined, cloud-managed endpoints as the strategic direction for organisations that are ready to reduce their reliance on on-premises infrastructure. Microsoft also states that its supported path for converting an existing Active Directory-joined or hybrid Microsoft Entra joined device to Microsoft Entra join requires a Windows reset; it does not provide a Microsoft-supported, no-reset conversion path for that scenario. See Microsoft's guidance on Microsoft Entra join and hybrid join. A no-reset migration is therefore not a hidden Microsoft feature. It is a vendor-supported, tool-assisted workflow that orchestrates Windows, Microsoft Entra ID, Microsoft Intune, and Microsoft Graph capabilities and adds the missing profile-continuity and recovery layers. Microsoft may support the underlying platform components, but not the end-to-end no-reset conversion. That distinction does not put the approach in conflict with Microsoft's direction. The destination, Microsoft Entra joined devices managed by Intune, is aligned with Microsoft's cloud-native endpoint strategy. The bridge used to move the existing fleet is specialized and must be validated through a representative proof of concept, with clear ownership for support and recovery. The strategic destination can be Microsoft-native even when the migration bridge is specialized. What “seamless” should mean in practice “Seamless” should not mean that nothing changes. A credible low-disruption migration may still require a user sign-out, controlled restarts, a first sign-in with Microsoft Entra credentials, Windows Hello re-provisioning, and re-authentication to some applications. Instead, a successful in-place migration should aim to achieve the following: Retain the same physical device and Windows installation. Keep the eligible local Windows profile, local files, installed applications, and compatible settings in place. Re-associate that profile with the correct Microsoft Entra identity. Establish or re-establish Intune management in a controlled manner. Restore the intended application and policy targeting. Protect BitLocker and local-administrator recovery throughout the transition. Limit the interactive cutover to a predictable maintenance window. Produce verifiable evidence that identity, management, security, and user productivity are working after the change. The join operation is a milestone; it is not the entire migration. A device is truly migrated only when the user can work and the required security controls are demonstrably active. A step-by-step framework for an in-place migration Step 1: Define the complete target state Do not define success simply as “Microsoft Entra joined.” The target state should cover four connected layers: Device trust The endpoint is Microsoft Entra joined in the correct tenant and is no longer joined to the on-premises domain where that is the intended outcome. Management The endpoint is enrolled in Intune, has the correct corporate/personal ownership classification and primary user, has the required Microsoft Entra registered owner where applicable, and receives the required applications and configurations. User continuity The correct user can sign in to the existing eligible profile and access the files, applications, and services needed for work. Security and recovery Compliance is evaluated, Conditional Access behaves as designed, and BitLocker, Windows LAPS, Defender, certificates, and recovery access are validated. For new designs, a supported Windows 11 edition capable of Microsoft Entra join should be the forward-looking baseline; Windows Home editions cannot be Microsoft Entra joined. Windows 10 reached end of support on 14 October 2025; ESU, LTSC, or other exceptional servicing scenarios should be assessed separately against Microsoft's lifecycle information. Step 2: Discover dependencies and segment the estate An accurate inventory determines which devices are suitable for an in-place path. At a minimum, collect: Current join and management state. Windows version, edition, servicing status, disk health, free space, and pending restarts. Primary and additional local profiles, including profile health and size. Source account, target user principal name, and any identity-mapping exceptions. BitLocker status, recovery-key location, and local-administrator or LAPS recovery route. Applications that use AD computer authentication, legacy protocols, device certificates, or domain service accounts. GPO-delivered settings, mapped drives, printers, folder redirection, logon scripts, Wi-Fi, VPN, and certificate delivery. Windows Hello, Credential Manager, EFS, private keys, and other identity-bound data. Network location, proxy behavior, endpoint security controls, and remote-worker constraints. Use the findings to classify devices into practical groups: Ready for a tool-assisted in-place migration. Ready after remediation. Better suited to reset and Windows Autopilot. Better suited to hardware replacement. Temporarily retained as a managed hybrid exception because a dependency remains. This segmentation prevents a small number of unsuitable devices from setting the risk profile for the entire project. Step 3: Replace the policy dependencies—not merely the join state Once a device leaves Active Directory, Group Policy no longer refreshes. Existing registry-based settings may remain on the device, while mapped drives, printers, folder redirection, scripts, certificates, Wi-Fi, and VPN configuration may require a cloud-management replacement. Microsoft's Group Policy analytics in Intune can help identify which GPO settings have a cloud-management equivalent. The goal should not be to copy every historical setting. It should be to rebuild the controls the organisation still requires through Intune, rationalizing old policies along the way. Applications that rely on an AD computer account or machine authentication deserve particular attention. Device migration cannot make an application cloud-ready; application and infrastructure modernization remain separate work streams. Step 4: Prepare Microsoft Entra ID and Intune before touching a device The destination must be ready before the source trust is removed. Confirm: Target user identities exist, are enabled, and use the intended sign-in names. Required Microsoft Entra ID and Intune licences are active. Device-join permissions, device limits, MDM authority, enrollment restrictions, and ownership rules are correct. The correct users are included in the Intune MDM user scope. Required applications, configuration profiles, security baselines, certificates, Wi-Fi, VPN, and update policies are assigned. Compliance policies and Conditional Access rules include a safe enrollment and bootstrap path. Access to required on-premises resources has been tested from a Microsoft Entra joined device. Microsoft documents that eligible corporate devices can automatically enroll in Intune when they join Microsoft Entra ID, provided licensing and MDM scope are configured correctly. Conditional Access deserves careful sequencing. A device may need time to enroll, receive policy, and report compliance. Temporary exceptions, if required, should be narrow, documented, monitored, time-bound, and removed as soon as the migration wave is complete. Compliance does not migrate from the old device record; it must be evaluated again in the target state. Step 5: Secure the migration control plane A mature migration design should use a customer-controlled Microsoft Entra application with only the Microsoft Graph permissions required for the enabled functions. Application credentials should be protected, rotated, audited, and revoked when no longer required. Microsoft recommends applying the principle of least privilege to Microsoft Graph permissions. Where the selected workflow requires credentials to update, disable, or delete source AD computer objects, use a dedicated identity with narrowly delegated permissions rather than broad domain administration. If the workflow uses a Windows Configuration Designer provisioning package, treat it as a privileged credential. Microsoft's bulk enrollment documentation notes that the embedded bulk token can be valid for up to 180 days and that MFA is not supported in that particular token flow. Microsoft documents bulk provisioning for new devices, not as a native in-place profile-migration method, so any orchestration around it remains part of the specialized workflow. Protect the package, scope any necessary policy exception tightly, test it on a non-production device, and revoke it after use. Endpoint security controls also need advance preparation. Any approved migration executable and the system actions it performs must be tested against EDR, antivirus, WDAC, AppLocker, hardening policies, and proxy controls. A good architecture should not require a persistent endpoint agent after the migration is complete. Step 6: Build recovery into the design Changing device trust crosses several systems and is not one atomic transaction. A credible plan therefore starts with recovery, not optimism. Before migration: Confirm that critical user data is backed up or successfully synchronized to an approved location. Keeping files on the same disk is not a substitute for backup. Confirm that a working BitLocker recovery password is available through an approved location. Confirm a tested local-administrator or Windows LAPS break-glass route. Keep source recovery information available until target escrow is verified. Record the source join state, device identifiers, user-to-profile mapping, primary user, group assignments, and management state. Define stop points and avoid irreversible source cleanup until the target state has been validated, where the workflow permits. Document who owns endpoint recovery, identity recovery, and user support. Microsoft recommends storing BitLocker recovery information for Microsoft Entra joined devices in Microsoft Entra ID; see the BitLocker recovery overview. Windows LAPS can back up managed local-administrator passwords to Microsoft Entra ID on Microsoft Entra joined devices. Do not accept a vague “rollback” promise. Look for phase-aware, checkpoint-based recovery that can identify the failure stage, preserve administrative access, and safely resume or repair the workflow. Reset or re-image should remain the documented last-resort recovery path. Step 7: Run a representative proof of concept A pilot built only from clean IT laptops proves very little. Include representative devices and users, such as: AD-joined and hybrid Microsoft Entra joined endpoints. Office-based and fully remote users. Different hardware models and supported Windows builds. BitLocker-protected devices. Large or multiple eligible local profiles. Certificate-based Wi-Fi or VPN. Business-critical and internally developed applications. Users who still require on-premises file, print, or application access. Define success before the pilot begins. Measure device join, Intune enrollment, policy receipt, compliance evaluation, BitLocker escrow, pre-cutover local-administrator or LAPS recovery, post-migration Windows LAPS policy and backup operation, application access, profile continuity, user downtime, failure rate, and recovery effort. The purpose of the pilot is not merely to prove that a device can join Microsoft Entra ID. It is to prove that a real user can remain productive afterward. Step 8: Apply a strict per-device readiness gate Immediately before cutover, an automated preflight should verify: Supported source and target states. A healthy, supported Windows installation and local profile. A valid source-user-to-target-user mapping. Intune enrollment eligibility and available device capacity. Stable power, internet, DNS, and non-interactive system connectivity. Sufficient privileges for the required system operations. Accessible BitLocker and local-administrator recovery. No blocking restart, disk, encryption, proxy, or security-software condition. An unloaded profile during the identity-re association stage. Valid target-join material and required API access. Unsafe devices should be blocked and routed to remediation rather than allowed to fail halfway through the trust transition. Step 9: Capture the state that must be reconstructed Before changing identity, a capable workflow should record the data required to rebuild the intended management relationship, including: Source user, target user, profile path, and security identifiers used for correlation. Existing Microsoft Entra, Intune, and Autopilot device identifiers where relevant. Intune primary user and ownership information where applicable. Assigned device-group memberships and any groups that must not be recreated. Device attributes or tags used for policy and application targeting. BitLocker recovery-key identifiers and administrative recovery status. Local execution logs and a central audit record. In a cross-tenant migration, group object IDs and device records are different. Memberships cannot simply be copied; source intent must be mapped to equivalent target groups, while dynamic membership must recalculate from target-tenant attributes. Step 10: Execute a protected identity transition The exact order varies by tool and environment. The following three phases are an illustrative orchestration model, not a universal sequence for every tool. Prepare and detach The workflow confirms readiness, protects the starting state, prevents sign-in during sensitive operations, and removes or transitions the former domain, registration, or management relationship in the planned sequence. Establish the target identity The selected tooling establishes the target Microsoft Entra join using Windows join or provisioning interfaces. Use of documented platform interfaces does not make the overall no-reset conversion a Microsoft-supported migration path. Controlled restarts and state checks confirm that the target trust was created before the workflow continues. Re-associate and finalize While the old user profile is fully unloaded, specialized tooling associates the existing eligible local profile with the correct target Microsoft Entra identity and aligns the necessary permissions. The local files do not need to be copied to an intermediate location simply to maintain the profile. After the protected stage, the user signs in with the Microsoft Entra account and final management, recovery, and cleanup tasks complete. This is the specialized part of the process. Microsoft does not provide a native supported AD-to-Entra profile-conversion utility, and its documentation states that, USMT does not support moving profiles from AD-joined devices to Microsoft Entra joined devices. The capability, support, and recovery obligations therefore belong to the chosen migration method. Profile continuity must also be described honestly. Windows Hello, passkeys, cached authentication tokens, Credential Manager entries, user-bound certificates and private keys, EFS-encrypted files, application licences, and some Outlook, OneDrive, or browser state may require re-authentication, re-provisioning, or separate recovery. Installed software can remain on the device without every identity-bound secret remaining usable. Endpoint migration does not migrate Exchange mailboxes, OneDrive or SharePoint content, Teams data, or other Microsoft 365 workloads; cross-tenant data migration requires a separate plan. Step 11: Re-establish management and policy intent Following the identity transition, the workflow should ensure that the endpoint: Enrolls in the correct Intune tenant and obtains valid management certificates. Has the correct primary user and ownership classification where applicable. Receives the intended device-group assignments, attributes, applications, and configuration. Re-onboards to Microsoft Defender for Endpoint where required. Escrows BitLocker recovery information to the intended target record. Receives the target Windows LAPS policy and proves administrative recoverability. Registers with Windows Autopilot for future reset, re-purpose, or replacement workflows where that is part of the lifecycle design. Removes obsolete source objects or management components only after the target state is proven. Be precise with the language: the same physical Windows installation may be retained, but new Microsoft Entra and Intune objects can be created. Intune enrollment is re-established, not magically “preserved,” and compliance must be recalculated after check-in. Step 12: Validate, observe, and scale in waves Validation should cover four dimensions. Identity Correct Microsoft Entra tenant and device record. AzureAdJoined : YES, DomainJoined : NO where intended, and successful device authentication in dsregcmd /status. A Primary Refresh Token for the signed-in user where expected. Microsoft documents these checks in its dsregcmd troubleshooting guidance. Management and security Intune check-in, correct primary user, policy delivery, Defender status, and compliance evaluation. Expected Conditional Access behaviour. Verified BitLocker recovery escrow and Windows LAPS operation. Required security baselines, certificates, updates, Wi-Fi, and VPN profiles. User continuity Desktop, documents, permitted local data, and compatible application settings. Microsoft 365, OneDrive, browser, Outlook, printers, mapped resources, and line-of-business applications. Expected reauthentication and Windows Hello provisioning. Business productivity SaaS access, required on-premises access, collaboration tools, and help-desk acceptance tests. Scale only after results are visible per device. A capable platform should provide central status, phase-level telemetry, error details, local Windows event logging, retry or recovery controls, and auditable outcomes. Migration can then proceed through technical validation, representative pilot, early adopters, departmental or location-based waves, broad rollout, and an exception queue. Depending on the operating model, deployment may use Intune, Group Policy, another endpoint-management platform, or a controlled manual process. Suitable endpoint-local architectures can also avoid a dedicated on-premises migration server. Define pause thresholds for first-pass failures, Intune enrollment delays, compliance delays, application incidents, and manual-recovery volume. Both centrally scheduled and guided self-service execution can be useful, depending on the user population and support model. Remote migration may be possible over the internet, but “no VPN required” should never be treated as universal. The answer depends on the domain-leave method, deployment channel, proxy, certificates, Wi-Fi, applications, and source-cleanup requirements. Remote scenarios need stable power, reliable connectivity, clear user communication, and a tested break-glass channel. What capable migration tooling should provide Automated readiness assessment Stops unsuitable devices before they enter a sensitive transition. Explicit identity mapping Connects the correct existing profile to the correct target user. In-place profile reassociation Preserves eligible local user state without rebuilding or copying the entire profile. Eligible multi-user profile handling Supports shared devices only when every profile and identity mapping is explicitly supported and proven in the pilot. Controlled sign-in and restart handling Prevents a user or background process from loading the profile during reassociation. Join and enrollment orchestration Coordinates domain departure, Microsoft Entra join, and Intune enrollment in the correct order. Primary-user, group, and attribute handling Reconstructs policy and application targeting without claiming that compliance state transfers. BitLocker and administrative recovery controls Maintains a usable recovery path throughout the identity gap. Source and target object hygiene Reduces duplicate, orphaned, or stale identity and management records. Remote and wave-based deployment Supports distributed workforces, schedules, rings, pauses, and exceptions. IT-driven and guided user modes Allows the operating model to match different user groups and support capacity. Central telemetry and local logs Gives IT evidence of each phase rather than relying on user reports. Checkpoint-based recovery Resumes or repairs partial transitions without promising an unrealistic one-click rollback. Least-privilege and transparent data handling Limits tenant access and makes it clear what device, identity, recovery, and diagnostic data is processed. No persistent endpoint agent after completion Avoids adding a permanent management dependency solely for a one-time transition. The right question is not, “Can the tool run a join command?” It is, “Can it safely coordinate identity, profile, management, recovery, and validation at enterprise scale?” How this complements Windows Autopilot Windows Autopilot and in-place migration solve different lifecycle problems. Microsoft describes Autopilot as a set of technologies for setting up and pre-configuring new devices and for resetting, re-purposing, and recovering existing devices. It should remain a core part of the future device lifecycle; see the Windows Autopilot overview. Device situation - Sensible approach New, replacement, or intentionally reset device - Use Microsoft Entra join through Windows Autopilot. Healthy existing device where eligible working state must remain substantially intact - Evaluate a vendor-supported, tool-assisted in-place migration through a representative proof of concept. Unhealthy, unsupported, or end-of-life device - Reset, rebuild, or replace it. Device with an unresolved legacy dependency - Remediate the dependency first or retain the device temporarily as a controlled hybrid exception. Windows Autopilot Reset should also be described accurately. On supported Microsoft Entra joined devices it removes personal files, apps, and settings while maintaining the Microsoft Entra and Intune connections; it does not support hybrid Microsoft Entra joined devices. Microsoft's Autopilot Reset documentation explains that use case. In-place migration does not replace Autopilot. It can help modernize the installed fleet, after which Autopilot can support the device's future reset, repurpose, recovery, and replacement lifecycle. When an in-place path may not be the right choice Reset or replacement may be safer when a device has: An unhealthy Windows installation, damaged disk, or corrupted profile. An unsupported edition or servicing state. A roaming, mandatory, temporary, VDI, FSLogix, or other containerized profile that the selected method does not explicitly support. EFS-encrypted content or critical private keys without a verified recovery plan. Business applications that require the AD computer account or cannot operate from a Microsoft Entra joined device. Kiosk, shared, laboratory, privileged-access, or other specialized configurations that require a separate design. So much historical configuration debt that a clean baseline is more valuable than preserving the current state. Low disruption is an eligibility-based design choice, not a guarantee for every endpoint. The practical way forward Reducing dependency on on-premises Active Directory does not have to be a big-bang rebuild of every Windows device. With the right discovery, target preparation, specialized migration tooling, security controls, and phased validation, eligible devices can move to a Microsoft Entra joined and Intune-managed state while keeping much of the user's familiar working environment in place. The most successful programs treat the change as more than a device join. They coordinate device trust, endpoint management, user continuity, and recovery as one controlled process. They use Windows Autopilot for new and reset devices, a vendor-supported in-place path where preserving the existing working state has clear business value and reset or replacement where it is technically safer. That is the practical path to faster endpoint modernization: align the destination with Microsoft's cloud-native strategy, choose the migration route according to device condition and business need, and declare success only after both security and user productivity have been verified. Microsoft Resources Cloud-native Windows endpoints overview Microsoft Entra joined versus hybrid Microsoft Entra joined endpoints High-level planning guide for cloud-native endpoints Plan a Microsoft Entra device deployment Set up automatic enrollment for Windows devices What USMT migrates—and does not migrate Windows Autopilot overview BitLocker recovery overview Windows LAPS overview
Intune App inventory Graph
Hi All, I've enabled the configuration profile to receive app inventory data in Intune. In the GUI the data I can view the data just fine, but I would like to use Graph to automate this data and create custom reports. When I use the following https://graph.microsoft.com/beta/deviceManagement/managedDevices/[device-id]/deviceInventories('ApplicationProperties') I get an error: "Forbidden - 403 - 199 ms Either the signed-in user does not have sufficient privileges, or you need to consent to one of the permissions on the Modify permissions tab" even though the docs I can find about permissions are OK.Retrieving the “Device inventory” of iOS devices via the Graph API
We use Microsoft Intune to manage our iOS mobile devices. To achieve the highest possible level of efficiency, we use PowerShell as a supplementary tool for administration. Since our devices may contain two SIM cards, it is important for us to be able to read this information in order to perform relevant processes (e.g., adding phone numbers to address books). In general, it would be desirable to be able to read the information from the “Device Inventory” of iOS devices. For the reasons mentioned above, we would like this information to be made available via the Graph API. Alternatively, there should be a way to provide this information for all devices in a single report.
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?Intune – Unable to reliably validate application installation status via Microsoft Graph APIs
Hi Everyone, I am working on application deployment and validation using Microsoft Intune, and I am trying to implement an automated validation step to confirm whether applications are successfully installed. My primary requirement Verify application installation status Confirm per‑device installation status Validate installation for specific Intune‑managed devices Use Graph APIs as part of an automation workflow APIs tested so far 1️⃣ App installation status per device (NOT working / not usable) I initially tried using the documented API: HTTP GET https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/{mobileAppId}/deviceStatuses Issue: This API is not working for us It either returns no data or behaves as if it is not a valid / usable endpoint It does not return reliable installation status Hence, we cannot use this API for validation in automation At this point, deviceStatuses is not usable as a primary source of truth in our environment. 2️⃣ Detected Apps (secondary confirmation only) We are also using the Detected Apps API: HTTP GET /deviceManagement/managedDevices/{deviceId}/detectedApps This does work, however: It only confirms app presence It does not confirm Intune assignment or installation intent We are using it strictly as a secondary confirmation, not a primary validation method 3️⃣ Intune internal API observed via browser inspection We also tested the API that appears to be used internally by the Intune portal: HTTP GET https://graph.microsoft.com/beta/users/{user-id}/mobileAppIntentAndStates/{device-id} Observations: The API returns data However, installState frequently shows unknown The Intune portal shows a different and final status (Installed / Failed / Pending) This makes the API unreliable for automation It appears to be troubleshooting‑oriented, not intended for reporting or validation Questions I am looking for guidance on Is deviceStatuses known to be unreliable, tenant‑dependent, or effectively unsupported? What is the recommended API to retrieve actual app installation status per device? Are there any v1.0 APIs available for: Device‑level app installation status? User‑level app installation validation? What is Microsoft’s recommended best practice to validate Intune‑installed applications via automation? Is there official documentation that clearly explains: Which API should be used for reporting vs troubleshooting Expected delays or data inconsistencies between Graph APIs and the Intune portal Goal The goal is to build a reliable and supported automation‑based validation mechanism to confirm that Intune‑deployed applications are successfully installed on target devices. Any official guidance, confirmation of known limitations, or alternative approaches would be very helpful. Thanks in advance for your support.
How to create a dependency using Graph API in PowerShell
hi, I used following documentations to create a dependency via Graph API in Powershell: https://learn.microsoft.com/en-us/graph/api/intune-apps-mobileappdependency-list?view=graph-rest-beta https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.beta.devices.corporatemanagement/new-mgbetadeviceappmanagementmobileapprelationship?view=graph-powershell-beta Both ways give me the same error: New-MgBetaDeviceAppMgtMobileAppRelationship : No OData route exists that match template ~/singleton/navigation with http verb POST for request /AppLifecycle_2602/StatelessAppMetadataFEService/deviceAppManagement/mobileAppRelationships. Status: 400 (BadRequest) ErrorCode: No method match route template Seems like these Endpoints do not support POST/PATCH requests at all. Is there any other way to create a dependency using Graph API in PowerShell?Controlling Excel Add-ins and Microsoft Store App Installations
We have a requirement to block users from adding add-ins to Excel and Installing certain application directly which utilize Microsoft Store apps. Below are the two scenarios we need to address. I would appreciate any guidance or recommendations on how to implement these controls. 1) Blocking Excel Add-ins from Microsoft Store Users are currently able to add add-ins such as “Claude by Anthropic in Excel” directly from the Microsoft Store apps. For example, if a user accesses the URL: https://marketplace.microsoft.com/en-us/product/saas/wa200009404?tab=overview they can proceed to add the add-in to Excel. So, We need a method to prevent users from adding Office add-ins from the Microsoft Marketplace or external sources. 2) Blocking Installation of Microsoft Store Apps (e.g., WhatsApp) We are currently blocking Microsoft Store apps on OS level. However, users can still download and install applications such as WhatsApp directly from the vendor website, which utilize Microsoft store apps in backend: https://www.whatsapp.com/download We are considering configuring the Intune policy “Only Private Store is enabled.” However, we noticed that enabling this setting prevents users from accessing certain built-in applications (e.g., Notepad). Is there any other way to block access Microsoft Store apps directly? Thank you in advance for your assistance. Dilan
Intune MAM BYOD: Remove Account message for iOS devices
Hello, I am seeing an issue for Intune MAM BYOD(iOS) users. After a user account password reset, it causes Intune to remove the account configured from mobile applications like MS Outlook, Work, OneDrive, etc. Current Intune Configuration: Done - App Protection Policy Done - Conditional access policy --> Grant --> Requires app protection policy (checked) Users had to re-enrol to access his/her data. Here is the screenshot, Thank you,
