Support tip: Upcoming Microsoft Intune network changes
12/18/25 Update - This post has been updated to include a new Azure Front Door (AFD) Connectivity Diagnostics Tool to help validate Intune network connectivity after firewall updates. We know many customers don’t always check their service change messages in the Microsoft 365 admin center or the corresponding Message Center content in the Microsoft Intune admin center, so in this blog post we’re highlighting an important upcoming change to Intune network service endpoints. Starting on or shortly after December 2, 2025, Intune will also use Azure Front Door IP addresses to improve security and simplify firewall management. If your organization uses outbound traffic policies based on IP addresses or service tags, you’ll want to review and update your firewall rules to avoid service disruptions. We’ll keep you updated if the timeline shifts. In the meantime, here’s the service change communication that posted to all Intune customers: MC1147982 - Action Required: Update firewall configurations to include new Intune network endpoints As part of Microsoft’s ongoing Secure Future Initiative (SFI), starting on or shortly after December 2, 2025, the network service endpoints for Microsoft Intune will also use Azure Front Door IP addresses. This improvement supports better alignment with modern security practices and over time will make it easier for organizations using multiple Microsoft products to manage and maintain their firewall configurations. As a result, customers may be required to add these network (firewall) configurations in third-party applications to enable proper function of Intune device and app management. This change will affect customers using a firewall allowlist that allows outbound traffic based on IP addresses or Azure service tags. Do not remove any existing network endpoints required for Microsoft Intune. Additional network endpoints are documented as part of the Azure Front Door and service tags information referenced in the files linked below: Public clouds: Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center Government clouds: Download Azure IP Ranges and Service Tags – US Government Cloud from Official Microsoft Download Center The additional ranges are those listed in the JSON files linked above and can be found by searching for “AzureFrontDoor.MicrosoftSecurity”. How this will affect your organization If you have configured an outbound traffic policy for Intune IP address ranges or Azure service tags for your firewalls, routers, proxy servers, client-based firewalls, VPN or network security groups, you will need to update them to include the new Azure Front Door ranges with the “AzureFrontDoor.MicrosoftSecurity” tag. Intune requires internet access for devices under Intune management, whether for mobile device management or mobile application management. If your outbound traffic policy doesn’t include the new Azure Front Door IP address ranges, users may face login issues, devices might lose connectivity with Intune, and access to apps like the Intune Company Portal or those protected by app protection policies could be disrupted. What you need to do to prepare Ensure that your firewall rules are updated and added to your firewall’s allowlist with the additional IP addresses documented under Azure Front Door by December 2, 2025. Alternatively, you may add the service tag “AzureFrontDoor.MicrosoftSecurity” to your firewall rules to allow outbound traffic on port 443 for the addresses in the tag. If you are not the IT admin who can make this change, notify your networking team. If you are responsible for configuring internet traffic, refer to the following documentation for more details: Azure Front Door Azure service tags Intune network endpoints US government network endpoints for Intune If you have a helpdesk, inform them about this upcoming change. If you need additional assistance, contact Microsoft Intune Support and refer to this Message Center post. Note: The above post went to all customers in our public cloud. Customers in Microsoft Intune for US Government GCC High and DoD received the following post (the only difference is the focus on US government network endpoints): MC1147978 - Action Required: Update firewall configurations to include additional Intune network endpoints Note: The previously available PowerShell scripts for retrieving Microsoft Intune endpoint IP addresses and FQDNs no longer returns accurate data from the Office 365 Endpoint service. Instead, use the consolidated list provided in the Intune endpoints documentation. Using the original scripts or endpoint lists from the Office 365 Endpoint service is insufficient and may lead to incorrect configurations. For network best practices, make sure to check out the blog: Support tip: Aligning network policy with Intune and Zero Trust. New: Azure Front Door Connectivity Diagnostics Tool for Intune To help you validate or troubleshoot the recent Intune network changes, we’ve published a lightweight Azure Front Door (AFD) Connectivity Diagnostics Tool. The script tests DNS resolution, outbound TCP connectivity on ports 80 and 443, and HTTPS reachability to the AFD IP ranges used by Intune, directly from an Intune-managed device. This is useful for environments that rely on IP-based firewall, proxy, or VPN rules. Important: This script only tests Azure Front Door (AFD) endpoints. It does not validate connectivity to non-AFD Intune endpoints, including existing Intune IPs, service FQDNs, or related services such as Windows Notification Service (WNS) or Windows Autopilot. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn. Post updates: 11/13/25: Added a note to use the consolidated list of Intune endpoints. 12/18/25: We’ve published a new Azure Front Door (AFD) Connectivity Diagnostics Tool to help validate and troubleshoot Intune connectivity after updating firewall rules.
Windows 11 has got to be the worst Operating System I've ever used in my life
I've never ever been this disappointed in a software product as much as I am disappointed with Windows 11. I've always held onto the current WIN for as long as I could, and last month I bit the bullet and thought I'd give WIN11 a go, and I'm regeretting it ever since. It's not even, "omg this is new, I don't know how to use it" type of frustration - no, the OS is a complete mess, it's unstable, messy, unprofessional, and the entire thing felt fake and dysfunctional on so many levels. It really makes my blood boil. When I drag the volume all the way down in the sound mixer, it doesn't mute the app, I have to click on the app icon itself When I select a lot of files, and I click in that little small gap in-between each file, it deselects all of them When I have a lot of windows open and I would hover over them to select one, it rarely catches it from the first try. I'd click the window I want to use and it never selects it If I have a file path selected in a window, I click away, and I click back again on that window, I get the drop down list of paths that lead to that path and I end up clicking on a completely different path that would take me out of the window I selected When I click on and out of a folder, it updates in the Quick Access bar and in doing so, it glitches the entire UI across all windows open I could go on and on and on, this has got to be the worst product I've ever used. I have a couple big projects I'm finishing now, but after I'm done, I'm going back to Windows 10, and I'd stay with that until it gets hacked by Anonymous or something. My lord what a joke of a product.
Windows Hello Interrupts Live Presentations and Demos — A Clear Case for Presentation Mode
I rely on my Windows device during my two‑hour classes to deliver presentations, demos, and instruction, and it’s essential that the screen remain awake and unlocked throughout. Despite configuring all relevant power and presence settings, Windows Hello still disrupts the class by forcing the device to the lock screen — and the setting that should prevent this is greyed out and unavailable. Context I teach two‑hour classes and use my Windows 11 laptop to present materials, run demos, and guide discussions. During class, the device must remain: awake unlocked connected to the projector responsive However, the laptop repeatedly reverted to the lock screen mid‑lecture, interrupting the presentation and forcing re‑authentication in front of students. What I Tried I addressed every obvious cause: Power Plans I created custom power plans for the classroom and office, switched via script, and disabled: display timeout sleep lid‑close actions Modern Standby transitions Presence Sensing I permanently disabled Presence Sensing, which was turning off the display when I stepped away from the lectern. These changes solved most issues — except Windows Hello. The Remaining Problem Even with all power settings configured, Windows Hello still timed out and returned to the lock screen. The setting “If you’ve been away, when should Windows require you to sign in again?” was permanently greyed outand set to Every time. This meant Windows Hello was overriding all power plan behavior. Root Cause After extensive troubleshooting, I discovered that: enabling Windows Hello combined with using a Microsoft account, OneDrive, Teams, or Office 365 causes Windows to silently provision Windows Hello for Business (WHfB) even on personal devices. Once WHfB is active: idle‑lock becomes mandatory, the timeout setting is disabled, and the UI no longer reflects the system's true state. This occurs even when: the device is not Azure AD joined, the device is not Intune‑managed, all work accounts are disconnected, and Hello is used only for convenience, not for enterprise identity. In short, the OS presents idle‑timeout as a user preference, but silently removes that choice as soon as Windows Hello is active. Impact on Teaching and Presenting Teaching and presenting require the device to: stay unlocked, keep the display active, avoid interruptions, ignore Presence Sensing, and maintain stable external display output. Before Modern Standby and WHfB, Windows supported this through Presentation Mode, which temporarily suspended lock and sleep behavior. Modern Windows removed Presentation Mode; there is no equivalent system‑level override. The result is: screens locking mid‑lecture, forced PIN/biometric prompts, display dropouts, Presence Sensing interruptions, and disrupted instruction. This is not a security improvement — it’s a workflow regression. The Architectural Gap There is currently no supported way to: use Windows Hello, and use Microsoft cloud services, and control idle‑lock behavior. The OS assumes that anyone using Hello must want enterprise‑grade identity protection, even on personal devices and even in teaching, presenting, or demonstrating scenarios. Why a System‑Level Mode Would Improve Security Right now, users must attempt to manage: power plans display timeouts sleep settings Presence Sensing Windows Hello behavior Modern Standby quirks This patchwork approach is error‑prone and often leads users to disable security features permanently. A system‑level mode would: make the behavior explicit, make it temporary, ensure the device returns to secure defaults afterward, reduce accidental misconfiguration, and provide predictable, intentional control. This strengthens security by replacing ad‑hoc workarounds with a single, reversible, auditable mode. Proposed Solution: A Modern Presentation Mode Windows needs a system‑level Presentation Mode — ideally a Quick Settings toggle (like Airplane Mode) — that: temporarily suspends WHfB idle‑lock, temporarily suspends Presence Sensing, temporarily suspends Modern Standby, prevents display‑off and lockscreen activation, maintains stable external display output, and restores all prior settings when turned off. This would support teaching, presenting, training, and demo workflows that Windows has historically handled well. Conclusion Windows Hello for Business assumes it can automatically determine a device's security context and defaults to an enterprise‑first posture. But many real‑world scenarios — including teaching, presenting, and live demonstrations — do not fit that model. In these cases, WHfB’s assumptions break down. Without a system‑level override, users have no way to signal that the device must remain awake and unlocked for a limited, intentional period. A modern Presentation Mode would provide that missing signal. It would honor WHfB’s security objectives while giving users a deliberate, temporary way to suspend idle‑lock and related behaviors during time‑bounded workflows. Just as importantly, it would ensure the device returns to its standard security posture afterward, reducing the need for ad‑hoc workarounds or permanent configuration changes. I welcome feedback from Microsoft PMs or MVPs on whether a modern Presentation Mode could be considered for future Windows releases.
