Critical Pen Hover & Stray Ink Issue on New Surface Pro 11 for Business with Slim Pen 2
Hello Microsoft Community and Support Staff, I am writing to report a critical and seemingly widespread issue with the pen input on the brand-new Surface Pro for Business, 13-inch (Intel model, often called Surface Pro 11 "Luna Lake"). The Core Problem: Pen Draws Without Touching the Screen When using the Surface Slim Pen 2, the device begins to register ink input while the pen is still hovering a few millimeters above the screen. It does not require any physical contact or pressure. This "hover-inking" makes handwriting completely unusable. As I write, any time I lift the pen to start a new letter or stroke, the pen continues to draw a line as it moves through the air to its next position. This results in messy, connected handwriting with unwanted "tails," completely defeating the purpose of having a premium inking device. This is Not a Defective Unit - It's a Replicable Problem Initially, I thought I had a faulty device. However, to isolate the issue, I have performed extensive testing: I have personally tested this on [3] brand-new Surface Pro 11 (Intel) devices. I have used [4] different Slim Pen 2s. The exact same hover-inking problem occurred on every single combination of device and pen. Furthermore, I have already performed all standard troubleshooting steps, including: Clean OS installation via Surface Recovery Image. Ensuring all Windows, driver, and firmware updates are installed. Running the Surface Diagnostic Toolkit (which reported no errors). However, the same issue continues to occur even after trying these methods. Additionally, it has been reported that the issue also appears on the latest Surface Pro 12-inch model with the Snapdragon X Plus, just like on the Surface Pro 11 that uses the Qualcomm Snapdragon X Elite instead of Intel’s Lunar Lake. (I do not own any Snapdragon devices myself. If you own a Snapdragon device and are experiencing the same issue, please share your feedback.)" Video Evidence: I have recorded a clear video demonstrating the problem. It shows the pen drawing while hovering on the Surface Pro 11 and makes unwanted tails on handwriting letters. Video Link: https://youtube.com/playlist?list=PLG_7BXFA-cL4evqe0RmRz--iFjDC1HVgT&si=EmEypaAqSyRozr67 Questions for Microsoft: Is this a known issue with the new Surface Pro 11 (Intel) model's firmware or drivers? What are the official steps to escalate this issue directly to the Surface engineering team for a fix? This is a major flaw in a flagship product that severely impacts its core functionality. I have submitted a formal bug report through the Feedback Hub, which can be found here: Feedback Hub Link: https://aka.ms/AAxzh27 I urge the Microsoft team to investigate this with high priority and release a firmware or software update to recalibrate the pen's Initial Activation Force (IAF). Thank you for your attention to this serious matter.New policy implementation and web enrollment for Android personally owned work profile
We’re happy to announce two improvements for the management of Android personally owned work profile devices with Microsoft Intune, which will be available in late Q2 of calendar year 2026. 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. Action may be required by you as we move to the new implementation. 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: A URL (new!) Productivity apps (when admin has configured conditional access so that the user is required to enroll before accessing corporate resources) The Company Portal app This gives you more options for how to guide your users to get set up. 3. Android enrollment is more consistent with the iOS web-based enrollment flow. How to configure and monitor Web based enrollment We will release a new setting that will allow you to switch your tenant to the new web-based enrollment for all personally owned work profile enrollments going forward. 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. Later on, we’ll automatically configure all personally owned work profile enrollments across all tenants to be web enrollments. New implementation We’ll release a new configuration policy that 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. Later on, Intune will automatically migrate all remaining devices using the custom DPC implementation over to the new AMAPI implementation. Monitoring There’ll be a new report that will show 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 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 We'll update these timelines to provide more specific timeframes in the coming months. 2025: Use this time to revise any relevant policy configurations, update your internal documentation, and prepare your helpdesk teams, as advised below. Late Q2 of calendar year 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. Later on: 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 AM API. 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. 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. Password: There will be some minor changes to how some configurations of password requirements apply on some devices. We will update to provide more information and guidance. 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.
Bug na bateria após atualização em 06/05/2026
Olá, pessoal. Tenho um notebook com processador Intel Core i5 de 11ª geração e faço parte do Programa Windows Insider. Na quarta-feira, 06/05/2026, por volta das 16h, ao desligar o notebook, apareceu a opção de atualização. Selecionei “Atualizar e desligar”. Aguardei o desligamento, fechei a tampa e deixei o equipamento conectado ao carregador, com aproximadamente 80% de bateria. Por volta das 18h, ao sair para dar aula, levei o notebook sem o carregador. Ao chegar à instituição e ligar o equipamento, ele permitiu apenas digitar a senha de login e desligou completamente, sem possibilidade de religar. Ao retornar para casa, conectei o carregador e o sistema indicava bateria em 0%. Aguardei cerca de 30 minutos, mas o nível de bateria não aumentou. Depois de alguns minutos conectado, consegui iniciar o notebook, porém a bateria continuava marcando 0%. Verifiquei o Windows Update e havia uma atualização não concluída. Tentei corrigir removendo a atualização e baixando novamente, mas ela não finalizava. Durante todo o dia 07/05/2026, tentei atualizar novamente, sem sucesso. O notebook ficou muito lento e a bateria continuava em 0%. Na sexta-feira pela manhã, 08/05/2026, após deixar o equipamento durante a madrugada baixando a atualização, ela chegou a 99%, mas não concluiu. Resolvi então restaurar o sistema, escolhendo a opção de manter aplicativos e arquivos. A restauração foi concluída com sucesso. O equipamento voltou ao normal em desempenho e, no primeiro reinício, a bateria voltou a aparecer com 100%. Realizei testes de carga e descarga durante a manhã de 08/05/2026 e utilizei o equipamento normalmente à tarde. Na manhã de 09/05/2026, notei algo estranho: a bateria ainda estava em 100%, mesmo após o notebook passar a noite hibernado. Continuei trabalhando e, de repente, o equipamento desligou sem qualquer aviso de bateria fraca. Ao conectar novamente o carregador e iniciar a máquina, a bateria voltou a ficar travada em 0%, mesmo após mais de 2 horas conectada. Ao verificar as atualizações, percebi que as mesmas atualizações estavam novamente disponíveis. Já removi a inscrição no Programa Windows Insider e desinstalei as atualizações recentes, mas isso não alterou a situação. Entrei em contato com o suporte da Microsoft e fui orientado a relatar o caso aqui, pois, por participar do Programa Insider, pode se tratar de um bug relacionado a alguma versão que esteja em conflito com o gerenciamento da bateria. Pretendo restaurar novamente a máquina para verificar se o funcionamento volta ao normal. As atualizações relacionadas são: * KB5073032 - 2025.11 * KB5082257 * KB5082417 Gostaria de saber se outros usuários do Programa Insider tiveram problema semelhante envolvendo atualização, bateria travada em 0% ou falha no gerenciamento de energia após atualização recente.Edge Dev on Windows - Tab sync not working
Just wondering if anyone else is seeing a bug where on Windows and Edge Dev (latest version), tab sync just says "No tabs from other devices". But if you go to Edge Stable, it does show open tabs. It also shows my recent tabs with Edge Dev on Android, so I know the sync is working, just the desktop client is not showing them. I've sent feedback for this issue but since sync is still working correctly, I am wondering if this is a UI bug.
Mute/unmute hotkey stopped working in main windows during presentation
In recent versions I have been able to press CTRL + SHIFT+ M when I was presenting (sharing) something from my Teams main window. Recently this stopped working and I need to go forth and back from main window to the my call window to mute myself. Could you please restore the old behavior. Thank you! Best regards Tom
Critical Edge Sync issue after Win11Pro reinstall – incomplete rehydration
A - ENGLISH VERSION Critical Edge Sync issue after Windows 11 Pro reinstall – incomplete rehydration, Device Info = 5, modules stuck Hello, I am experiencing a major issue with Microsoft Edge synchronization after a full reinstall of Windows 11 Pro. Despite multiple reinstalls, several days of waiting, and all possible local troubleshooting steps, Edge Sync remains incomplete, and none of my historical data is rehydrated. Below is the full context, timeline, symptoms, technical observations, and questions. 1) Full chronological context 1.1 – Full PC reset Clean Windows 11 Pro reinstall Sign‑in with Microsoft personal account Windows Insider Program activated (Beta channel) 1.2 – Edge Beta installed automatically Edge Beta was installed automatically without warning. I suspected it might be the cause of the incomplete sync. 1.3 – Leaving the Insider Program I left Insider only to try restoring full Edge synchronization. 1.4 – New Windows 11 Pro 25H2v2 reinstall Clean install Edge Stable installed Sync enabled Several days of waiting 1.5 – Result: sync still incomplete Even on Edge Stable, historical data never returns. 2) Symptoms 2.1 – Missing data No previous tab groups restored Incomplete history “Other devices” sessions missing Passwords visible in settings but not rehydrated No data from my previous Windows 11 PC 2.2 – Sync modules stuck In edge://sync-internals: Saved Tab Group: frozen for days Passwords: “Running” but no data rehydrated Sessions: incomplete Typed URLs / History: partial 2.3 – Device Info = 5 The cloud still lists 5 devices, including my previous Windows 11 installation. This indicates that historical data should be available. 2.4 – Last Synced active Sync is active, but missing data is never returned. 3) Technical diagnosis Everything points to a “consistent but incomplete” cloud profile state: Client sync works Server reports sync as healthy Historical data is never rehydrated Critical modules remain stuck Issue reproduces across multiple devices (Win10, Win11) This suggests a server‑side Edge Sync profile corruption, or a metadata divergence after: Insider → Stable channel change Windows reinstall Local profile deletion Edge Beta auto‑installation Microsoft account reconnection 4) Key question: Is Edge Beta limited in synchronization? I would like an official clarification: → Does Edge Beta restrict any sync modules? → Are Saved Tab Group, Sessions, or Passwords limited in Edge Beta? → Are there backend differences between Edge Stable and Edge Beta? If Edge Beta is not the cause, I will gladly re‑enable my Insider profile. I left Insider only to attempt restoring full sync. 5) Request I kindly request: → A backend analysis of my Edge Sync profile, to check: metadata integrity module states device list consistency possible corruption ability to rehydrate historical data I can provide: sync‑internals screenshots logs additional details multi‑device testing Thank you very much for your help. B - VERSION FRANÇAISE Problème critique de synchronisation Edge après réinstallation Windows 11 Pro – réhydratation incomplète, Device Info = 5, modules bloqués Bonjour, Je rencontre un problème majeur avec la synchronisation Microsoft Edge, apparu après une réinitialisation complète de mon PC Windows 11 Pro. Malgré plusieurs réinstallations, plusieurs jours d’attente, et toutes les procédures locales possibles, la synchronisation reste incomplète, et mes données antérieures ne sont jamais réhydratées. Je détaille ci‑dessous l’ensemble du contexte, les étapes, les symptômes, les observations techniques et les questions. 1) Contexte chronologique complet 1.1 – Réinitialisation complète du PC Réinstallation Windows 11 Pro “vierge” Connexion au compte Microsoft personnel Activation du programme Windows Insider (canal Bêta) 1.2 – Edge Bêta installé automatiquement Sans avertissement ni information, Edge Bêta a été installé automatiquement sur mon système Insider. Pensant que Edge Bêta pouvait être la cause d’une synchronisation incomplète, j’ai tenté de revenir à Edge Stable. 1.3 – Sortie du programme Insider J’ai quitté le programme Insider uniquement pour tenter de retrouver une synchronisation Edge stable et complète. 1.4 – Nouvelle réinstallation Windows 11 Pro 25H2v2 Installation propre Edge Stable installé automatiquement Synchronisation activée Plusieurs jours d’attente pour réhydratation 1.5 – Résultat : synchronisation toujours incomplète Même après retour à Edge Stable, les données antérieures ne reviennent pas. 2) Symptômes observés 2.1 – Données manquantes Aucun groupe d’onglets antérieur n’est restauré Historique incomplet Sessions “Autres appareils” très partielles Mots de passe visibles dans les paramètres mais non réhydratés dans l’interface Données provenant de mon ancien PC Windows 11 absentes 2.2 – Modules Edge Sync bloqués Dans edge://sync-internals : Saved Tab Group : valeur figée depuis plusieurs jours Passwords : module “Running” mais aucune donnée réhydratée Sessions : incomplètes Typed URLs / History : partiels 2.3 – Device Info = 5 Le cloud conserve encore les identifiants de 5 appareils : PC Windows 10 Smartphone PC Windows 11 actuel PC Windows 11 avant réinstallation PC Windows 11 Insider (Edge Bêta) Cela prouve que les données de l’ancien appareil devraient être disponibles, mais ne sont pas renvoyées au client. 2.4 – Last Synced actif La synchronisation est active, mais ne renvoie pas les données manquantes. 3) Diagnostic technique Tout indique un état “cohérent mais incomplet” du profil cloud Edge : Le client synchronise correctement Le serveur considère la synchronisation comme valide Mais les données historiques ne sont jamais renvoyées Les modules critiques (Saved Tab Group, Passwords, Sessions) restent bloqués Le problème est identique sur plusieurs appareils (Win10, Win11) Cela suggère une corruption du profil Edge Sync côté serveur, ou une divergence entre métadonnées locales et cloud après : changement de canal (Insider → Stable) réinstallation Windows suppression du profil local Edge Bêta imposé réactivation du compte Microsoft 4) Question cruciale : Edge Bêta est‑il bridé dans la synchronisation ? Je souhaite obtenir une réponse officielle : → Edge Bêta limite‑t‑il certaines fonctions de synchronisation ? → Certains modules (Saved Tab Group, Sessions, Passwords) sont‑ils restreints dans Edge Bêta ? → Existe‑t‑il des différences de backend entre Edge Stable et Edge Bêta ? Si Edge Bêta n’est pas en cause, je serai heureux de réactiver mon profil Insider. J’ai quitté Insider uniquement dans l’espoir de retrouver une synchronisation complète. 5) Demande Je sollicite : → Une analyse backend de mon profil de synchronisation Edge pour vérifier : l’intégrité des métadonnées l’état des modules la cohérence des appareils la présence ou non d’une corruption la possibilité de réhydrater les données historiques Je suis prêt à fournir : captures edge://sync-internals journaux détails supplémentaires tests sur plusieurs appareils Merci d’avance pour votre aide.
UI overflow in extension permission dialog on Linux (Gnome)
When installing an extension, the permission dialog renders incorrectly and overflows its container. The dialog content appears clipped and does not scale properly within the window. This affects usability because parts of the UI (text/buttons) may be partially hidden depending on window size and display scaling. MS Edge version: Version 149.0.3993.0 (Official build) dev (64-bit) To reproduce: Open Microsoft Edge on any Linux distro using Gnome Navigate to the extension store Attempt to install an extension (e.g. AdGuard AdBlocker) Observe the permission popup dialog
