Pinned Posts
Forum Widgets
Latest Discussions
Microphone & camera passthrough to Cloud PC from MacBook
I have a M1 MacBook Pro that I use to connect to my Cloud PC for work via the Microsoft App. I try to use the Teams app installed locally on the Cloud PC for making and accepting calls but I am having a lot of audio issues. First of all, the person I am calling sounds very tinny (kinda like a chipmunk!) and they cannot hear me. Video doesn't seem to work properly either. I have had very little luck with my external webcam (some Logitech one, don't actually know the model but I don't think it makes a difference? but it has a microphone). There has the very odd few times that a call is working fine but then after a few seconds or so, or when I start sharing my screen on the Cloud PC after a minute of the call starting, I start to experience the same issues with audio as explained above. I am running Sequoia 15.6, the Mac Windows App is version 11.1.5 (2585). Admittedly I've mostly tried in clamshell mode and connected to external earphones (AirPods Pro). I used to use my earphones via the Citrix app on VDI with no issues previously. Any solutions would be gratefully received. Thank youOptimizing 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.
Enable FIDO Token (RSA DS100) passthrough to W365 Machine via Windows App
Hi There, Working with Enterprise license, trying to establish the approach to allow FIDO Token, specifically the RSA DS100, to redirect from the Host device. The users can only connect via the Windows application, not via the RDP client. I have the Device Class/Driver ID of the token. It is key that removable storage is not enabled as a result of this, for obvious reasons. Ideally the allowance would be scoped to only include the token. Thanks in advance.365 stuck at "Setting Up" after license reassignment, is there a way to force reprovisioning?
I am fairly new to managing Windows 365, and I've run into an issue that seems like it should have a simple fix, but hasn't been so straightforward in practice. I have a 365 Business cloud PC under one user (admin). After testing a few things, I removed the license from that user and reassigned it to a new employee. The portal now shows " Setting up Cloud Pc" for that user, and it's been stuck there for several hours with no sign of progress. I have tried : Unassigned and reassigned the license again. Restarted the cloud PC from the portal ( though it's not active). is there a way to manually trigger or force reprovisioning of the Cloud PC after a license reassignment ?Getting Started with Windows 365 Benefits, Use Cases, and Setup Guide
In today’s hybrid work environment, flexibility, security, and scalability are more critical than ever. Windows 365, Microsoft’s Cloud PC solution, addresses these demands by bringing the Windows experience to the cloud — enabling users to securely access their personalized desktop from any device, anywhere. Whether you’re an enterprise IT architect, an SMB owner, or an individual professional, Windows 365 has a lot to offer. Let’s dive into the key benefits, common use cases, and how you can get started with Windows 365. https://dellenny.com/getting-started-with-windows-365-benefits-use-cases-and-setup-guide/
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.Expanded TURN relay regions for Windows 365 and Azure Virtual Desktop
Starting June 15, 2025, we are launching a dedicated TURN relay IP range across the Microsoft Azure public cloud. 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 40 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. As part of this transition, connections will gradually move away from the existing ACS TURN Relay range (20.202.0.0/16). This change will occur behind the scenes, but, to ensure uninterrupted service, you will need to proactively bypass the new TURN relay range (51.5.0.0/16). 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 40 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 40 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 Below 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 client is far from a supported region, the connection may fall back to TCP, potentially impacting performance. Australia East Japan East Spain Central Australia Southeast Japan West Sweden Central Brazil South Korea Central Switzerland North Canada Central Korea South Taiwan North Canada East Mexico Central UAE Central Central India North Central US UAE North Central US North Europe UK South East US Norway East UK West East US 2 Poland Central West Central US East US2 EUAP South Africa North West Europe France Central South Africa West West US Germany West Central South Central US West US 2 Israel Central South India West US 3 Italy North Southeast Asia How to prepare for this change This new IP subnet will form a critical part of the resilient and performant connectivity provided for Windows 365 and Azure Virtual Desktop. As part of the ongoing transition, traffic will be progressively redirected from the current Azure Communication Service (ACS) TURN relay range (20.202.0.0/16) to a newly designated subnet (51.5.0.0/16). While this shift is designed to be seamless, it’s essential that you preemptively configure bypass rules for the new range to maintain uninterrupted service. With both IP ranges properly bypassed, end users will not experience any connectivity issues. You therefore need to ensure that traffic is both accessible and optimized. 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.Unable to assign license to employee
Hi, I'm new to Windows 365 and just bought it today. Login by main account and installed a couple of software in the Cloud PC without any issues. However, when I go to admin and reassign the license to employee's account. It's been stuck at setting up for hours. Any way to fix this issue? I tried to log back in with admin's account, restart, reset. Yet, unable to get pass the setting up screen when re-assign it to employee's account. Thanks
Saving Cloud PC data for a time and then restoring
Hi, I'm in a position where we have a cloud PC user who is currently on maternity leave. Whilst she is away we have a new starter covering her position. I'm wondering if there's a way to save the data that's on the mat leave user's CPC so we can free up the license for the new starter? Then be able to restore the saved data when the first user is back from mat leave. I couldn't see anything about this online but thought it might be worth a shot asking on here. If not, would it potentially be buying another license and spinning up a new CPC? Thanks in advance! Joel
