New policy implementation and web enrollment for Android personally owned work profile is now GA
We’re happy to announce two improvements for the management of Android personally owned work profile devices with Microsoft Intune, which is now generally available! A new implementation for how Intune delivers policies to devices. Web based enrollment. These updates modernize how Microsoft Intune manages devices and improves the enrollment flow. As of June 18, you will need to take action to opt in to the new implementation. This change will become required later in 2026, and we’ll continue to update this blog as rollout details become available. Keep reading to understand what’s changing, actions, and timelines you need to know. What’s changing New implementation We’re finalizing our work on moving the Android personally owned work profile implementation to the latest and greatest available – Google’s Android Management API (AMAPI). It has been almost a decade since Intune released support for Android personally owned work profile management. At that time, we accomplished this by building a custom device policy controller (DPC), in the form of the Intune Company Portal app. A lot has changed since then. Google released AMAPI and its companion app, Android Device Policy, which enforces AMAPI policy on devices. This is now Google’s recommended implementation, which we used to deliver the three corporate Android Enterprise management methods: corporate owned work profile, fully managed, and dedicated. Google no longer recommends use of custom DPCs and they’re deprecating associated functionality. The benefits of moving personally owned work profile management to AMAPI include: Faster release of new features across all four Android Enterprise management options. Consistent behaviors across all four Android Enterprise management options. The Microsoft Intune app will replace the Company Portal app as the user app (to manage devices, contact their IT department, collect logs, and more), providing an updated user experience and aligning it with the corporate Android Enterprise management options. Enables Intune to support the latest Android platform management capabilities, which are unavailable with custom DPC implementations. Web based enrollment The move to AMAPI also enables us to build a web-based enrollment flow for personally owned work profile devices, similar to web based device enrollment for iOS. The benefits of this include: Users don’t need to manually install an app to start Intune enrollment since they can start enrollment from a webpage instead. Users can access enrollment from any of the three different entry points which all launch the same webpage: Productivity apps - when admin has configured conditional access so that the user is required to enroll before accessing corporate resources (recommended) The Company Portal app This gives you more options for how to guide your users to get set up. A URL Android enrollment is more consistent with the iOS web-based enrollment flow. How to configure and monitor Web based enrollment As of June, 18th 2026 - A new setting is now available that lets you switch your tenant to the new web-based enrollment experience for all future personally owned work profile enrollments. We recommend that you configure this in a test tenant first, try out and document the user flow, and prepare your helpdesks accordingly before opting in on your main tenant. Once you opt in, there isn’t an option to opt out. Planned for Q4 2026, Intune will automatically configure all personally owned work profile enrollments across all tenants to be web enrollments. New implementation A new configuration policy allows you to migrate device groups to the new implementation. As a best practice, we encourage admins to evaluate migrating a smaller device set before migrating all devices. Before moving devices to the new implementation, you may want to email users or configure custom notifications to inform them of what to expect. Planned for Q4 2026, Intune will automatically migrate all remaining devices using the custom DPC implementation over to the new AMAPI implementation. Monitoring There is a new report that shows how many personally owned work profile devices are in each of the following states: On AMAPI Not targeted to move to AMAPI Targeted to move and pending completion (since it may roll out over some time) Attempted to move and hit an error (and why) How this will affect your users Web based enrollment After you opt in to web based enrollment or later after it’s changed to the default, all personally-owned devices (on all Android OS versions) will enroll with the web based flow. These devices will be managed with AMAPI. After enrollment, Intune will install a few apps automatically to ensure streamlined management. Microsoft Intune: User-facing app to manage devices, contact the IT department, collect diagnostic logs, and more. Company Portal: For mobile app management (MAM). Android Device Policy: To enforce AMAPI policies. This app is installed in a “hidden” state, so users won't see it in their app list. Microsoft Authenticator: To provide single sign on for users’ work account. Below is an example of the web based enrollment flow that a user would see if they needed to set a PIN on their device to meet admin requirements. New implementation When a device is moved to the new implementation (either through admin configuration or the later automatic move), devices won’t unenroll and users won’t lose access to corporate resources. Moving enrolled devices to the new implementation will be supported on any device running supported Android OS versions for user-based management methods at that time. The changes on the device will be: The Microsoft Intune app will install, and it will be the app for users to interact with instead the Company Portal. Users will not see a notification about this app installing. The Android Device Policy app will install to enforce policies. Users will not see a notification about this app installing and it will be in a “hidden” state on their device. If a device connected to corporate Wi-Fi with username and password authentication, when they move to AMAPI, they will lose access to corporate Wi-Fi until they sign in to the corporate Wi-Fi again. To avoid any potential disruption, we encourage you to move to certificate Wi-Fi authentication instead (as mentioned below). Timeline 2025: Use this time to revise any relevant policy configurations, update your internal documentation, and prepare your helpdesk teams, as advised below. June, 18th 2026: Enrollment: You’ll be able to opt in for all enrollments of personally owned work profile devices to be web based enrollments on AMAPI. New implementation: You’ll be able to set a configuration policy to migrate groups of previously enrolled devices over to AMAPI. Planned for Q4 2026: Enrollment: All enrollments (regardless of past configuration) will be web enrollments for devices running all Android OS versions. New implementation: All devices still on the custom DPC implementation and running supported Android OS versions for user-based management methods at that time will be automatically moved over to AMAPI. You will receive advanced notice of when these changes will be applying to your tenant. How to prepare We recommend you make these changes to prepare for the upcoming release and provide the most streamlined experience for users. Passkey support: If you have passkeys configured as the only accepted authentication method, users won't be able to enroll with the new web based enrollment flow. This is a known limitation, and we'll add passkey support before web based enrollment becomes the default for all personally owned work profile enrollments across all tenants - planned for Q4 2026. Important: Web-based enrollment doesn't support passkeys yet. If passkeys are your only allowed authentication method, enrollment will fail. Don't opt in to web-based enrollment until we announce passkey support for this flow. Replace custom policies: Intune ended support for custom configuration polices for personally owned work profile devices in April 2025. Custom policies are not supported in the new implementation. Replace all custom policies with equivalent policies using this setting mapping. Certificate authentication for Wi-Fi: If you’re using username and password authentication for Wi-Fi policies, we strongly encourage you to move to certificate authentication instead. Devices that are connected to corporate Wi-Fi with username and password authentication will lose access to corporate Wi-Fi when they are moved to AMAPI until the user signs into the corporate Wi-Fi network again. Devices using certificate authentication for Wi-Fi won’t lose access, and it’s also a more secure authentication method. Evaluate biometric configuration: Devices on the new implementation won't apply policies that prevent users from using face, fingerprint, iris, or trust agents to unlock their device. However, policies that prevent this at the work profile level are still supported. If you have this configured at the device level, consider blocking at the work profile level to protect work resources in an equivalent way. Note that for users who have turned on the setting to use one lock (unified password for the device and work profiles), then biometric settings configured for the work profile will apply to the device instead, since there isn't a separate work profile unlock. Review enrollment restrictions: In enrollment restrictions (also referred to as device platform restrictions) the “Android Enterprise (work profile)” restriction for personally owned work profile devices has a setting to Allow or Block “Personally owned” devices. This configuration will not apply to devices on AMAPI and the setting will be removed from the Intune admin center when all devices are moved to AMAPI. As communicated in the Intune Android 12 blog, this setting does not work reliably on devices running Android 12 and later. Conceptually, personally owned work profile management is meant for personal devices, so blocking personal devices from enrolling and only allowing corporate devices isn’t recommended. If you currently have the “Personally owned” setting set to Block for personal work profile devices, you should plan an alternate way for blocking these devices. Options include using a corporate management method instead (such as corporate owned work profile) or configuring the personal work profile enrollment restriction to block enrollments for all users except for users in a specified group. Update Android OS: Intune currently supports Android 10 and later on personally owned work profile devices. We recommend you guide users to update to their device’s latest supported Android version for the best experience. Helpdesk preparation: Inform your helpdesk teams of these coming changes so they know what to expect. For devices on the new implementation, diagnostic logs will be collected using the Microsoft Intune app (instead of the Company Portal app). Plan to update any user instructions you have after you try out the web based enrollment flow. iOS web based enrollment: We recommend you consider setting up web based device enrollment for iOS now or when we release Android web based enrollment for a more consistent and improved user experience. Changes to be aware of A few defaults will change as part of the move to the new implementation. Required app installation behavior: In the custom DPC implementation, users can uninstall required apps, and then they are reinstalled automatically within a few hours. In the new implementation, users won’t be able to uninstall required apps from their device, which is the same experience as on corporate Android Enterprise devices. Caller ID and contact search: In the custom DPC implementation, the settings to “Display work contact caller-id in personal profile” and “Search work contacts from personal profile” are two independent settings. In AMAPI, they are controlled with a single setting. If you have blocked either, Intune will automatically block both for devices on the new implementation. Intune will update the policy user interface to have a single setting once all devices are on the new implementation. Screen timeout: In the custom DPC implementation, you can configure screen timeouts either for the full device or for the work profile under “Maximum minutes of inactivity until work profile locks.” In AMAPI, you can only configure this at the work profile level. Intune will set this to the lesser of the two when devices move to the new implementation. We will remove the device level setting from policies when all devices are on AMAPI. Security provider and Google Play services: The compliance settings for "Up-to-date security provider" and "Google Play Services is configured" won't be supported for devices on AMAPI. This is because security providers will automatically be updated and Google Play Services are required for device enrollment and management. Intune will remove these settings from compliance policies when all devices are on AMAPI. Enrollment reports: A couple of enrollment reports will not report on devices enrolled into AMAPI management. They are the “Enrollment failures” and “Incomplete user enrollments” reports that are found in Devices > Enrollment in the Monitor tab. Google Domain allow listing: The device restriction setting “Google domain allow-list” will not be supported for devices on AMAPI. This capability is now managed directly in the Google Admin console rather than through device restriction policies. Once the onboarding account has been migrated to a Microsoft Entra account and federated with a Google account, admins can configure this setting in the Google Admin console under the Third-party integrations node by enabling “Authenticate Using Google.” Intune will remove this setting from device restriction policies once all devices are on AMAPI. Stay tuned to this blog for updates! If you have any questions or feedback on this change, leave a comment on this post or reach out on X @IntuneSuppTeam. Post updates 02/19/25: Updated the Timeline and How this will affect your users + New Implementations sections. 04/08/25: Updated these sections: How to configure and monitor, How this will affect your users, Timeline, How to prepare, and Changes to be aware of. 04/09/25: Updated the Changes to be aware of section to include details about TeamViewer supportability. 08/22/25: Added images and updated all sections with the latest information, including an updated Timeline section and removing the information about the delay to TeamViewer support. 09/09/25: Added a screenshot to clarify Android enrollment restrictions. 09/23/25: Update the Changes to be aware of section to include more information about 'Enrollment reports'. 02/12/26: Updates to the Changes to be aware of section to include more information about 'Security provider and Google Play services'. 03/27/26: Updates to the Changes to be aware of section to include more information about 'Google Domain allow listing'. 05/13/26: Updated the Timeline section to reflect availability in late Q2 of calendar year 2026. 06/18/26: Updated to note that as of June 18 this is now generally available! You may need to take action to opt in to the new implementation. 10/28/26: Updated the Changes to be aware of section to remove information about password requirements.
Copilot Feature Request: Real-Time Two-Way Voice Interpretation with Speaker Identification
Voice Interpretation for Microsoft Copilot Dear Microsoft Copilot Team, I would like to suggest a new feature for Copilot: Real-Time Two-Way Voice Interpretation. Users select two languages (for example, Lao and Vietnamese) and place their phone between people speaking different languages. Copilot would automatically detect the speaker's language, translate the conversation in real time, and play the translation aloud, allowing natural communication without manual translation. Key capabilities: •Automatic language detection. •Continuous two-way voice translation. •Speaker identification and optional labels (Manager, Colleague, Speaker 1, etc.). •Option to translate a specific speaker or all participants. •Customizable translation voices and speech speed. •Better support for regional accents and everyday expressions. •Context-aware translation that focuses on meaning rather than word-for-word conversion. •Simple controls to start, pause, mute, switch languages, and stop interpretation. Privacy: Voice recognition and saved speaker profiles should be optional, require user consent, and be easy to manage or delete. Translated voices should be clearly distinguished from the original speaker's voice. Benefits: This feature could help migrant workers, travelers, students, businesses, and international teams communicate more easily. For example, a Vietnamese worker in Laos could speak naturally with Lao-speaking colleagues while Copilot handles real-time interpretation. Integrating this capability directly into Copilot would make multilingual communication simpler and more accessible for users worldwide. Thank you for considering this suggestion. Best regards, A Microsoft Copilot User
Edge Sync stuck in Initializing with Backend Uninitialized
Hello, I am hoping to get feedback from people familiar with Edge Sync internals, synchronization failures, or similar cases. OVERVIEW Around October 13, 2026, I discovered that my Favorites and saved Passwords were no longer visible in Microsoft Edge. The issue is present on both my desktop PC and my laptop using the same personal Microsoft account. Approximately two weeks later, the issue remains unchanged. What makes this case unusual is that authentication appears to work correctly, Edge Sync servers respond successfully, and encryption keys download successfully, yet the sync engine never completes initialization. ENVIRONMENT Microsoft Edge Windows 11 Personal Microsoft account Desktop PC Laptop The same symptoms occur on both devices. SYNC INTERNALS edge://sync-internals consistently reports: Transport State = Initializing Sync Engine State = Stopped Backend Status = Uninitialized Sync Feature Enabled = True Bookmarks = 0 Passwords = 0 Additional values: Download Key Result = Fail Set Key Result = Fail SIGN-IN STATUS edge://signin-internals reports: Successful authentication Successful token retrieval No authentication errors There is no indication of a Microsoft account sign-in problem. SYNC DIAGNOSTICS sync_diagnostic.log repeatedly shows: SyncState after authenticated = FeatureCanStart Try to start sync engine Load and connect Nigori controller Update key data credentials Reset engine The sync engine repeatedly attempts initialization but never reaches a running state. SERVER COMMUNICATION cv_debug.log reports: SYNC_SERVER_OK EncryptionKeysFetcher.DownloadKeys = Success Key count = 10 SetEncryptionKeys = Success This confirms that sync servers respond and encryption keys can be downloaded successfully. One unusual observation is that Sync Internals reports: Download Key Result = Fail Set Key Result = Fail while the logs simultaneously report successful key download and processing. PROFILE VERIFICATION Active profile: ...\Microsoft\Edge\User Data\Default During troubleshooting, a file named "Bookmarks" could not be located within the active profile. The following sync-related components remain present: Sync Data LevelDB Nigori.bin Logs MULTI-DEVICE IMPACT The same behavior is present on both desktop and laptop using the same Microsoft account. This makes a single-device profile corruption scenario seem less likely. NEW OBSERVATION After the initial failure, I created a new Favorites folder named: After Edge Sync Failure 20261013 The folder appeared correctly in the Favorites Bar. After Microsoft Edge and Windows were closed and restarted, the folder was no longer present. This suggests the issue may still be actively affecting local Favorites persistence and is not limited to historical sync data. ACTIONS NOT PERFORMED Based on recommendations received in Microsoft Q&A, I have intentionally avoided: Reset Sync Deleting the Edge profile Clearing all Edge data Reinstalling Edge The goal has been to avoid overwriting potentially recoverable sync data. PRIMARY QUESTION My main question is not whether synchronization currently works. My main question is whether the original Favorites and Password records may still exist within the Edge Sync service and whether there is any supported way to determine that before attempting potentially destructive recovery actions. QUESTIONS Has anyone seen this exact combination of Transport State = Initializing, Sync Engine State = Stopped, and Backend Status = Uninitialized persisting for weeks? Can a corrupted Nigori or encryption-key state cause Favorites and Passwords to report zero items despite successful authentication and successful key download? Has anyone recovered Favorites or Passwords after a similar state? Is there any supported method to determine whether the original sync data still exists on the sync backend before attempting Reset Sync? Does this pattern suggest an account-level sync corruption, backend corruption, or another known Edge Sync failure mode? Any technical insight would be greatly appreciated. Thank you.Autosave steals focus when typing in Outcome pane
When typing in the "new Outcome" pane, the focus is stolen every few keystrokes. This appears to correlate with the autosave triggering. Discovery version: 0.15.20 OS: Windows 11 To replicate: - Define a purpose. - Create a new outcome. - Type into the "Statement" field.
Edge on Android: Syncs personal data (e.g. history, payment methods), despite me turning them off
Sync settings chosen during first-run setup are ignored. All sync types get turned on. Steps taken Install Outlook. (Link: https://play.google.com/store/apps/details?id=com.microsoft.office.outlook ) Sign in to Outlook. Uninstall and re-install Edge. (Link: https://play.google.com/store/apps/details?id=com.microsoft.emmx ) Choose whether to set Edge as default browser. Tap the tiny blue text, which says "Sync settings". (Not the tiny blue text immediately underneath, which says "Microsoft Privacy Statement"). All sync types are turned on by default. Turn off all sync items except one, e.g. Passwords. Dismiss "Sync settings" Re-open "Sync settings", to confirm your settings are still there. Then dismiss it again. Sign in, or "Continue". Continue setting up Edge. Open the Edge menu. Tap your account Tap Sync. Result: ALL sync items are turned on, despite having turned them off in step 6. Request Is this bug fixed, in a later version of Edge? Note: This bug does not fit in the official feedback method for Edge for Android. I am hoping the helpful elves at the other end of the Edge feedback form are reading this question. Because I have sent them the link to https://learn.microsoft.com/en-us/answers/questions/6035494/edge-on-android-syncs-personal-data-history-paymen. My environment Google Pixel 10a Android 17 Edge version 155.0.4283.48 (also reproduced with earlier version: 154.0.4258.38) OR Edge Canary version 157.0.4338.0 (Downloaded 2026-10-19)
Android Enterprise System update expected behavior
What would be the expected behaviour when we set the System update to Automatic in the Android Enterprise Device restriction profile? We have several devices rebooting "randomly" and without notification and when we check the dumpstate logs, these reboots were triggered by an update: Canonical boot reason: reboot,enterprise,mainline_updbug. According to the Android documentation this could be correct: https://source.android.com/devices/tech/admin/ota-updates Since we don't see the same behaviour on all devices, while they share the same Update policy, I'm not sure what to expect from this setting?
File History problems after installing KB5124008, KB5126052,KB5126146, KB5122878, and KB890830
This morning, I ran Windows Update on two Windows 10/11 computers, but the file history feature stopped working completely after the update. Previously, after updating KB5120249 and KB5101684, files could still be backed up to the D: drive normally. The "Last Backup" time in "File History" is not updating correctly. Newly created or saved Word documents, pictures, videos, etc., still show "No previous version available" in "Content → Previous Versions". No folders were corrected; their dates are automatically updated. After running Windows Update again today, the file history feature stopped working on both computers. The File History panel pops up but cannot be used, prompting for a hard drive connection. (The hard drive is connected and I've confirmed it can read and write.) resulting in an "InconsistentState" entry in C:\Users\User\AppData\Local\Microsoft\Windows\FileHistory\Configuration. I'm very angry. If Microsoft doesn't address this, I'll keep complaining. If anyone else has encountered the same situation, please leave a comment below. You can also check Microsoft Q&A or the Microsoft Community Hub. The five updates installed are: September 8, 2026—KB5122878 (OS Builds 19045.7725 and 19044.7725) September 8, 2026-KB5126146 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10 Version 22H2 2026-09 Security Update (KB5124008) (26200.9445) 2026-09 .NET Framework Security Update (KB5126052) Windows Malicious Software Removal Tool x64 - v5.145 (KB890830) Deleting the %LocalAppData%\Microsoft\Windows\FileHistory folder also failed. Furthermore, "File History" itself is not listed in Microsoft's "Deprecated Features List." While other backup features suggest that Microsoft has no plans to discontinue it. Microsoft is going to pretend it doesn't exist. These worked normally before the update but stopped working afterward. This is to inform other users experiencing the same problem.
