Passkey best practices for Windows 365 users on unmanaged devices (BYOD)?
I have global contractors who work from home so spinning up Windows 365 Enterprise Cloud PCs are ideal. The contractors work from from either their personal Mac or personal Windows PC using the Microsoft Windows app so each user can access their dedicated Windows 365 Cloud PC and everything has been working well so far using standard MFA. We are looking to move everyone to passkeys but there is no intuitive documentation on how end users are expected to adopt it so they can use passkeys to 1) access the virtual PC and then use passkeys while in the virtual PC itself. Seems Microsoft explains everything under the hood except how to practically roll it out to reliably replace standard MFA. What is the recommended path forward to migrate my BYOD virtual PC users to passkeys? Thanks, Charlie
Windows 365 and developer environments: how do you balance security and productivity?
Hi everyone, I’d like to raise a topic that we are currently struggling with, and I suspect many other organizations are facing the same challenge. We are in the process of establishing a Windows 365–based development environment, where developers work in Cloud PCs. This is largely driven by: a BYOD strategy security requirements (no sensitive code on unmanaged devices) the need for standardization However, this quickly becomes complex in practice. The core challenge We are trying to balance three competing priorities: 1. Security requirements No sensitive code on local devices Minimal attack surface Zero Trust principles and Conditional Access Full traceability of identity and actions 2. Developer needs Local admin rights to be able to do their work Freedom to install tools, SDKs, and runtimes Flexibility without constant blocking Fast iteration cycles The reality is that if it takes too long to get access or permissions, it breaks the developer workflow. 3. IT and governance Standardization of environments Manageability and patching License and cost control Compliance and auditability The practical dilemma Developers want to be local admins on their machines Security teams prefer: Just-In-Time access (PIM), or No admin privileges at all In practice: PIM tends not to work well for developers It introduces too much friction It disrupts flow and often leads to workarounds What we are currently exploring We are testing a model where: Developers work in Windows 365 Cloud PCs They use their regular corporate identity (Entra ID) Isolation is achieved through the environment, not separate accounts Developers have local admin rights within the Cloud PC However, this raises a new question: How do we secure an environment where the user is an admin? Questions to the community I would really appreciate insights from others who have been through similar scenarios: 1. Identity vs privilege Do you use the same identity for everything, or separate user/admin accounts? How far do you take identity separation? 2. Local admin rights Do you allow developers to have local admin rights? Is it permanent or Just-In-Time? If JIT, how do you make it work without impacting productivity? 3. Cloud-based development environments If you are using Windows 365, Dev Box, or AVD: Has this made it easier to relax restrictions? Or are you facing the same challenges, just in the cloud? 4. Guardrails instead of restrictions Instead of trying to prevent everything: EDR / endpoint protection Conditional Access Network isolation Monitoring and detection Has anyone successfully shifted from strict control to strong guardrails and detection? Current reflection I am starting to think that: Focusing on secure, isolated environments for development may be more effective than trying to tightly control every individual action. In other words: secure the platform not every single user behavior But this is far from straightforward. Purpose of this discussion The goal is to find a realistic blueprint that: maintains high developer productivity meets security requirements minimizes friction in day-to-day work Not something theoretically perfect, but something that actually works. If you have experience in this area, I would really value your input: what has worked well what has not worked key design decisions you would recommend Thanks in advance.Expanding the Reach of AI-enabled Cloud PCs for Frontier Firms
Co-Authored by Lakshmi Rayasam Over the past several months, we’ve been focused on a clear goal: making AI-enabled Cloud PCs easier to adopt, easier to deploy, and available to more customers—wherever they are. Following the momentum from Ignite, releasing Improved Search & Click to Do, we’ve continued to evolve the AI-enabled Cloud PC experience in Frontier Preview, prioritizing scale, accessibility, and product market fit. The latest set of enhancements removes deployment blockers and expands where—and how—customers can get started. We’ve also added a new refreshing AI-enabled end-user experience explaining the value of Frontier while users hover over the AI-enabled (Frontier) tag. Note: Future availability of these features is dependent on the results of this Frontier Preview and is subject to change Removing the need for Windows Insiders AI‑enabled Cloud PCs now work with standard Windows 11 retail builds, eliminating the need for Windows Insider participation. This change alone unlocks broader enterprise deployment scenarios and removes a major barrier for production use. AI-enabled Cloud PCs are just one toggle away as IT admins can join our Frontier Program and enable AI-enabled Cloud PCs via a newly introduced policy setting within the Devices – Onboarding: Windows 365 > User Settings blade, and further filter access based on Microsoft Entra ID group access. Note: After enrolling the latest Windows 11 25H2 (OS Build 26200.7840 or higher) you must reboot your Cloud PC. Expanded regional availability To meet customers where they operate, we’ve expanded AI‑enabled Cloud PCs to additional Azure regions:‑ Japan East Germany West Central South Central US Canada Central This expansion improves latency, supports data residency needs, and enables more global customers to participate in the Frontier Preview. 128GB disk support for Windows 365 Enterprise We’ve added support for 128GB disk size Windows 365 Enterprise licenses, offering greater flexibility for customers who don’t require larger footprints while still enabling AI‑driven workflows. These right‑sized deployments and makes it easier to scale across broader user populations. Together, these updates directly address the most common Ignite feedback and are expected to unlock large‑scale deployments, including enterprise pilots transitioning into sustained usage. What Comes Next Following the March rollout, our CY26 focus shifts to closing parity gaps using cloud‑based models, in close partnership with Windows platform teams. Initial work centers on enabling Text Actions for Click‑to‑Do via a cloud models within Frontier Preview—one of the most requested capabilities from customers.‑‑‑ In parallel, we’ll continue investing in foundational improvements that increase perceived feature depth and usage signals, including cost optimization, reliability enhancements, and productivity scenarios that compound value across the Cloud PC experience.Azure Default Outbound Access Changes: Guidance for Windows 365 ANC Customers
Editor’s note, March 27, 2026: An earlier version of this post listed Azure Load Balancer (SLB) as a supported outbound access method option for Windows 365 ANC. This has been updated. SLB is not a supported outbound access method for ANC. 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 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. Unsupported Outbound Access Methods Azure Standard Load Balancer Azure’s Standard Load Balancer is not supported as an outbound access method for ANC. Instead, using NAT Gateway is recommended. 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. 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.
MS designer is NOT WORKING!
It only makes 1 image not 4, it takes way too long time,. and it doesnt follow prompting,. and it makes imegs in 3:2 not 16:9... thsi has been goign on for over 2 weeks,... alsmot 3.. i have been in contact with support many times woith zero help.. HOW can you have a product in your office bunlde ant it not workign an zero supprot on it? I need teh application to make my videos,. im just abptu to cancel all subscritopons to micrposft an switch to apple..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!Multimedia Redirection and WebRTC Redirector plug-in updates for Windows 365 & Azure Virtual Desktop
Automating plug-in maintenance with GitHub Scripts Keeping your Windows 365 and Azure Virtual Desktop environment up to date is crucial for optimal performance and security. Two essential plug-ins, Multimedia Redirection service and WebRTC (Web Real-Time Communication) redirector service, require periodic updates. However, these plug-ins do not update automatically, which can lead to compatibility or performance issues if left unattended. Understanding the Challenge Unlike most of the components of Windows 365 and Azure Virtual Desktop, both the Multimedia Redirection and WebRTC plug-ins must be updated manually. This manual process can be time-consuming for IT administrators and disruptive if not managed properly, especially in enterprise environments where user experience and uptime are top priorities. Cloud PCs that are provisioned or reprovisioned with Gallery images do have the latest plug-ins installed and Azure Virtual Desktop session hosts deployed with Azure Marketplace images have the latest WebRTC plug-in installed. But as these Cloud PCs and Session Hosts age, these plug-ins will become outdated over time. Note: Windows 365 Gallery images that include the latest Multimedia Redirection and WebRTC plug-ins are only the Windows Enterprise + Microsoft 365 Apps images. For Azure Marketplace images, only the Windows multi-session + Microsoft 365 Apps images include the latest WebRTC plug-in. Features dependent on WebRTC and Multimedia Redirection WebRTC: Microsoft Teams media optimizations Users connect from non-Windows physical endpoints Users connect from Windows endpoints and SlimCore fails Multimedia Redirection: Video playback and call redirection on Edge or Chrome browsers Users who visit websites with embedded videos Users who use Contact Center as a Service (CCaaS) solutions Manually Updating Administrators can update these binaries by deploying their respective MSI installers to users’ Cloud PCs and personal Session Hosts either through Intune or their management engine of choice. This may be the simplest way of upgrading endpoints, but there is a chance that end users would be disrupted during their work because WebRTC installer will forcefully stop Teams processes while installing, and Multimedia Redirection could break video streams or calls while the binaries are upgraded. If choosing this method, administrators should leverage maintenance windows to minimize disruptions. The MSI installers can be manually downloaded from the links below: WebRTC redirector installer MSI Multimedia redirector installer MSI Automating Updates with GitHub Scripts To address this challenge, our team has developed a series of PowerShell scripts available in our GitHub repository. These scripts automate the update process for both Multimedia Redirection and WebRTC plug-ins, ensuring that the latest versions are installed without the need for direct user intervention. The benefits of these scripts are: No End User Impact: The scripts are designed to run silently in the background, so end users experience no downtime or interruptions. Consistent Plugin Versions: Automated updates help maintain consistency across all Windows 365 instances, reducing troubleshooting time and compatibility issues. Easy Integration: The scripts can be deployed with Intune via Remediations, or as a standalone script. Remediations provides the best admin experience as it will report back on compliance and any errors encountered during deployment. Getting Started To begin using the automated update scripts: Visit our GitHub repository and download the latest versions of the update scripts. WebRTC Updater Multimedia Redirector Updater Review the step-by-step setup and configuration instructions. Deploy the scripts to your Windows 365 or Azure Virtual Desktop environment, either in standalone mode or with Remediations. IMPORTANT: The scripts currently do not support Windows Multi-Session hosts. Updating Azure Virtual Desktop Multi-Session Hosts Updating these plugins should be done during the build process of the golden image or the Session Hosts. This can be achieved by using an automated building solution, like Azure Image Builder, to install the latest versions. The URLs for these plugins are static, meaning that administrators can use the same URL without having to be concerned about the version that is being downloaded. For reference, the URLs are below: WebRTC - https://aka.ms/msrdcwebrtcsvc/msi Multimedia Redirection - https://aka.ms/avdmmr/msi More information on WebRTC and Multimedia Redirection plug-ins Microsoft updates these binaries periodically for functional and security enhancements. To stay current on the latest releases and what they contain, please visit the following links: What’s new for WebRTC Redirector Service What’s new for Multimedia redirection service Conclusion Regularly updating the Multimedia Redirection and WebRTC plugins is essential for a secure and efficient Windows 365 environment. By leveraging the automation scripts from our GitHub repository, IT administrators can ensure plugins remain current, all while eliminating manual effort and minimizing any impact on end users. For more details and to access the scripts, check out our GitHub page.Optimizing RDP Connectivity for Windows 365
Updated with RDP & Zscaler connectivity improvements August 2025 The use of VPN or Secure Web Gateway (SWG) client software or agents to provide tunneled access to on-premises resources in addition to providing protected internet access via a cloud based Secure Web Gateway (SWG) or a legacy VPN & on-premises proxy path is very commonly seen in Windows 365 and AVD deployments. This is especially the case when deployed in the recommended Windows 365 with Microsoft Hosted Network (MHN) model where the Cloud PC is located on a network with direct, open high-speed internet available. The more modern, cloud based SWG solutions fit perfectly with this modern Zero-Trust approach and generally perform at a higher level than traditional VPN software, where internet browsing is hairpinned through on-premises proxies and back out to the internet. As we have many Windows 365 customers using such solutions as part of their deployment, there are some specific configuration guidelines which are outlined in this post which Microsoft recommends are applied to optimize key traffic and provide the highest levels of user experience. What is the Problem? Many of these VPN/SWG solutions build a tunnel in the user context, which means that when a user logs in to their device, the service starts and creates the tunnels required to provide both internet and private access as defined for that user. With a physical device the tunnel is normally up and running before or shortly after the user sees their desktop on screen, meaning they can then quickly get on with their work without noticing its presence. However, as with any virtualized device which needs a remote connection to access, the above model poses several challenges: 1. Additional Latency Firstly, the remote desktop traffic is latency sensitive, in that delay to the traffic reaching its destination can easily translate into a poor user experience, with lag on actions and desktop display. Routing this traffic through a tunnel to an intermediary device to reach its destination adds latency and can restrict throughput regardless of how well configured or performing said device is. Modern SWG solutions tend to perform at a much higher levels than a traditional VPN/Proxy approach, but the highest level of experience is always achieved through a direct connection and avoiding any inspection or intermediary devices. Much like Teams media traffic, the RDP traffic in the Windows 365 case should be routed via the most optimal path between the two endpoints so as to deliver the very highest levels of performance, this is almost always the direct path via the nearest network egress. From a Cloud PC side this also means the traffic never leaves Microsoft’s managed network if directly egressed. 2. RDP Connection Drops An additional challenge comes from the use of user-based tunnels. As the user initiates a connection to the Cloud PC, the connection reaches the session host without issue and the user successfully sees the initial logon screen. However, once the user login starts, and the client software then builds the tunnels to the SWG/VPN for the user, the user then experiences a freeze of the login screen. The connection then drops, and we have to go through the reconnection process to re-establish the connection to the Cloud PC. Once this is complete, the user can successfully use the Cloud PC without further issue. Users however may also experience disconnects of the remote session if there is any issue with the tunnel, for example if the tunnel temporarily drops for some reason. Overall, this doesn’t provide a great user experience with the Cloud PC, especially on initial login. Why does this occur? It occurs because the tunnels built to route internet traffic to the SWG generally capture all internet bound traffic unless configured not to do so, a forced tunnel or ‘Inverse split tunnel’. This means the initial login works without issue but as soon as this tunnel is established upon user logon, the RDP traffic gets transferred into it and as it’s a new path, requires reconnecting. Equally, as the traffic is inside this tunnel, if the tunnel drops momentarily and needs to reconnect, this also causes the RDP session to require reconnecting inside the re-established tunnel. In the diagram below, you can see a simplified representation of this indirect connectivity approach with a forced tunnel in place. RDP traffic has to traverse the VPN/SWG resources before hitting the gateway handling the traffic. Whilst this is not a problem for less sensitive traffic and general web browsing, for latency critical traffic such as Teams and the RDP traffic, it is non-optimal. What’s the Solution? Microsoft strongly recommends implementing a forced tunnel exception for the critical RDP traffic which means that it does not enter the tunnel to the SWG or VPN gateway and is instead directly routed to its destination. This solves both of the above problems by providing a direct path for the RDP traffic and also ensuring it isn’t impacted by changes in the tunnel state. This is the same model as used by specific ‘Optimize’ marked Office 365 traffic such as Teams media traffic. On the Cloud PC side this also means this traffic never leaves Microsoft’s managed network. What exactly do I need to bypass from these tunnels? Previously, solving this problem meant significant complexity due to the large number of IP addresses required to configure optimization for this RDP traffic, we provided a script as part of this blog to assist with collecting and formatting these IPs. I'm pleased to share that Microsoft has invested in an extensive and complex piece of work to solve this challenge by building a new, upgraded global gateway infrastructure to allow it to be addressed from a single subnet. In addition to that simplification that we have planned so that this subnet should not see any regular change, abstracting customers from change as we scale the infrastructure and add new regions in future. As of February 2025, this work has now been completed and the old infrastructure decommissioned, this was all completed with zero downtime for our customers. This now allows RDP based traffic to now be covered by two single subnets rather than many hundred as previously was the case. There are further improvement works due to be delivered in the coming months for UDP based RDP to provide new dedicated and globally scaled TURN infrastructure. This post will be updated when this is complete and RDP connectivity is therefore in its final and complete, simplified and secured state. These temporary elements are: The WindowsVirtualDesktop service tag Is now up to date as of 19th March 2025 with all decommissioned IPs removed. 2. UDP based RDP via TURN now exclusively uses 51.5.0.0/16 as of August 2025. The new, dedicated subnet is in the WindowsVirtualDesktop service tag. More on this can be found in this post. This work will also vastly expand our global TURN relay availability. RDP based Connectivity bypass: As of August 2025, the critical traffic which carries RDP is contained within the following simplified endpoints: RDP Endpoints for Optimization Row Endpoint Protocol Port Purpose 1 *.wvd.microsoft.com TCP 443 Core TCP based RDP and other critical service traffic 2 40.64.144.0/20 TCP 443 Core TCP based RDP 3 51.5.0.0/16 UDP 3478 Core UDP based RDP via TURN Please see this article for more information on row 3 In some network equipment/software we can configure bypass using FQDNs and wildcard FQDNs alone, and we’d recommend that this method (row 1) is used in addition to the IP based rules if possible. However, some solutions do not allow the use of wildcard FQDNs so it’s common to see only IP addresses used for this bypass configuration. In this case you can use the newly simplified rows 2 & 3 in the table above, making sure row 1 is still accessible via the SWG/Proxy. There are also a small number of other endpoints which should be bypassed on the Cloud PC side: Other required VPN/SWG bypass requirements: Other endpoints for Optimization Row Endpoint Protocol Port Purpose 4 azkms.core.windows.net TCP 1688 Azure KMS - Traffic Needs to arrive from Azure public IPs 5 169.254.169.254 TCP 80 Azure Fabric communication 6 168.63.129.16 TCP 80 Azure Fabric communication These additional bypass requirements (4-6) are not RDP related but are required for the following reasons: Row 4 – This is Azure KMS activation which is a required endpoint for a Cloud PC and AVD Session Hosts. The traffic for this needs to arrive from an Azure public IP, if not then the connection will not be successful. Therefore it should not be sent via a 3 rd party internet egress such as via an SWG or proxy. IP addresses corresponding to the FQDN can be found via the link above if required. Rows 5 & 6 – These are critical IP addresses used to communicate to the Azure Fabric to operate the VM. We need to ensure these are not inadvertently sent in any VPN/SWG tunnel where they will not be then able to reach their destination in Azure. How do I implement the RDP bypass in common VPN/SWG solutions? Microsoft is working with several partners in this space to provide bespoke guidance and we’ll add detailed guidance for other solutions here as we get them confirmed. Already available however is Zscaler ZIA. Zscaler Client Connector The changes outlined above should make configuration in all scenarios vastly simpler moving forward. Due to some fantastic work to assist our mutual customers by our friends at Zscaler, as of February 2025 and version 4.3.2 of the Zscaler Client Connector, the majority of the mentioned Windows 365 and AVD traffic which requires optimization, including RDP can be bypassed with a single click configuration within a predefined IP based bypass! Zscaler ZIA Configuration Version 4.3.2 (Released Feb 2025) of the Zscaler Connector Client portal enables this feature. Ensure a recent version of the Client Connector is installed on both the Cloud PC (And Physical device if Zscaler is used there) to take advantage. In the Zscaler Client Connector Portal, select the new IP-Based, Predefined Application Bypass for Windows 365 & Azure Virtual Desktop. This contains preconfigured bypass for RDP and KMS traffic. 3. Add the following endpoints to the bypass configuration manually as they are not included in the automatic bypass. Endpoint Protocol Port Purpose 169.254.169.254 TCP 80 Azure Fabric communication 168.63.129.16 TCP 80 Azure Fabric communication Other VPN/SWG solutions Microsoft is currently working with other partners in this space to provide detailed guidance for other VPN/SWG solutions and will list them here as they are complete. Please let us know in the comments if you’d like us to list a particular solution and we’ll aim to prioritize based on feedback. In the interim, use rows 1-6 in the tables above to create manual bypasses from VPN/SWG/Proxy tunnels. This should be significantly simpler and have much lower change rates than previously due to the IP consolidation. FAQs: Q: In a Microsoft Hosted Network deployment, is there anything else I need to do? A: Unless the local Windows firewall is configured to block access to the endpoints noted, there should be nothing else required, the network the virtual NIC sits in has direct, high speed connectivity Microsoft’s backbone and the internet. Q: In an Azure Network Connection scenario, is there anything further I need to do? A: In this scenario, the recommended path for the traffic is directly out of the VNet into Microsoft’s backbone. Depending on the configuration it may require allowing the endpoints noted in this article through a firewall or NSG. The WindowsVirtualDesktop service tag or FQDN tag may help with automating rules in firewalls or configuring User Defined Routing. RDP traffic specifically should be sent direct into Microsoft’s backbone via a NAT Gateway or similar with no TLS inspection, avoiding putting load on NVAs such as Firewalls. Q: Do I need to configure the bypass on just the Cloud PC? A: RDP connectivity (Rows 1-3) is used identically on both the physical and cloud sides. It is strongly advised that the bypass is applied to both the Cloud PC and the connecting client if that also uses the SWG/VPN to connect. If both are using the same configuration profile then this should happen automatically. Rows 4-6 are only required on the cloud side. Q: How often do the IP addresses Change? A: Now the improvement work is complete we don’t anticipate regular change. You can monitor the WindowsVirtualDesktop service tag for changes if desired and we’re working on getting these requirements into the M365 Web Service longer term for monitoring and automation. Q: Can I add more than the RDP traffic to the bypass. A: Microsoft only provides IP addresses for the RDP connectivity at present. However if your solution is capable of configuration by FQDN alone, then you can add other service endpoints to your optimized path, these can be found on this Microsoft docs page. Q: Im using a true split tunnel, does this impact me? A: The above advice is for a forced tunnel scenario (inverse split tunnel) where the default path is via the tunnel and only defined exceptions are sent direct, which is often referred to as a split tunnel in common parlance and is the most commonly seen deployment model of such solutions. However a split tunnel in the technically accurate sense of the words, where the default path is the internet and only defined endpoints (such as corp server ranges/names) are sent down the tunnel, shouldn’t need such configuration as the RDP traffic should follow the default path to the internet. Q: Does this also optimize RDP shortpath? A: RDP Shortpath for Public Networks works to provide a UDP based RDP connection between the client and Cloud PC if enabled and achievable. This connection is in addition to the TCP based connection described above and the dynamic virtual channels such as graphics, input etc are switched into the UDP connection if deemed optimal. Row 3 above covers this traffic for connectivity via TURN relays. Please see this article for more information on this connectivity model. Q: Is this advice also shared in Microsoft’s official documentation? A: We’re currently working on uplifting the entire connectivity documentation for Windows 365 and the above will form part of this work in the coming months. We’ll share the official link in this blog when available. Q: Does this advice apply equally to AVD? A: Yes, both Windows 365 and AVD have exactly the same requirements in terms of the connectivity discussed in this blog.
