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.
Application Deployment in Windows 365 – Recommended Practices
(This post was jointly written with Aleksandar Bozadzhiev) Overview As more companies are using Windows 365 to enable their employees, reduce their costs, or reimagine how to provide a managed Windows experience, we’re hearing some consistent feedback. A common challenge we hear is “How can I ensure that all my required applications are installed before my users can access their Cloud PCs?” Common statements we’ve heard include: “I need to ensure all security tools are installed before users can logon to reduce risk.” “I need to ensure my people are immediately productive when they 1 st logon.” This article will provide some recommended approaches to help you meet this need; providing both technical and process recommendations. Technical Recommendations Use Intune to assign applications to devices rather than users. By targeting devices you can better ensure your applications get installed as soon as possible. When a Cloud PC is provisioned, it immediately is enrolled with Intune. After enrollment, the Cloud PC will sync with Intune to determine what applications, policies and profiles are required for the device. Assigning to user groups will result in the Intune sync occurring after the user 1 st logs, potentially delaying the installation of required apps for several minutes after logon. Additionally, using Configuration Manager or a third-party solution to install applications will result in additional delays, as Intune will need to install the 3 rd party agent/client, which will then do its own scan/sync to determine what needs to install on the Cloud PC. Of course, there may be exceptions where applications are more appropriate to be targeted to users rather than devices; such as software that has specific license requirements, or applications require a user to be logged on to perform the installation. Use “All Devices” group and device filters (rather than dynamic groups) Our Windows 365 documentation provides details on how to use both dynamic groups and device filters for targeting applications. The challenge with using Azure AD dynamic groups is that a newly provisioned Cloud PC may not be in a dynamic group for some time, potentially for several minutes up to several hours. This is due to the nature of how dynamic groups are processed and synced to Intune. When a Cloud PC is provisioned and enrolled into Intune, the following actions occur: A device object in both Azure AD and Intune are created. Azure AD Dynamic group membership is periodically calculated for new members. Dynamic group membership is synced with Intune. The Cloud PC checks-in with Intune to determine what applications, policies, and profiles are applicable. The above actions occur sequentially and run on a periodic schedule which results in a potentially significant delay in installing applications. Using the “All devices” Intune virtual group and device filters when assigning applications will result in your applications being installed as fast as possible. Why? Device filters are evaluated by Intune immediately upon enrollment and the All Devices Intune group does not require any synchronization activity. Device filters that can be used with Cloud PCs include: All Cloud PCs All Cloud PCs within a specific provisioning policy All Cloud PCs with a specific configuration Also, note that if you’d like to use an Enrollment Status Page (ESP), a device filter that represents a specific provisioning policy is the only filter that is supported with an ESP. More details in the section below. The above links describe how to create a device filter. The below images shows an example of creating a device filter, and then using a device filter when assigning applications. Check out the Common Questions and Answers in our Intune documentation for more details on the challenge of using dynamic groups to deploy applications at enrollment. Also, note our performance recommendations in our Intune documentation when using groups for application targeting. Recommendation: To reiterate, using the “All Devices” group AND a device filter that represents some or all Cloud PCs will provide the best possible performance, installing your applications as fast as possible post provisioning. Using a device filter that represents a specific provisioning policy or a specific configuration will provide granular targeting. What about using an Enrollment Status Page (ESP)? An ESP is commonly used to display the provisioning status when enrolling with Intune. It’s a detailed progress indicator. An ESP is designed to be displayed while the user is waiting for their device to be ready. When using Windows Autopilot to provision new physical Windows devices, the ESP runs in two phases: the device ESP and the user ESP. The device ESP runs only during the default out-of-box experience (OOBE). When provisioning Cloud PCs the device ESP is not used – as there’s no OOBE phase - only the user ESP. Since a Cloud PC is provisioned without a user present, an ESP may add complexity to the overall provisioning process. Further, while there is a setting “Block device use until all apps and profiles are installed” this is only used during the user ESP phase, and this setting is not used during Cloud PC provisioning when targeting apps to devices. Thus, if you’re targeting applications to device groups, we recommend not to use an ESP for Cloud PCs. If you’d like to use an ESP for user targeted applications and policies, make sure to follow the guidance here. Specifically, note that a custom ESP is only supported when you use a device filter that targets a specific provisioning policy. Using dynamic device groups with an ESP is not supported. Process Recommendations - Planning for onboarding users to Cloud PCs Without using the “Block device use until all apps and profiles are installed” setting, how can we ensure all the apps are installed prior to the 1 st logon? This is when it’s important to consider the onboarding process. Meaning, when testing/evaluating Windows 365, you might assign a license to yourself or your coworker, ensure you’re in a group that is assigned a provisioning policy, and then check the Intune admin console to see when you’re Cloud PC status changes from “provisioning” to “provisioned.” If you then immediately connect to your Cloud PC, you may find that not all of your applications installed, and then think “Well I can’t give this to my users until I know all my apps will be there!” Surprisingly, this statement holds the key to managing this challenge. Think about how you’re going to provide Cloud PCs to users. How many will you provision at a time? One? One hundred? One thousand? What’s your communication plan? How will users know when (and how) to use their Cloud PCs? What we find is that it is uncommon for users to login to their Cloud PCs shortly after they’re provisioned. Below is a chart that shows some of our internal telemetry from the last 28 days (based on time of this writing). Some takeaways from this data: Less than 30% of users sign-in to a Cloud PC less than 1 hour after it’s been provisioned. Over 50% of users sign-in to their Cloud PC 4 hours or more after it’s been provisioned. Additionally, we found that the average time until 1 st login is just over 32.4 hours and the median is 4.2 hours as there is a lot of variation in the results. What we can infer from the above is that most companies have users that do not sign-in immediately after provisioning and wait several hours before doing so. Sometimes this is done unintentionally, while sometimes this is planned during a deployment project. For example, a deployment plan may look like the following: Day 1 - Provision 50/500/5000* Cloud PCs Day 2 – Review the results Day 3 – Send out end user communications * Earlier this year, we worked with a company who followed this model and successfully provisioned over 10,000 Cloud PCs in less than 24 hours. The above deployment plan can definitely be compressed to build in a 2-3 hour buffer (for example) to ensure all apps are installed. Consider how a user will know to log on to their Cloud PC for the 1 st time. As an IT admin, you can control when to notify people that their Cloud PC is ready. During your notifications, you can optionally provide a link to download the Windows 365 app through the Microsoft Store, or a link to the Intune Company Portal to install the app. Lastly, make sure to test your application installation prior to onboarding your Cloud PC users in a production environment. While this may sound obvious, such testing helps eliminate potential onboarding challenges. What can be done to verify application installation? The Intune Admin portal can be used to review the results and ensure that all device targeted apps are installed. Administrators can select a Cloud PC and view the “Managed Apps” list that are targeted to the device. Using the Intune admin portal is a great way to review the results of a few Cloud PCs. Additionally, the Graph API can be used to help you automate this process. Check out our documentation that explicitly mentions how to get the application installation status on a user’s device. The Microsoft Hosted Network (MHN) can help If you’re concerned about having a Cloud PC connected to your network without immediately having your required security applications, consider using the Microsoft Hosted Network when planning your network deployment of the Windows 365 service. Using the MHN is the simplest option and aligns with the Zero Trust framework model and is the Microsoft recommended deployment model for Azure AD joined Cloud PCs. Additionally, a Cloud PC is not connected to your network until a VPN connection is explicitly established, further reducing risk. Summary When it comes to the Windows 365 provisioning process, the process used by IT admins to perform testing and evaluation can be vastly different than the process to deliver Cloud PCs to end users. In most environments, people 1 st sign-in to Cloud PCs several hours after they are provisioned. Acknowledging this human behavior and building a waiting period buffer is a means to ensure all your applications are installed and provide IT admins a way to verify prior to providing the Cloud PC to end users. The technical guidance above will also help you provide the best provisioning and onboarding experience to your users.
Windows 365 Cloud PC Self-Service Automated Request Process
How to automate Windows 365 Cloud PC self-service requests (Windows 365, Azure Active Directory, Microsoft Forms, Power Automate, MS Graph) Contributors: Juan José Guirola Sr. (Next Generation Endpoint GBB for Americas) Bobby Chang (Power Platform GBB for Americas) Azim Manjee (Cloud Endpoint Technical Specialist) Windows 365 simplifies how organizations offer Cloud PCs to their employees. As a cloud-based service from Microsoft, Windows 365 provides a personal, secure streamed experience from any supported device. It comes with all the productivity, security, and collaboration benefits of Microsoft 365. Windows 365 removes the need to manage a complex infrastructure and it integrates with existing cloud-based networking investments such as Azure Active Directory, Microsoft Endpoint Manager, and more. As the workplace continues to shift toward hybrid work, Windows 365 gives more organizations the ability to issue a cloud-native, persistent Cloud PC that is available 24 hours a day, 7 days a week, all with the ease of assigning a license. This simplified approach to provisioning Cloud PCs opens up the potential for automation and self-service scenarios. With Windows 365, you can provide your employees with Cloud PCs on demand, and here, we’ll show you how. Prerequisites The following items are required to provide automated, self-service Cloud PC request of Windows 365 deployment in a production environment: (For personal development and sandbox/testing scenario, you can use the Microsoft 365 Developer Plan and Power Apps Developer Plan). Windows 365 Enterprise Licenses Windows 10 Enterprise or Windows 11 Enterprise Azure Active Directory (Azure AD) Premium (P1/P2) Azure AD native group (must NOT be a synced group) Microsoft Intune (previously known as Microsoft Endpoint Manager) Microsoft Forms Power Automate per flow plan Microsoft Graph (Windows 365 Cloud PC MS Graph API in beta) Working with Windows 365 Cloud PCs using the Microsoft Graph API Azure App Registration with the following permissions: CloudPC.Read.All. For enterprise production scenarios, we would recommend leveraging the Application Lifecycle Management (ALM) capabilities in Power Platform, in order to safely adopt future changes to your processes. However, this is outside of the scope of this blog post. Before you begin Before you set up automation and a self-service Cloud PC request process, identify and assign the target Azure AD group(s) for the Windows 365 Cloud PC license assignment and provisioning policy. In our scenario, we have three Azure AD Groups (one Azure AD group for each of our three business segments), for both license and provisioning policy assignments. To configure group license assignments, see Assign licenses to users by group membership in Azure Active Directory. For information about how to target the groups for provisioning policies, see Create Windows 365 Cloud PC provisioning policies. Once you have the group assignment, set up the self-service process starting with Microsoft Forms. Create the request intake form Establishing an intake process will not only allow your employees to request the Windows 365 Cloud PC on-demand, but also allow you to build in an approval process and a feedback loop once the license is provisioned and ready for access. For our scenario, we are using Microsoft Forms as the intake form for requesting a Cloud PC. If your organization needs additional requirements around data validations and user experience in the form, we recommend leveraging Power Apps instead. To create a form with Microsoft Forms, see the Microsoft Forms help and learning home page or Create a form with Microsoft Forms. The following are the key components of our example form: Purpose-specific title “Windows 365 Cloud PC Request Form” Four questions to identify the requesting employee’s business segment, the type of Cloud PC they require, their region, and their contact number (aka mobile number) Shared to people in the organization only, for security, tracking, and notification purposes Alt text: Example Windows 365 Cloud PC Request Form in Microsoft Forms. Register MS Graph in Azure AD Once the request form is complete, register MS Graph as an Enterprise application in Azure Active Directory. Log into the Azure portal with appropriate permissions for making application registrations. Global Administrator privileges will provide the permissions to make application registrations; there are other options by following the custom role details in this documentation Custom role permissions for app registration - Azure AD - Microsoft Entra | Microsoft Docs. In the Azure services portal, click Azure Active Directory > Azure Active Directory. Alt text: A screenshot of the Azure Active Directory blade in the Azure services portal. Select App registrations in the left navigation menu. Click New registration. Give the application a name, select Single Tenant for the supported account type, and then click Register. Alt text: A screenshot of the Register an application screen, showing the details that need to be identified for the new application. Note. Alt text: A screenshot of the recently created application overview with the Application (client) ID and Directory (tenant) ID details highlighted. Click API permissions in the left navigation menu. . Select Microsoft.Graph and choose Application permissions. Ensure the following permissions are added: CloudPC.Read.All User.Read User.Read.All Group.Read.All Mail.Send (optional for sending messages via Graph ) Alt text: A screenshot of the Select permissions setup. Once the permissions have been added, click Grant consent. Click Certificates & secrets in the left navigation menu, and then click New client secret. Important! Note this key and store it somewhere safe, like a key vault. This key will only be visible upon creation. Once you navigate away, you will be unable to expose the key again and will have to generate a new key. Create the Cloud PC provisioning process automation In this section, we will build the Power Automate flows that will orchestrate the self-service process. This decision flow illustrates the end-to-end process of adding the requestor to proper AD security group, prompting an approval process, and then notifying requestor of their Cloud PC readiness. Alt text: A flowchart depicting the process for the automated provisioning process. To begin, sign into Microsoft Power Automate with your Microsoft 365 organization credentials. From the left navigation menu, click + Create then: Click Automated cloud flow. Name the flow and choose the flow trigger, “When a new response is submitted” (Microsoft Forms) from list. Click Create. Alt text: A screenshot that shows the flow name and trigger selection options. In When a new response is submitted, select your form from the Form Id drop down, then: Click + New step. Search for “forms” in Choose an operation and select Get response details (Microsoft Forms) from Actions. For Get response details, select your form from the Form Id drop down and then select Response Id as Dynamic content. Alt text: A screenshot of the criteria for the Get response details step. Click on + New step (To add variable for the Object ID of the targeted group in Azure AD). In Choose an operation, type variable. Select Initialize variable from Actions. Type VARGroup ID details screen. Give it a name, e.g., VARGroupID and select “String” as Type. Click + New step (To add variable for the “id” attribute value of the Cloud PC). Choose an operation, type variable. Select Initialize variable from Actions. Give it a name, e.g. VARCloudPCID and select “String” as Type. Click on + New step (To add variable for the “status” provisioning value of the Cloud PC). Search for VAR in Choose an operation. Select Initialize variable. Give it a name (e.g. VARProvisioningStatus) and select “String” as Type. Click on + New step (To add variable for your tenant ID). Choose an operation, type variable. Select Initialize variable from Actions. Give it a name (e.g., VARTenantGUID) and select “String” as Type. Tenant ID/Tenant GUID is required for authentication against the CloudPC Microsoft.Graph API. For information on getting your tenent ID, see How to find your Azure Active Directory tenent ID.For information on getting your tenent ID, see How to find your Azure Active Directory tenant ID. In the Value field, enter your Tenant ID. Click on + New step (To add variable for your Choose an operation, type variable. Select Initialize variable from Actions. Give it a name (e.g., VARAppID) and select “String” as Type. (This AppID represents the App Registration Client GUID, which is required for authentication against the CloudPC Microsoft.Graph API). In the Value field, enter your App Registration Client ID. Click on + New step (To add variable for the “Secret,” which is your . Choose an operation, type variable. Select Initialize variable from Actions. Give it a name (e.g., VARSecretID) and select “String” as Type. This is required for authentication against the CloudPC Microsoft.Graph API. Refer to Step 6 in the “Register MS Graph in Azure AD” section of this document. For additional protection, use Azure KeyVault to store and retrieve this client secret. Refer to Defining inputs and outputs for this variable action to obfuscate the secret during run time and from the logs. In the Value field, enter your Client Secret. At this point, we need to determine the automated actions, based on the “Business Segment” value provided by requestor. This can be accomplished by applying a Switch action. : Click on + New step. Search for “Switch” in Choose an operation and select Switch (Control). Next to On, select What Business Segment are you part of? from Dynamics content. Add as many “Cases” as needed to meet your specific needs. In our example, we have 3 Cases, which represent the 3 business segments: South Enterprise, LATAM, and Microsoft Federal. Within each Case, click Add an action Search for “variable” and select Set variable. Select VARGroupID from the Name drop down. Insert the Object ID of the desired targeted group for each “Case.” Note: The Object ID can be retrieved by viewing the group properties in Azure AD. Alt text: A screenshot of options for setting the Case variables. Click on + New step (This step will initiate the approval process) Search for “approval” in Choose an operation and select Start and wait for an approval. Select Approve/Reject – Everyone must approve from the Approval type drop down. Enter the email addresses for approvers in the Assigned to field. Fill in the remaining fields as desired. In our example, we elected to use values gathered from the requestor. Alt text: A screenshot of the available settings for the approval process in Start and wait for an approval. Click on + New step. This step will set up the execution process determined by approval outcome. Search for “Condition” in Choose an operation and select Condition control. Select Outcome under Dynamic content as the value. Choose is equal to and type “Approve” for the value. You will be presented with two sub processes, If yes and If no. Add necessary flows for each. Alt text: A screenshot of the If yes and If no sub-process flow setup options. For the If yes process: Click Add an action. Search for “Azure AD” in Choose an operation and select Get User. Select Responders’ Email for the User Id or Principal Name value. Click Add an action. Search for “Azure AD” in Choose an operation and select Add user to group. Select VARGroupID for Group Id and Id for User Id. Click Add an action. Search for “Send email” in Choose an operation and select Send an email (V2) Office 365 Outlook. Select VARGroupID for Group Id and Id for User Id. Rename to “Send an approved email.” Fill in all fields, as desired. Alt text: A screenshot of the Send an approval email setup. [Optional] If you want to added notification, click Add an action. You can add notification to your flow. In our example we are using Twilio, but you can choose to use other services. Follow your SMS provider’s instructions to properly configure in Power Automate Flow. Click Add an action. To pause the flow and allow the provisioning process to kick off in the backend, select Delay and configure the desired time. In our example, we’ve elected to delay the flow for 1 minute. Search for Delay in Choose an operation. Click Add an action. Important! To add the control to perform Graph API calls against tenant to monitor requestors Cloud PC provisioning status, search. In the Method field, select GET. Under URI, set it up exactly as illustrated below, placing the UserPrincipalName dynamic content inside the string: https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs?$filter=userPrincipalName eq '@{outputs('Get_user')?['body/userPrincipalName']}' and status eq 'Provisioning'&$count=true For Authentication, select Active Directory OAuth. Leave the authority as default. Enter your TenantID variable under Tenant, https://graph.microsoft.com under Audience, the AppID under Client ID, and the Secret in the Secret section. Alt text: Example setup for Graph API controls to monitor requestor Cloud PC provisioning status. Click Add an action, and search for “Parse JSON.” Under (note in the UI you will also see Parse User CPCs), select Body for the Content field and insert the body of the HTTP request response into the Schema field. Use the following schema: Alt text: A screenshot of completed content and schema details for Parse JSON. { "type": "object", "properties": { "@@odata.context": { "type": "string" }, "@@odata.count": { "type": "integer" }, "value": { "type": "array", "items": { "type": "object", "properties": { "id": { "type": "string" }, "displayName": { "type": "string" }, "imageDisplayName": {}, "provisioningPolicyId": { "type": "string" }, "provisioningPolicyName": { "type": "string" }, "onPremisesConnectionName": { "type": "string" }, "servicePlanId": { "type": "string" }, "servicePlanName": { "type": "string" }, "status": { "type": "string" }, "userPrincipalName": { "type": "string" }, "lastModifiedDateTime": { "type": "string" }, "managedDeviceId": {}, "managedDeviceName": {}, "aadDeviceId": {}, "gracePeriodEndDateTime": {}, "servicePlanType": { "type": "string" }, "statusDetails": {} }, "required": [ "id", "displayName", "imageDisplayName", "provisioningPolicyId", "provisioningPolicyName", "onPremisesConnectionName", "servicePlanId", "servicePlanName", "status", "userPrincipalName", "lastModifiedDateTime", "managedDeviceId", "managedDeviceName", "aadDeviceId", "gracePeriodEndDateTime", "servicePlanType", "statusDetails" ] } } } } Note: You can also get this schema by using the Graph explorer to request from the same endpoint. Use the Generate from example button to generate the schema: Click Add action and search for “Apply to each.” In the Output field, select Value from our Parse JSON step. A Do until step should appear., If it doesn’t, click Add an action and search for “Do until.” Alt text: A screenshot of the Do until setup. In the Do until step, select the ProvisioningStatus variable is equal to string(‘provisioned’). Click and search for “Set Variable.” Configure the CPC-ID Variable to the ID of the item from the Parse JSON. Click Add an action and search for “HTTP.” Configure the HTTP using the same variables for TenantID, APpID, and Secret, as in the previous HTTP action, but using the following URI: https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs/@{variables('CPC-ID')} Example: Alt text: Example setup for monitoring Cloud PC. Click Add an action, search for “Parse JSON.” Select Body for the Content field and insert the following into the Schema field: { "type": "object", "properties": { "@@odata.context": { "type": "string" }, "id": { "type": "string" }, "displayName": { "type": "string" }, "imageDisplayName": { "type": "string" }, "provisioningPolicyId": { "type": "string" }, "provisioningPolicyName": { "type": "string" }, "onPremisesConnectionName": { "type": "string" }, "servicePlanId": { "type": "string" }, "servicePlanName": { "type": "string" }, "status": { "type": "string" }, "userPrincipalName": { "type": "string" }, "lastModifiedDateTime": { "type": "string" }, "managedDeviceId": { "type": "string" }, "managedDeviceName": { "type": "string" }, "aadDeviceId": { "type": "string" }, "gracePeriodEndDateTime": {}, "servicePlanType": { "type": "string" }, "statusDetails": {} } } Alt text: A screenshot of the Parse JSON schema. Click Add an action and search for “Set Variable.” Select ProvisioningStatus for the Name and configure the provisioning status variable to the status of the item from the Parse JSON. Click Add an action and search for “Delay.” Set a delay in an appropriate increment to recheck the status based on your typical Cloud PC provisioning time (e.g., 30 minutes is a normal time increment). In our example, we selected an increment of every 15 seconds. Consider throttling concerns to not overwhelm the API and cause timeouts. Once you’re past the Do Until scope, Click Add an action and search for “Send an Email.” Create your “successful” provisioning email. In our example, we use several variables and dynamic content to ensure clarity. You can also embed links to the different clients available to the employee for accessing their Cloud PC. Alt text: An example of a “successful” provisioning email setup. Click Add an action and search for “Send Text Message.” Create your “successful” provisioning SMS. In our example, we use several variables and dynamic content for clarity. Alt text: An example “successful” provisioning SMS message setup. Once you’re past the Apply to Each scope, Click Add an action, and search for “Terminate.” Set the Status to Successful. Return to the Approval Conditon to setup the rejection or If no process. Scroll up in the workflow to access this setup. Click Add an action and search for “Send Email.” Create and carefully word the rejection email. Alt text: An example of a rejection email setup. Click Add an action and search for Terminate. Set the Status as Cancelled. The entire Power Automate flow should look like the image below. Alt text: A Power Automatic flow diagram depicting the process described in this document. Once you’ve completed adding in steps to your automation flow, you’re ready to test the solution. Select Test and execute the steps described in the User experience section of this document. User experience Once the self-service experience is configured, the employee or requestor should be able to generate a request. The following is an example of what the user can expect during their request experience. The requestor completes the Self-service user request form. Alt text: An example of a completed self-service request form filled in by an employee. The flow kicks off based on information entered in the form by the requestor. The approval process begins. Alt text: An illustration of the approval process flow. The Approver gets an email and Microsoft Teams notification to approve, reject, or reassign the request. Alt text: An example of an approval request. Once approved or rejected, the flow continues to add the user to the proper Azure AD Group, which in turn will assign the proper Windows 365 license and the correct provisioning policy. Alt text: An illustration of the If yes and If no process flows. If the request is approved, the approval email and SMS text will be sent to the requestor informing them that the request was approved. If the request is rejected, the rejection email will be sent. Alt text: An example of an approval email. Alt text: An example of an approval text message. Power Automate will monitor the provisioning status as it changes from “provisioning” to “provisioned.” Once the Cloud PC status changes to “provisioned,” the requestor will receive an email and SMS text message informing them that their Cloud PC has been provisioned and is ready to access. Alt text: An example email message informing the requestor that their Cloud PC has been provisioned. Alt text: An example text message informing the requestor that their Cloud PC has been provisioned. Continue the conversation by joining us in the Microsoft 365 Tech Community! Whether you have product questions or just want to stay informed with updates on new releases, tools, and blogs, Microsoft 365 Tech Community is your go-to resource to stay connected.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.Unlocking the Power of Windows 365 in 2025: Your Ultimate Learning Guide
Fun fact, the article below is written by Microsoft Copilot! Before kicking off, I want to wish all of you Happy (and successful) New Year! As we move further into 2025, the digital workspace continues to evolve, and Windows 365 remains at the forefront, offering seamless and flexible cloud computing solutions. Last year, we have been recognized for the second consecutive year as a Leader in the 2024 Gartner® Magic Quadrant™ for Desktop as a Service (DaaS). Whether you're a seasoned professional or new to the world of cloud PCs, there's always more to learn about making the most out of Windows 365. To kick this year off with a tradition, here’s your comprehensive new guide to mastering Windows 365 in the year 2025! Getting started with Windows 365 Microsoft provides a wealth of resources to help users understand and maximize Windows 365. Start by exploring the official Windows 365 website for detailed documentation, tutorials, and updates. Additionally, the Microsoft Learn platform offers structured learning paths and modules specifically tailored to Windows 365. Windows 365 migration: It's easier than you think - Windows IT Pro Blog Windows 365 Cloud PCs and Microsoft Intune for VDI administrators | Windows IT Pro Blog New end-user experiences for Windows in the cloud: December 2024 | Microsoft Community Hub Technical deep dive bootcamp on Microsoft AVD and Windows 365 The future of Windows, Windows 365 and AI | Microsoft 365 Community Conference Create provisioning policies for Windows 365 Windows 365 deployment overview Windows 365 networking deployment options Windows in the Cloud video series Windows in the Cloud video series dives into Windows 365 capabilities: Windows 365 and Azure Virtual Desktop news from Microsoft Ignite - Windows in the Cloud What’s next in Windows 365 Frontline - Windows in the Cloud Introducing Windows 365 Link – the first Cloud PC device Microsoft Teams in the Windows cloud Windows App: what's new and what's next | Windows in the Cloud GPU-enhanced Windows 365 Cloud PCs - Windows in the Cloud Leadership spotlights Leadership spotlight: Melissa Grant, Windows Marketing Leadership spotlight: Marcus Ash on the future of Windows and AI design Customer spotlights Episode 1 - Windows 365 Customer Spotlights with Sepideh AMAs (Ask Microsoft Anything) Looking for more tips to deploy and manage Windows 365 and Azure Virtual Desktop faster, better, and simple? Catch up on the most recent sessions on-demand: AMA: The latest in Windows 365 and Windows in the cloud(December 2024) AMA: Windows 365 - Q3 2024 capabilities(October 2024) AMA: Windows 365 GPU-enabled Cloud PCs(September 2024) AMA: Windows App(August 2024) Upcoming dates: January 29, 2025 - AMA: Windows 365 February 26, 2025 - AMA: Windows 365 March 26, 2025 - AMA: Windows 365 Microsoft Ignite ’24 content available on demand In case you missed any of the breakout sessions that the Windows cloud engineering team delivered to Microsoft Ignite, they are now available on demand. Here are just a few highlights: Transform end-user computing experiences with Windows, Windows 365 and Intune Download PowerPoint slides here. Secure and resilient Windows strategy from Client to Cloud Download PowerPoint slides here. What's New in Windows Security, Productivity and Cloud What's new and what's next for Azure Virtual Desktop Books Mastering Windows 365 Mastering Microsoft Intune Get Microsoft certified As a candidate for this certification, you have subject matter expertise managing devices and client applications in a Microsoft 365 tenant by using Microsoft Intune. You’re responsible for: Implementing solutions for efficient deployment and management of endpoints on various operating systems, platforms, and device types. Implementing and managing endpoints at scale by using Microsoft Intune, Microsoft Intune Suite, Windows Autopilot, Microsoft Copilot for Security, Microsoft Defender for Endpoint, Microsoft Entra ID, Azure Virtual Desktop, and Windows 365. Implementing identity, security, access, policies, updates, and apps for endpoints. Learn more about the course via: Microsoft 365 Certified: Endpoint Administrator Associate - Certifications | Microsoft Learn Join the Windows 365 Community Engage with the Windows 365 community to share experiences, ask questions, and learn from others. Participate in forums such as the Microsoft Tech Community and follow relevant hashtags on social media platforms like LinkedIn and Twitter. Connecting with peers and experts can provide valuable insights and tips. Windows 365 Community weekly newsletters Follow us on LinkedIn Join our community on Discord Hands-On Practice There’s no substitute for hands-on experience. Set up your own Windows 365 environment and experiment with its features. Create different scenarios, troubleshoot issues, and explore various settings to get a practical understanding of how Windows 365 works. This practical approach will help solidify your knowledge and boost your confidence in using the platform. Go for our Interactive Demo for Windows 365 to: https://aka.ms/w365demo Attend Virtual Events and Webinars Save the date now for the third installment of the Microsoft Technical Takeoff for Windows and Microsoft Intune! This free, virtual skilling event will offer prescriptive, technical deep dives and panel-based discussions to help you feel prepared and confident in deploying and managing devices, apps, and experiences from client to cloud! Microsoft Technical Takeoff | Microsoft Community Hub Community events in 2025 to attend Workplace Ninja Summit + local user groups Workplace Ninja Summit is another amazing community event where you can learn about all things Intune and Windows 365. Its goal is to share knowledge with the community and to make workplace management with Microsoft Technologies simpler for everybody. Dates: 22 - 25 September 2025 More information can be found at Workplace Ninja Summit 2025 UK edition Workplace Ninjas UK 2025 - Expo + Breakouts | Edinburgh - 16 - 17 June 2025 Australia edition Workplace Ninja Australia Tour 2025 - Canberra, Fri, Feb 14, 2025, 9:00 AM | Meetup USA edition Workplace Ninjas US | 2025 Two-Day Conference Announcement December 2025 MMS Minnesota The Midwest Management Summit is a 4-day conference purposely capped at 750 attendees so that nobody gets lost in the crowd. Speakers have time to meet and talk to you. There are no people rushing out of a session to get the next speaker going. You have time to absorb what you see and talk it over with speakers and other attendees. Dates: May 4-8, 2025 at the Radisson Blu in Bloomington, MN More information can be found at https://mmsmoa.com/ MEM Summit Modern Endpoint Management Summit is an event dedicated to exploring the latest trends, innovations, and best practices in the field of endpoint management. Dates: 23 - 25 April 2025 - Paris, France Learn more about the event via: MEM Summit 2025 EUC Tech Summit Denmark EUCtech Denmark, an independent organization focusing on End User Computing technologies from Citrix and Microsoft. Dates: May 22, 2025 @ 7:30 am - 4:30 pm Learn more: EUCtech Denmark AVD Techfest AVD TechFest is an international festival bringing industry experts, vendors, and community speakers together to share and discover best practices for Windows 365 and Microsoft Azure Virtual Desktop (AVD) technology. Learn more at avdtechfest.com Stay in touch with us. Learning about Windows 365 in 2025 is an ongoing journey that combines official resources, community engagement, and hands-on experience. By tapping into these diverse learning avenues, you can stay ahead of the curve and fully harness the potential of Windows 365 to transform your digital workspace. Oh, and if you did not already, make sure to follow me on Linkedin to stay connected! Happy learning! Christiaan d.Windows in the Cloud at Microsoft Technical Takeoff: November 27-30
If you're looking to go deeper into the Windows 365 and Azure Virtual Desktop announcements from Microsoft Ignite -- and find demos and tips -- join us at the Microsoft Technical Takeoff! Watch deep dives and ask questions live, or catch up on demand and ask questions all week. Here's what's on deck for sessions talking about Windows in the cloud: Exploring Windows cloud solutions: Insights and sample scenarios Nov 27 - 8:00 AM PT What's new and what's next for Windows 365 and Azure Virtual Desktop Nov 27 - 8:30 AM PT Windows 365 and Azure Virtual Desktop powered by Microsoft Intune Nov 27 - 10:30 AM PT Intelligent IT management for Windows 365 and Azure Virtual Desktop Nov 28 - 8:00 AM PT Securing Windows in the cloud: a practical approach for Cloud PCs & Cloud VDI Nov 28 - 11:00 AM PT Accelerate your migration to Windows 365 and Azure Virtual Desktop Nov 29 - 9:30 AM PT VMware Horizon for Windows 365 deep dive Nov 29 - 11:30 AM PT Boosting your productivity with Windows 365 Business Nov 30 - 7:30 AM PT Windows 365 Frontline: let’s talk deployment (and the road ahead!) Nov 30 - 9:30 AM PT Hope to see you there!Upcoming Endpoint Requirements Improvement for Windows 365
Windows 365 has a range of connectivity requirements in terms of FQDNs which need to be accessible directly from the VNet for the service to be able to operate and users connect to their Cloud PC. As the service has grown and expanded, over time this list has grown at in parallel. Significant effort has been going on in the background by our fantastic engineering team to simplify and reduce these requirements and also abstract customers from future change where possible as the service expands and improves over time. I’m pleased to announce Windows 365 customers will start to see the first of the improvements cumulating from this work start rolling out over the coming months. This has been relayed to customers via message center post ID MC675811 already but you’ll find more detail on this change below. What is changing? The first of these improvements revolves around the reduction of the required FQDNs for the service. Over the coming months we’ll be removing the use of a considerable number of the required FQDNs from the requirements, once this is fully complete, we’ll remove them from our docs page and at that point they can then be safely removed from any firewall rules etc. We will send out official communications to customers when this removal can be done. Following this initial phase, even more removals are planned in future as engineering work to facilitate this completes. In addition there are also other significant improvements being worked on which we’ll announce nearer the time they are ready to be released. What are the endpoints being replaced with? We’re moving a large number of the FQDNs to resolve under an existing wildcard FQDN *.infra.windows365.microsoft.com (*.infra.windows365.microsoft.us if within Windows 365 US Government environments) which has been part of the published endpoint requirements for a considerable amount of time. For example, an existing endpoint such as cpcsaamssa1prodprap01.blob.core.windows.net will now become accessible via something.infra.windows365.microsoft.com instead. As the wildcard means ‘anything’, this means we can create future endpoints inside this wildcard domain without the need for changes to your rulesets and configuration. Where in my Windows 365 deployment does this impact? These changes are only for the Cloud PC side only. No access is required for these endpoints on the side of the physical device connecting to Windows 365. For customers using recommended Microsoft Hosted Network (MHN) model, the underlying network for the VNet automatically has access to the required endpoints so for example for traffic initiated during the provision phase has access with no configuration required. However, please ensure any proxy or Secure Web Gateway (SWG) path allows access to this endpoint should connectivity be required from the Cloud PC itself post provisioning. For customers using Azure Network Connection (ANC) please ensure that the underlying network path the VNet has, allows for direct access to this domain, for example through a virtual firewall in Azure providing the required connectivity for the service. Please also ensure any proxy/ SWG path the Cloud PC uses once provisioned, also allows access. Customers using Azure Firewall and FQDN tags should have to make no change as the endpoint is already included in the tag. For more information on these two network deployment models, see here. What are the benefits of this change? There are numerous benefits accrued through this first phase of improvements: Reduced endpoint requirements for initial configuration – Configuring firewalls and rulesets will become significantly simpler. Vastly reduced change rate – As with any growing and expanding cloud service, new endpoint requirements happen regularly. With this approach the goal is to ensure wherever possible, any new service endpoint will come from the existing wildcard FQDN meaning customers are abstracted from this change and do not have to make regular rule updates. Reduced risk of misconfiguration – The simpler requirements and reduced change rate, reduces the risk of missing endpoints in any configuration. Enables future improvements in required endpoint provisioning/management to be announced at a future date. What do I need to do to prepare? As the endpoint we’re migrating to (*.infra.windows365.microsoft.com) has been in the published requirements for a considerable amount of time, it’s very likely that no change to configuration is necessary in most customer environments. However, you may want to ratify that this endpoint is accessible from your environments by doing the following. For Customers using Azure Network Connection, please ensure *.infra.windows365.microsoft.com is accessible directly from the VNet, for example in an Azure Firewall or other NVA. Customers using FQDN tags in Azure firewall need to make no change as the endpoint is already in the tag. For any customers using a proxy or Secure Web Gateway (SWG) for traffic initiated from the Cloud PC once provisioned & configured, please ensure the rulesets for these services allow *.infra.windows365.microsoft.com How do I check access is possible? Although this endpoint isn’t designed to be human accessible, If you wish to ratify that access is possible to *.infra.windows365.microsoft.com you can use the following methods: The recommended way to check is by using an ANC Healthcheck. The check for this wildcard FQDN will be live in the ANC checks late October 23 and will flag a warning if not accessible. I’ll update this blog when this method is live and ready for use. If you wish to manually check access, from a browser running within the VNet you want to test, go to saprod.infra.windows365.microsoft.com – If accessible you’ll get an XML error returned as per the example below. Ensure the traffic is sent direct from the VNet however and not via a proxy or similar as the key connectivity is required during provisioning when proxies will not be in use. From a windows device within the VNet you can use PSPING to make a test TCP connection to the endpoint using the following command Psping -n 5 saprod.infra.windows365.microsoft.com:443 You will again need to ensure this connection is routed directly out of the VNet and not via any SWG/Proxy infrastructure so as to ensure the direct path required for provisioning/operation is available. If successful you should see a response similar to that below:Enable RDP Shortpath for Windows 365 with Proactive Remediation
RDP Shortpath for Windows 365 is now in public preview, bringing the ability to lower latency and improve end-user experience on the Cloud PC. When this feature becomes generally available (GA) it will be enabled by default. But while its in preview, it needs to be enabled on the Cloud PCs. To enable RDP Shortpath, a single registry value needs to be set. Details about RDP Shortpath for Windows 365 can be found here. The registry value to set can be found here. You can use Endpoint Manager to enable this for some or all Cloud PCs with minimal effort. While this can be accomplished in several ways, below are the steps deploy a PowerShell script package using Proactive remediations, enabling IT Pros to see reports on its effectiveness. As RDP Shortpath can improve connectivity to Cloud PCs and Proactive remediations can improve your User Experience score in Endpoint Analytics, using Proactive remediations to deploy this script is a recommended practice to enhance IT Pros' ability to clearly understand the end-user experience of their users. We’ve updated the Windows 365 GitHub repository, creating an RDP Shortpath Proactive Remediation folder. The folder contains two scripts, a remediation script and a detection script to enable the registry value and enable reporting on its status, respectively. Both must be used within a script package in Proactive Remediations. Be aware that the scripts are not signed, which can cause the scripts to fail if your organization is blocking unsigned scripts from running. Before getting started, it is advisable to read the official documentation on this feature as there are caveats and requirements with its enablement. It is also recommended to test this feature on a small set of test systems before enabling it production-wide to ensure it works as intended. This can be done by manually changing the Registry Key as outlined in the following links. Use RDP Shortpath for public networks (preview) with Windows 365 Azure Virtual Desktop RDP Shortpath for public networks (preview) Let’s get started! Firstly, go to the Windows 365 GitHub repo and download the two scripts in the RDP Shortpath Proactive Remediation folder (The Windows 365 GitHub repository) Next, in the MEM portal, open the Reports Tab, then select Endpoint Analytics. Clicking on Endpoint analytics will make new options appear in the console. Click on Create Script Package. Fill out the fields, then click Next. Click the folder icons for the Detection and Remediation scripts. Select the appropriate scripts that were downloaded from our Windows 365 GitHub repo. Once the correct scripts are selected, click next. If you need to leverage Scope Tags, complete the fields as needed. If not needed, or fields completed successfully, click next. Finally, select an Azure AD Group that contains the Windows 365 Cloud PCs that need to be updated to use RDP Shortpath. Once that is complete, click Next. Review the selections and either go back and fix problems or click “Complete”. It will take some time for the data from the Windows 365 Cloud PCs to start populating the dashboard. Once data starts to become available, you can monitor the progress of the scripts. If you need more details about the actions of the scripts, Proactive Remediation provides a way to export the data to CSV. The added benefit to this action is it captures the output of the scripts, giving admins insight to what is happening on the endpoints during remediation. To retrieve this data, click on Device Status, then export. A ZIP file will be downloaded, and upon opening, there will be a CSV file. Once the CSV file is opened, admins can see the outputs from the scripts. Please let me know if this script package had been useful to your organization, if a bug has been found, or suggestions. If you’d like to improve this script, make a Pull Request on the repository. The goal for the repo is to have it be a community compilation, not just a place where I put scripts that I think will be useful.Windows 365 and Azure Virtual Desktop sessions at the Microsoft Technical Takeoff
The next iteration of the Microsoft Technical Takeoff is coming up quick. Four days of in depth sessions, demos, roadmap and Q&A are coming up on Monday March the 3rd to Thursday the 6th. This is a great learning event where we in the Microsoft engineering and product groups go deep on a whole host of topics, from Windows, Azure Virtual Desktop, Intune and Windows365. For those specifically interested in Windows 365 and Azure Virtual Desktop then this is the ultimate short list of sessions. Please click on the link for the session below and then click on the Attend button, (times below are in PST). To access the full site with the entire agenda and session list just visit: aka.ms/TechnicalTakeoff Windows 365 and Azure Virtual Desktop Monday, March 3, 2025 8:30 AM - The path ahead: The roadmap for Windows in the cloud 10:30 AM - Understanding security and management on Windows 365 Link 11:00 AM - Unlocking productivity on the frontline with Windows 365 Tuesday, March 4, 2025 10:30 AM - Skill up! Cloud PC management and reporting 11:00 AM - Get to know Windows security and resiliency in the cloud Wednesday, March 5, 2025 9:30 AM - Enhancing resiliency with Windows 365 10:30 AM - Delivering like-local Windows experiences from the cloud Thursday, March 6, 2025 7:00 AM - Azure Virtual Desktop app management 7:30 AM - Azure Virtual Desktop hostpool management at scale 11:00 AM - Windows cloud migration and deployment best practices
