Forum Widgets
Latest Discussions
Azure Default Outbound Access Changes: Guidance for Windows 365 ANC Customers
After March 31, 2026, newly created Azure Virtual Networks (VNets) will no longer have default outbound internet access enabled by default. Windows 365 customers choosing Azure Network Connection as a deployment option must configure outbound connectivity explicitly when setting up new VNets. This post explains what’s changing, who’s impacted, and the recommended actions, including Azure Private Subnets and Microsoft Hosted Network. What is Default Outbound Access (DOA)? Default Outbound Access is Azure’s legacy behavior that allowed all resources in a virtual network to reach the public internet without configuring a specific internet egress path. This allowed telemetry, Windows activation, and other service dependencies to reach external endpoints even when no explicit outbound connectivity method was configured. What’s changing? After March 31, 2026, as detailed in Azure’s communications, Azure will no longer enable DOA by default for new virtual networks, instead the VNet will be configured for Private Subnet option, allowing you to designate subnets without internet access for improved isolation and compliance. These changes encourage more intentional, secure network configurations while offering flexibility for different workload needs. Disabling Private Subnet option will allow administrators to restore DOA capabilities to the VNet, although Microsoft strongly recommends using Azure NAT Gateway. Impact on Windows 365 Azure Network Connection Customers For Windows 365 Azure Network Connection (ANC) deployments using virtual networks created after March 31, 2026, new VNets will default to private subnets. Outbound internet access must be explicitly configured for the VNet; otherwise, Cloud PC provisioning will fail. Existing virtual networks are not affected and will continue using their current internet access configuration. Note on Microsoft-hosted network: For Microsoft-hosted network deployments, which is the Microsoft recommended deployment model for Windows 365, Microsoft fully provides and manages the underlying connectivity in Azure on your behalf. There is no impact or change needed for those deployments. What You Should Do To prepare for Azure’s Default Outbound Access changes and ensure your Windows 365 ANC deployments remain secure and functional: Recommendations Transition to Microsoft-hosted network (MHN) if possible. MHN provides secure, cost-effective connectivity with outbound internet access by default, reducing operational overhead and ensuring compliance with Azure’s updated standards. Update deployment plans to ensure either an explicit NAT, such as a NAT Gateway or Default Outbound access (not recommended) is enabled by disabling the Private Subnet option. Test connectivity to ensure all services dependent on outbound access continue to function as expected, and that the ANC does not enter a failed state. Supported Outbound Access Methods To maintain connectivity, choose one of these supported methods: NAT Gateway (recommended) Note: Direct RDP Shortpath (UDP over STUN) cannot be established through a NAT Gateway because its symmetric NAT policy prevents direct UDP connectivity over public networks. Azure Standard Load Balancer Azure Firewall or third-party Network Virtual Appliance (NVA). Note, it is not recommended to route RDP or other long-lived connections through Azure Firewall or any other network virtual appliance which allows for automatic scale-in. A direct method such as NAT Gateway should be used. More information about the pros and cons for each method can be found at Default Outbound Access. Resources: Azure updates | Microsoft Azure Default Outbound Access in Azure Transition to an explicit method of public connectivity | Microsoft Learn Deploy Microsoft Hosted Network (MHN) QuickStart: Create a NAT Gateway Optimizing RDP Connectivity for Windows 365 | Microsoft Community Hub Quick FAQ Does this affect existing VNets? No. Only new VNets created after March 31, 2026, are affected. Existing VNets will continue to operate as normal. Do Microsoft Hosted Network deployments require changes? No. MHN already includes managed egress. What if I do nothing on a new VNet? ANC checks will fail because the VNet does not have internet access. Configure NAT Gateway or another supported method. What are the required endpoints? Please see here for a list of the endpoints required. Why might peer-to-peer connectivity using STUN-based UDP hole punching not work when using NAT Gateway? NAT Gateway uses a type of network address translation that does not support STUN (Simple Traversal Underneath NAT) based connections. This will prevent STUN-based UDP hole punching, commonly used for establishing peer-to-peer connections, from working as expected. If your application relies on reliable UDP connectivity between peers, STUN may revert to TURN (Traversal Using Relays around NAT) in some instances. TURN relays traffic between endpoints, ensuring consistent connectivity even when direct peer-to-peer paths are blocked. This helps maintain smooth real-time experiences for your users. What explicit outbound options support STUN? Azure Standard Load Balancer supports UDP over STUN. How do I configure Azure Firewall? For additional security you can configure Azure Firewall using these instructions https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?context=/azure/virtual-desktop/context/context . It is strongly recommended that a direct method of access is used for RDP and other long-lived connections such as VPN or Secure Web Gateway tunnels. This is due to devices such as Azure firewall scaling in when load is low which can disrupt connectivity. Wrap-up Azure’s change reinforces intentional networking for better security. By planning explicit egress (or choosing MHN), Windows 365 ANC customers can stay compliant and keep Cloud PCs reliably connected.
OneNote - Location, Name, Resolving Backup (& Search dropdown)
I recently had a problem with the Search function in OneNote - where Search was not finding words in recently created Notes. And I fixed that problem, eventually, by deleting all of the files in the OneNote cache. But after that, when restarting OneNote, it came up Empty (with Errors). After jacking around with copying the old OneNote folder and renaming it, Opening Backups, etc. - I finally got my OneNote back up and working (sort of - see paragraph at the end). My problem now is the "Info" is showing 2 Notebooks - "OneNote Notebooks 4" and "OneNote Notebooks 2" - and even worse, the location shown for Notebooks 4 is: https://onedrive.live.com/view.aspx?resid=562C6E59%21s0bcbd9618347485ca665bf8f3012d298&id=documents&end=()&end. I created Notebooks 4 on the advice for another post to get things running again - but, WHERE AM I? - which Notebook am I using? How do I get back to a single notebook at a reasonable location instead of the ridiculous link above. I also have a question about the OneNote locations shown in the "Save & Backup" option - I don't understand a couple of things there. [And a side note - even though OneNote Search is now working, the dropdown list is now showing the full path name for the Note location instead of the Page/Tab name for the location of the Note. Is there some option that I reset while trying to get OneNote working again.] I obviously need help with this one - and am afraid to mess around experimenting since OneNote is back up and working well (except for the dropdown). ron in shawnee
More than 30 minutes to install a language pack?
Happy new year to everyone. Is it normal that the Windows 365 PC , 2 core with 8GB RAM takes more than 30 minutes (still running) to install a language pack? I see lots of online discussions stating that the disk performance is terrible for this configuration and hence the performance. Any suggestions or words of advice would be appreciated.
Cannot Access Windows Hardware Developer Program in Partner Center — How to Sign Drivers in 2025?
Hi all, I'm trying to sign a Windows driver and need access to the Microsoft Windows Hardware Developer Program. **What I'm trying to achieve:** - Sign a driver for Windows using the standard Microsoft hardware signing process. **The issue:** - When I try to register for the Windows Hardware Developer Program, I get a message saying "Hardware Program is already in Active state". - However, when I go to Programs > Settings in Microsoft Partner Center, the Hardware Developer Program is NOT visible/available. - I have Global Admin permissions, and I’ve also tried using an account with Owner permissions — no difference, the Hardware Program is missing from the list. **My question:** - How do I get access to the Windows Hardware Developer Program if it's "Active" but not visible in the Partner Center? - Is there any way to manage or join the Hardware Program in 2025 if it's not listed? - Is there an alternative process for signing Windows drivers now? Any up-to-date guidance for 2025 would be super helpful. Any advice or escalation contacts would be highly appreciated! Thanks in advance.
Map only local drives and default printer from clients computer when logging into 365 Desktop?
Hello, I have gone into Intune and created a new config profile and have set Windows Components > Remote Desktop Services > Remote Desktop Session Host > Printer Redirection \ Device and resource redirection to let the users map drives and printers that are on their laptop into Windows 365 Desktop. However, how can we set it so that: 1. The only printers that are mapped to the 365 desktops from the client's device is the clients default printer and not any network printers that are installed on the laptop. 2. The only drives it maps into 365Desktop are the clients local drives like their SSD drive, and usb drives pluged in and not any network drives that are on the laptop.
26 ноября
Здравствуйте! Хочу обратиться в службу поддержки с целью продвинуть компанию Microsoft. Дело в том, что мой друг сегодня активировал Windows, чему предшествовало огромное количество шуток на эту тему. Я создал google-форму, а точнее петицию, в которой призываю граждан любой страны утвердить 26 ноября как праздник "Активации Windows". Я бы хотел, чтобы вы рассмотрели мою идею и, как основная сторона, согласились на это, а также расширили этот опрос в больших кругах. Прикрепляю ссылку на google-формы: https://docs.google.com/forms/d/e/1FAIpQLSfrlFcap22IUJhrLBeRp4C8tAcxlGRY_AMPVqxcQJjwxPB4Tg/viewform?usp=publish-editor С уважение, Дмитрий Translation: Hello! I want to contact support in order to promote Microsoft. The thing is, my friend activated Windows today, which was preceded by a huge number of jokes about it. I created a Google form, or rather a petition, in which I urge citizens of any country to establish November 26 as "Windows Activation" Day. I would like you to consider my idea and, as the main party, agree to it, as well as help spread this survey more widely. I am attaching the link to the Google form: https://docs.google.com/forms/d/e/1FAIpQLSfrlFcap22IUJhrLBeRp4C8tAcxlGRY_AMPVqxcQJjwxPB4Tg/viewform?usp=publish-editor Sincerely, Dmitry
Windows 365 Enterprise Cloud PC Connection Fails - VM Unavailable (Code 10012)
We are facing a critical and persistent connection failure for a Windows 365 Enterprise Cloud PC that appears to be stuck in a state where the VM is not available to the RDP client. Provisioning Policy Configuration: - Cloud PC Type: Windows 365 Enterprise - Experience: Access a full Cloud PC desktop - Use Microsoft Entra single sign-on: Yes - Join type: Microsoft Entra Join - Geography: Canada - Region: Automatic (Recommended) - Network: Microsoft hosted network - Current MDM -Microsoft Intune Checked logs and found that the RDP client connection attempts consistently failing with same error, Disconnected: reason = 10012 [Telemetry :: Event] Type: RDPClient Details: DisconnectReason Subdetails: SessionHostResourceNotAvailable Code: 10012 Troubleshooting steps taken so far: - Restarted the Cloud PC. - Initiated a Reprovision action. - Tried web version but that didn't help either. Since simple restarts and reprovisions have failed to resolve the SessionHostResourceNotAvailable (10012) error, the current VM instance is unusable. Any guidance on resolving this definitive Code 10012 error is highly appreciated.Save the date: Windows 365 AMA - What’s new from Microsoft Ignite
Tune in on December 3 for a special Windows 365 AMA. Catch up on the latest capabilities for Windows 365 announced at Microsoft Ignite! Host Christian Montoya and members of the product team will answer your questions live and offer insights to help you configure, deploy, and manage Windows in the cloud with ease. Save the date and post your questions early at aka.ms/Windows365AMA!Expanded TURN relay regions for Windows 365 and Azure Virtual Desktop
We’re excited to share that the rollout of expanded TURN relay regions for Windows 365 and Azure Virtual Desktop is now complete. TURN relay is available in all regions listed below. This new range—51.5.0.0/16—enhances RDP Shortpath connectivity and delivers faster, more reliable performance for Azure Virtual Desktop and Windows 365 users in 39 regions worldwide. What is TURN? TURN (Traversal Using Relays around NAT) enables devices behind firewalls to establish reliable UDP connections. With RDP Shortpath for public networks, TURN acts as a fallback when a direct UDP-based connection isn’t possible—ensuring low-latency, high-reliability remote desktop sessions. This new TURN relay range is part of the ‘WindowsVirtualDesktop’ service tag in Azure, making it easier for you to manage access and security configurations at scale. Benefits of the new TURN relay This change isn’t just a technical update—it’s a regional expansion. We’re scaling from 14 to 39 regions globally, bringing the TURN relay infrastructure closer to users, reducing latency, and improving connection reliability. Combined with a dedicated IP range for Azure Virtual Desktop and Windows 365 traffic, this initiative offers you more control, optimized routing, and a higher success rate for UDP-based communications. Here are the benefits in more detail: Expanding regional coverage By expanding from 14 to 39 regions globally, organizations will benefit from: Lower latency: Data travels shorter distances, resulting in faster connections and reduced lag. Improved reliability: Fewer dropped connections and more stable sessions, especially for real-time applications. Higher UDP success rates: Better performance for voice, video, and real-time data—even under variable network conditions. Dedicated IP Range for Azure Virtual Desktop and Windows 365 traffic This rollout introduces a dedicated IP range tailored for Azure Virtual Desktop and Windows 365 traffic, distinct from the ACS TURN relay. Benefits of this improvement include: Optimized traffic flow for Azure Virtual Desktop and Windows 365. Improved control over network security configurations. Customers can navigate restrictive security setups without compromising performance. Enhanced quality and speed for traffic, free from generic filtering Supported regions Here is a list of supported regions with the new TURN relay. A TURN relay is selected based on the physical endpoints, not the Cloud PC or session host. For example, a user physically located in the UK will use a relay in the UK South or the UK West regions. If the user is far from a supported region, the connection may fall back to TCP, potentially impacting performance. For example, a user physically located in the UK will use a relay in the UK South or the UK West regions. If the client is far from a supported region, the connection may fall back to TCP, potentially impacting performance. Accessible Your environment should have this subnet accessible from all networks used for Windows 365 or Azure Virtual Desktop connectivity, both on the physical network and cloud side. For Microsoft Hosted Network deployments in Windows 365 this underlying connectivity is already in place. For Azure Virtual Desktop and Windows 365 – Azure network connection ANC deployments, the ‘WindowsVirtualDesktop’ service tag contains this subnet so connectivity may already be in place. Optimized The subnet should also be optimized to ensure this critical, latency sensitive traffic has the most performant path available, this means: No TLS inspection on the traffic. This traffic is TLS encrypted transport with a nested TLS encrypted tunnel. TLS inspection yields no benefit but carries high risk of performance and reliability impact and puts significant additional load on the inspecting device. Locally egressed, meaning traffic is sent to Microsoft via the most direct and efficient path. In Azure this means directly routed onto Microsoft’ backbone and for customer side networks, directly to the internet where it will be picked up by Microsoft’s infrastructure locally. Bypassed from VPN, Proxy and Secure Web Gateway (SWG) tunnels and sent directly to the service as demonstrated in the example here. On the Cloud side this may involve using a User Defined Route (UDR) to send the Windows Virtual Desktop traffic direct to ‘internet’ instead of traversing a virtual firewall as can be seen in the example here. Learn more To learn more about RDP Shortpath and how to configure it for public networks, see our documentation on RDP Shortpath for Azure Virtual Desktop.
