Outlook for iOS (MAM only Call Identification)
In order of the implementation of O365/M365 and with it Microsoft Intune, Outlook for iOS has become the standard mail client on iOS devices for many customers today. This is due to the excellent user experience and the constant stream of new features implemented by Microsoft. From a security perspective, in addition to the provision on managed devices (managed by Intune), the secure use on unmanaged devices with MAM or App Protection Policies (APP) is a big argument for using Outlook for iOS. Currently, many ouf our customers are working on a BYOD setup for blue collar worker, who typically have a maximum of one email inbox. A big pain point for many users who use Outlook for iOS in an MAM-only setup (and for MDM setup with Intune) is the missing caller identification of Exchange Online (EXO) contacts. Outlook for iOS supports a one-way contact export process whereby contacts from within Outlook for iOS can be exported into the personal (unmanaged) part of the native iOS Contacts app. This means a contact must first be imported into the users personal contacts directory of EXO and then exported from Outlook for iOS to the native (unmanaged) iOS Contact app in order to see who is calling. This functionality enables Caller-ID, iMessage, and FaceTime integration for users’ Outlook contacts. The exported Outlook contacts are considered unmanaged and are accessible by unmanaged, personal apps. Especially for European customers who are subject to GDPR compliance, this is a no go, as personal data and company data must not be mixed. The unintentional outflow of contact data worthy of protection to commercial platforms, such as WhatsApp or Google, and the unintentional synchronization of address books with social media apps, represents a significant GDPR risk. Although the user's personal EXO contacts can be synchronized, there is currently no option to synchronize the GAL. Furthermore, there is currently no provision in Outlook for iOS to synchronize the GAL cyclically. The user has to add a GAL contact to his personal contacts as described above and then within the Outlook for iOS app export the contact to his native iOS contacts app to be able to see who is calling. To meet the GDPR compliance, we need to prevent the contact export. So this is not a solution. The question to ask is: Why does a user need to export a GAL/personal contact to their native iOS Contact app? There are already several paid app solutions that close exactly this gap (ebf Contacts, Secure Contacts, etc.) which offer more or less the same range of functions. The app builds a container and downloads the managed address books (GAL, personal) of the user and then enables the resolution of the CallerID or identification of the caller via the so-called Apple CallKit integration. Apple has been offering the so-called CallKit integration for years. With CallKit you can integrate your calling services with other call-related apps on the system. CallKit provides the calling interface, and you handle the back-end communication with your VoIP service. For incoming and outgoing calls, CallKit displays the same interfaces as the Phone app, giving your app a more native look and feel. CallKit also responds appropriately to system-level behaviors such as Do Not Disturb. In addition to handling calls, you can provide a Call Directory app extension to provide caller ID information and a list of blocked numbers associated with your service. When a phone receives an incoming call, the system first consults the user’s contacts to find a matching phone number. If no match is found, the system then consults your app’s Call Directory extension to find a matching entry to identify the phone number. This is useful for applications that maintain a contact list for a user that’s separate from the system contacts, such as a Outlook for iOS. For example, consider a user who is a colleague to Jane, but doesn’t have her phone number in their contacts. If the Outlook for iOS app has a Call Directory app extension, which downloads and adds the phone numbers of all of the user´s colleagues. When the user gets an incoming call from Jane, the system displays something like “(App Name, e.g. Outlook) Caller ID: Jane Appleseed” rather than “Unknown Caller”. The effort to integrate the Call Directory Extension is minimal and would solve many pain points from both a security and user experience perspective. Apple has documented CallKit excellently on the developer site: https://developer.apple.com/documentation/callkit With the possibility of using Apple CallKit in combination with Outlook for iOS and the contact synchronization (personal/GAL) of a managed EXO mailbox, the use of M365 in a BYOD scenario for customers Blue Collar workers will massively increase. Furthermore, the use of contact synchronization is then also possible for devices managed by Intune. This creates an outstanding user experience while increasing user adoption! This article was also published as feedback in the Outlook Forum for iOS: https://feedbackportal.microsoft.com/feedback/idea/a80414f4-9598-ed11-a81b-000d3ae32cd0 There are already other requests within the Microsoft community that I would like to link here: PatrickF11 : Outlook for iOS + Caller Identification - Microsoft Community Hub Daniel Huttenlocher: https://feedbackportal.microsoft.com/feedback/idea/bbfc8763-da97-ed11-a81b-000d3ae32cd0
App Protection Policy and Siri Intents
Hello, I know that there is a MAM Policy setting to be checked "areSiriIntentsAllowed" to decide to allow or block a Siri intent for an Intune SDK integrated application but I am not seeing where in the App Protection Policy that I can change this value to allow the Siri intent. Is there an Intune Console setting that dictates what the "areSiriIntentsAllowed" will be set to? Here's the Intune SDK integration reference https://learn.microsoft.com/en-us/intune/intune-service/developer/app-sdk-ios-phase4#siri-intents Thanks!Google Meet Links Not Opening on Intune-Managed Devices
We recently encountered an issue where Google Meet links could not be opened on devices managed via Microsoft Intune. This behavior was consistent across multiple users and devices, and it raised questions about whether this was a configuration issue, a policy conflict, or something else entirely. Symptoms Clicking a Google Meet link (e.g., https://meet.google.com/xyz-abc-def) results in no action. Tried to open it from Outlook, Gmail or Google-Calendar When Opening with the Browser, we get a Redirection to Google-Play-Store, but the Google-Meet App ist already installed. Behavior is consistent across Outlook, Teams, and other apps that handle links. We tried different Default Browers (Edge and Chrome) and Outlook, Gmail, Google Calendar and Google Meets are configured as managed Apps Is this a known Issue or can this be fixed with Intune Configurations? Looking forward to your feedback.Edge Mobile prompting users to Allow opening app using Custom URI Scheme
Somewhat recently, perhaps with release of IOS 26, Microsoft Edge began prompting users to "Allow" or "Don't allow" a site to open another application when using a Custom URI Scheme. This causes an unnecessary step in our user's authentication process especially when Conditional Access policies are enabled as Edge must be used to pass the CA conditions. This occurs even when the custom-intunemam:// scheme is used to open the Intune enabled application from Edge. I am wondering if there is an Edge Mobile - Intune configuration/setting that we could configure to bypass the prompt. Thanks!Remed Script to delete Reg Value
Hi All I hope you are well. Anyway, pulling hair out this one, so could someone help me compile a Detect and Remed script to delete the following Reg key please: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Value I need removed is the SetActiveHours one as below Any help would be greatly appreciated.
InTune policies blocking callback from Edge browser
InTune policies blocking callback from Edge browser I'm using a BYOD Android phone enrolled in our company's InTune company portal. A few months ago, I ran into an issue where I'm unable to authenticate to a MatterMost chat server from the MM app in my work profile. When I enter the server address and click log in, it takes me to a browser window inside the MM app (but using Edge) to authenticate using the host organization's SSO. Once I enter my credentials, it sends a callback using this URI scheme: mmauth://callback?MMAUTHTOKEN=<token>&MMCSRF=<more data>. However it looks like Edge prevents this callback from reaching the MM app because I get a popup saying: No available apps There are no apps currently configured on this device that your organization allows to open this content. Please ensure you are signed in with your work or school account to your managed apps or contact your organization's support team. I assume this is because our IT has either "Restrict web content transfer with other apps" or "Allow app to transfer data to other apps" policy settings enabled. In general things are pretty locked down so that data can't be shared between non-Microsoft apps, and even then some things can't be copied and pasted from one Microsoft app to another. I reached out to our company IT support but he seemed to think the only possible solution was to allow Chrome inside the Work profile to bypass the Edge restrictions. For obvious reasons, no one in IT or the company leadership wanted to implement this solution. Are there any other solutions where MatterMost or even just that specific "mmauth" URI can be white-listed in InTune to allow MatterMost to complete the authentication? Not looking to try to get around policies, but would like to have a informed discussion with our IT on maybe adjusting the policy to be more functional.Conditional Access Policy Loop with Edge on BYOD Devices – Need Help!
Body: Hello Tech Community, I’m facing an issue with an Azure AD Conditional Access Policy that seems to be causing a loop when users access Office 365 resources using Microsoft Edge on Windows 11 24H2 BYOD devices. Here’s the scenario: Problem: The policy is titled "Require App Protection Policy for Edge on Windows for All Users when Browser and Non-Compliant-v1.0" and continuously prompts users to switch profiles in Edge. These devices are BYOD and intentionally excluded from full Intune management (non-compliant by design). However, Edge repeatedly requests authentication or profile switching, creating a frustrating experience. Policy Details: Applies to: Windows devices using browsers (primarily Edge). Excludes: Compliant devices or those with trustType = ServerAD. Includes: Office 365 applications. Excludes Groups: Certain groups that should bypass the policy. What I’ve Tried: Verified device compliance status in Azure AD and Intune. Checked Azure AD Sign-In Logs for errors or repetitive authentications. Cleared Edge browser cache and cookies. Ensured Edge is configured to use Windows sign-in information. Adjusted the App Protection Policy settings for Edge. Questions: Could this be an issue with how Edge handles profile authentication in Conditional Access scenarios? How can I ensure that BYOD devices remain excluded from full Intune management but still work seamlessly with this policy? Are there specific adjustments I can make to the Conditional Access or App Protection Policy to avoid these loops? Additional Context: My goal is to secure access using App Protection Policies (MAM) for BYOD scenarios without requiring full device enrollment in Intune. Any insights, suggestions, or similar experiences would be greatly appreciated! Thank you in advance for your help!
