co-managed Working flow
Hi SCCM Expert, I would like to understand how co-management works in a multi-tenant scenario. Currently, my SCCM environment manages devices from two different domains: abc.com → Integrated with ABC Intune Tenant xyz.com → Integrated with XYZ Intune Tenant To enable co-management, we configured the Cloud Attach/Co-Management settings in SCCM using a Global Administrator account from the abc.com tenant. We then created a pilot collection and added devices from both abc.com and xyz.com domains. My questions are: Since co-management was configured using credentials from the abc.com tenant, how can devices belonging to the xyz.com tenant successfully become co-managed and receive Intune workloads from their respective tenant? During the co-management enrollment process, what determines which Intune tenant a device enrolls into? Is the SCCM co-management configuration tied to the tenant used during setup, or does the device use its own Azure AD/Entra ID registration information to identify the target tenant? What is the actual trigger point for the transition from SCCM management to co-management/Intune enrollment? If devices from multiple tenants exist in the same SCCM hierarchy, how does SCCM ensure that each device is enrolled into the correct Intune tenant? Could you please help clarify the architecture and enrollment flow in this scenario?
OneDrive for macOS documentation issue. DefaultFolder plist example is missing array wrapper
Hi everyone, The Microsoft Learn documentation for configuring the OneDrive sync app on macOS currently contains an incorrect plist example for the DefaultFolderLocation setting. Documentation page: https://learn.microsoft.com/en-us/sharepoint/deploy-and-configure-on-macos#defaultfolderlocation In the “DefaultFolderLocation” section, the current plist example shows the DefaultFolder key as a dictionary: <key>DefaultFolder</key> <dict> <key>Path</key> <string>(DefaultFolderPath)</string> <key>TenantId</key> <string>(TenantID)</string> </dict> This format does not work correctly when deployed as a managed preference/configuration profile. The setting starts working when the DefaultFolder dictionary is wrapped in an array, like this: <key>DefaultFolder</key> <array> <dict> <key>Path</key> <string>(DefaultFolderPath)</string> <key>TenantId</key> <string>(TenantID)</string> </dict> </array> Please update the Microsoft Learn documentation to include the array wrapper in the DefaultFolder plist example. The current Microsoft Learn example is confusing because administrators may deploy the documented plist exactly as shown, but the setting does not appear to work correctly until the array wrapper is added.
Android 15 - CredentialProviderPolicy not surfaced by Intune
I have been having an issue with Android 15 devices. We use Authenticator as our password autofill provider. As soon as a device is updated from Android 14 to Android 15, the password autofill provider is no longer set and the setting to change it is 'blocked by work policy.' I have already tried removing all policies that apply to the devices (device config and device compliance policies) and factory resetting them. Simply having them enrolled as corporate owned fully managed devices causes this to happen. I raised the issue in the Android Enterprise community blog. A link to that is included below. Someone on that thread found that there is a policy in Android 14/15 called the credentialproviderpolicy. When that policy is blocked or unconfigured, this behavior happens. I cannot find anywhere in Intune where I can set this policy. It seems that it is allowed by default when managing Android 14 with Intune, but not set or blocked when the device switches to Android 15. Is there any way to specifically set a policy that is not reflected in the Intune UI? This is a blocker for being able to move more phones to Android 15. Link to Android Enterprise thread: https://www.androidenterprise.community/t5/admin-discussions/android-15-cannot-set-default-password-app/m-p/8827#M2105 Thanks, TomMicrosoft Managed Home Screen: Unwanted Samsung One UI 8.0 Elements Appearing
Hello Tech Community, Our organization is currently deploying a configuration in Microsoft Intune using a Corporate-owned dedicated device enrollment profile. We’ve applied a device restriction policy to configure Samsung tablets in Multi-app Kiosk mode, with Managed Home Screen set as the launcher. Instead of using an app configuration policy, Managed Home Screen is configured through the device restrictions policy. We’ve left the device navigation options unconfigured, which should hide the following UI elements: Android Overview button Android Home button Android App drawer Once all policies and required apps are installed, Managed Home Screen successfully acts as the launcher for end-users to sign in. Overall, this works well; however, we’ve encountered an intermittent issue: After multiple lock/unlock cycles, the navigation bar sometimes reappears, showing the Overview, Home, and App Drawer buttons. This allows users to access background apps that are not exposed through Managed Home Screen, which defeats the kiosk experience. Device details: Samsung Galaxy Tab S10 FE Android 16, One UI 8.0 Managed Home Screen version: 2.2.0.107721 Has anyone experienced this behavior or have recommendations to prevent these UI elements from reappearing? I’ll gladly provide additional details about our configuration if needed. Thank you!
Device Enrollment
Hi everyone, I need some guidance regarding a device-management scenario in my environment. We currently have Microsoft 365 Business Basic with the Intune Plan 1 add-on. All of our devices (about 150+) are Azure AD Registered, and I’m trying to determine the best method to enroll them into Intune using only our existing licenses. I’m unsure which enrollment method is most appropriate for this setup, and I haven’t been able to find a solid, recommended approach. I want to avoid unnecessary complexity and I cannot upgrade or change our licensing. I would really appreciate a well-structured explanation that covers: The best enrollment method for this scenario Why this method should be used Step-by-step guidance Pros and cons of the proposed method Any insights from those who have handled similar situations would be extremely helpful. Thanks in advance!
Managed Home Screen MSAL - severe issuse
Hi Intune Community! We are currently experiencing severe issues with Managed Home Screen and MSAL on our shared Android devices, managed as dedicated with Entra Shared mode. Anyone else experiencing issues? Quite often when a user types her user name at the MHS sign in page and press the Sign In button, the screen only blinks and nothing happens. Only workaround is to restart the device and then it often works to sign in a user once or twice, until same issue happens again. It affects all devices and all users and we have tried both the latest version of MHS and some older version. No difference. Some things that we have seen is: If we exit kiosk mode and start the Intune app it says "Something went wrong" and shows a Register button. This is however gone when restarting the device. (see images below) If we start the Authenticator app, also after exit kiosk, it asks for "organization email" and shows a Register button. This is also back to normal once you restart the device. (see images below) If we let the device be after trying to sign in, 10-20 minutes later it has managed to sign in and asks for setting a Session PIN. The problem is that it is the user who last made a successful sign in who gets signed in. Huge security issue. We also see that Edge and Teams (probably other msal-enabled apps as well) doesn't behave as normal even if you successfully sign in. Teams ask what account to sign in with. Either selecting the suggested account or pressing the Back-button (<) signs you in. (see images below)
iPads in Single App Mode stuck after Update
Hi, We've got a bunch of iPads that we control via InTune, a bunch are set to Single App Mode. They have auto-update on for iOS updates, however when they restart themselves after completing the update often(not always) they will go back to the lock screen rather than the single app screen. Thankfully we've got the SN displayed on the lock screen and when we reboot from InTune it fixes it, however this isn't a proper solution. Because it's single app mode it won't let the users swipe away the lock screen. Has anyone got a fix for this? Any assistance is greatly appreciated.
MDM Work Portal Settings – Android – iOS
Hello Team, Please help me with some questions I have regarding the implementation of my MDM policy on Android and iOS mobile devices. When installing these applications, the following questions arise: Why is "location" required, and why is its activation necessary? It requests permission to access the phone's storage — why is this needed? How is web browsing managed or controlled? Defender asks to activate a VPN — I would like to understand why this is necessary. How does Defender classify the severity level as high, medium, or low, and how is this used to determine whether a device is considered compliant?
