Forum Widgets
Latest Discussions
Optimizing RDP Connectivity for Windows 365
Updated with RDP & Zscaler connectivity improvements February 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 which all decommissioned IPs removed. 2. UDP based RDP via TURN is currently using the subnet 20.202.0.0/16 but will switch to 51.5.0.0/16 in H1 CY25. The new, dedicated subnet is in the WindowsVirtualDesktop service tag but the current one (20.202.0.0/16) is not, so will manually need to be added to current bypass configuration if desired. More on this can be found in this post. This work will also vastly expand our global TURN relay availability. Today this is only available when the physical device is in the vicinity of these Azure regions. RDP based Connectivity bypass: As of February 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 20.202.0.0/16 UDP 3478 Core UDP based RDP via TURN - Current 4 51.5.0.0/16 UDP 3478 Core UDP based RDP via TURN – Future (Currently not in use) Please see this article for more information on rows 3 & 4 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. We also recommend row 4 is also added to manually configured optimizations to ensure this is also optimized when it comes into use in the coming months. 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 5 azkms.core.windows.net TCP 1688 Azure KMS - Traffic Needs to arrive from Azure public IPs 6 169.254.169.254 TCP 80 Azure Fabric communication 7 168.63.129.16 TCP 80 Azure Fabric communication These additional bypass requirements (5-7) are not RDP related but are required for the following reasons: Row 5 – 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 6 & 7 – 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. As noted above, 20.202.0.0/16 will become unnecessary in a few months and will be removed from this document when decommissioned. It’s replacement (51.5.0.0/16) is already included in the preconfigured bypass. Endpoint Protocol Port Purpose 20.202.0.0/16 UDP 3478 Core UDP based RDP via TURN - Current 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-7 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-4) 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 5-7 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. Rows 3 & 4 above cover 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.
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
How to Automate Windows 365 Cloud PC Last Login monitoring!
Automate Windows 365 Cloud PC Last Login monitoring! (Windows 365, Azure Active Directory, Power Automate, MS Graph) Contributors: Juan José Guirola Sr. (Next Generation Endpoint GBB for Americas) Bobby Chang (Power Platform GBB for Americas) Enterprises of all sizes are adopting and aligning Windows 365 to solve several business-critical scenarios. Organizations appreciate the simplicity of the solution, rapid deployment, and enhanced end user experience; offering the opportunity to include new solutions to their services catalog! Part of the simplicity of Windows 365 is that its management plane is Microsoft Intune. Leveraging the Windows 365 admin blade in Intune, administrators can perform the initial configuration of the service and perform on going monitoring of Cloud PCs deployed within the enterprise with several reports being made visible through the “Reports” blade, to include Device management, Endpoint Security, Endpoint Analytics, etc. We have recently introduced a new type of analytical report – Cloud PC utilization report (preview) – which brings visibility to Cloud PCs with low usage. This is a nice addition to the platform, and a much-needed report. For some organizations, that level of reporting will suffice. But if you are looking for a more custom report that aligns to the specific goals and needs of your organization, then keep reading. This blog will describe how to use the Microsoft Power Platform to automate the reporting of Windows 365 based on your specific criteria and receive notifications via email when the criteria is met. In our example, we are setting the criteria to report on Cloud PCs that have not been logged on to for 60 days or more. Let’s get started. Prerequisites The following items are required to automate the process and deploy 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 Azure Active Directory (Azure AD) Premium (P1/P2) Microsoft Endpoint Manager 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. Register MS Graph in Azure AD If you have followed our previous BLOG – How to automate Windows 365 Cloud PC self-service requests – you may have already performed these steps. If so, please proceed to the next section of this BLOG. 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. Figure 1: 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. Figure 2 : A screenshot of the Register an application screen, showing the details that need to be identified for the new application. Note your Directory (tenant) ID and Application (client) ID GUIDs and then click on API Permissions. Figure 3: 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. Click Add a Permission. 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 ) Figure 4: 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 secret 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 Last Login Monitoring automation! In this section, we will build the Power Automate flows that will orchestrate the Last Login monitoring reporting process. This decision flow illustrates the end-to-end process of retrieving Cloud PC attribute values from the Microsoft Graph leveraging the Windows 365 API and parse through the LastLoginResult value to compare against our criteria of 60 days or more. Figure 5: A flowchart depicting the process for reporting Cloud PC Last Login. 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, “Recurrence” from list. Click Create. Set your desired Interval. Figure 6: A screenshot that shows the Recurrence trigger. Click on + New step (To add variable for the UPN). In Choose an operation, type variable. Select Initialize variable from Actions. Type Init VARUPN details screen. Give it a name, e.g., VARUPN and select “String” as Type. Click + New step (To add variable for the “lastLoginResult” attribute value of the Cloud PC). Choose an operation, type variable. Select Initialize variable from Actions. Give it a name, e.g. lastLoginResult and select “String” as Type. Click on + New step (To add variable for the “Composed_LastLoginResult_Value” of the Cloud PC). Search for VAR in Choose an operation. Select Initialize variable. Give it a name (e.g. Composed_LastLoginResult) and select “String” as Type. Click on + New step (To add variable for CurrentDateTime). Choose an operation, type variable. Select Initialize variable from Actions. Give it a name (e.g., DateNow) and select “String” as Type. In the Value field, Add, Expression, in Fx type utcNow() Click on + New step (To add variable for DateDifference) Choose an operation, type variable. Select Initialize variable from Actions. Give it a name (e.g., DateDiff) and select “Integer” as Type. Click on + New step (To add variable for the “Criteria,” which in our example is 60 day +). Choose an operation, type variable. Select Initialize variable from Actions. Give it a name (e.g., More than 60 days) and select “String” as Type. At this point, we need to determine the automated actions, based on the “LastLoginResult” value of the Cloud PC. This can be accomplished by parsing through each Cloud PC LastLoginRestult value and applying a “Condition” action. Let’s add a GET step to the flow to gather Cloud PC attribute value: Click Add an action. Important! To add the control to perform Graph API calls against tenant to gather Cloud PC attribute value, search for HTTP. In the Method field, select GET. Under URI, set it up exactly as illustrated below: https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/cloudPCs? $select=userprincipalname,id,displayName,managedDeviceName,Status,imageDisplayName,lastModifiedDateTime,lastRemoteActionResult,lastLoginResult For Authentication, select Active Directory OAuth. Leave the authority as default. Enter your Tenant ID under Tenant, https://graph.microsoft.com under Audience, the AppID under Client ID, and the Secret in the Secret section. For production scenarios, you should consider storing your secret in a Key Management solution, like Azure Key Vault If you are using Azure Key Vault, then you can first add the Get Secret action from the pre-built Azure Key Vault connector (https://learn.microsoft.com/en-us/connectors/keyvault/#actions) then securely pass your Secret into this step of your automation - Figure 7: Example setup for Graph API controls to gather Cloud PC attribute value. Hide your Secret from the Power Automate run history Click on the … to the right of the Power Automate HTTP action Select Settings Turn the toggles to On for “Secure Inputs” and “Secure Outputs” in order to not display your Secret in plain text on the logs or run history Click Add an action, and search for “Parse JSON.” Under Parse JSON, select Body for the Content field and insert the body of the HTTP request response into the Schema field. Use the following schema: Figure 8: A screenshot of completed content and schema details for Parse JSON. { "type": "object", "properties": { "@@odata.context": { "type": "string" }, "value": { "type": "array", "items": { "type": "object", "properties": { "userPrincipalName": { "type": "string" }, "managedDeviceName": { "type": "string" }, "id": { "type": "string" }, "displayName": { "type": "string" }, "imageDisplayName": { "type": "string" }, "status": { "type": "string" }, "lastModifiedDateTime": { "type": "string" }, "lastRemoteActionResult": {}, "lastLoginResult": {} }, "required": [ "id", "userPrincipalName", "displayName", "imageDisplayName", "managedDeviceName", "status", "lastModifiedDateTime", "lastRemoteActionResult", "lastLoginResult" ] } } } } 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. Click Add an action and search for “Compose.” In the Compose step, enter rungraph for: {id} Figure 9: Compose control example. 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/@{items('Apply_to_each_2')?['id']}? $select=userprincipalname,id,displayName,managedDeviceName,Status,imageDisplayName,lastModifiedDateTime,lastLoginResult Example: Figure 10: Example setup for retrieving lastLoginResult value for each specific Cloud PC. Follow the same steps as previously outlined to hide your Secrets from the run history (Click on … > Select Settings > Turn toggles to On for “Secure Inputs” and “Secure Outputs”) 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" }, "value": { "type": "array", "items": { "type": "object", "properties": { "userPrincipalName": { "type": "string" }, "managedDeviceName": { "type": "string" }, "id": { "type": "string" }, "displayName": { "type": "string" }, "imageDisplayName": { "type": "string" }, "status": { "type": "string" }, "lastModifiedDateTime": { "type": "string" }, "lastRemoteActionResult": {}, "lastLoginResult": {} }, "required": [ "id", "userPrincialName", "displayName", "imageDisplayName", "managedDeviceName", "status", "lastModifiedDateTime", "lastRemoteActionResult", "lastLoginResult" ] } } } } Figure 11: A screenshot of the Parse JSON schema. Click Add an action and search for “Condition”. Select lastLoginResult under Parse JSON for the value. Select is not equal to for condition. Under Add dynamic content, type null as the expression. Figure 12: lastLoginResult Condition Expression. At this point we are ready to add logic to the flow based on meeting the criteria of the condition. If yes - Click Add an action and search for “Set variable”. Insert a Name (e.g. lastLoginResult) For Value, select lastLoginResult under Parse JSON2 as the Dynamic content Click Add an action and search for “Compose”. Select Compose as the Data Operation. Enter the following expression in Inputs field: split(variables('lastLoginResult-Value'),'"') Click Add an action and search for “Compose”. Select Compose as the Data Operation. Enter the following expression in Inputs field: outputs('Compose_3')?[3] Click Add an action and search for “Set Variable”. Select Set Variable. Give it a Name (e.g. Composed_LastLoginResult_Value) Click on Add dynamic content to add Value Select Outputs under Compose 4 Step. Click Add an action and search for “Set Variable”. Select Set Variable. Give it a Name (e.g. DateDiff) Click on Add dynamic content to add Value Select Expression and enter the following expression div(sub(ticks(variables('DateNow')),ticks(variables('Composed_LastLoginResult_Value'))),864000000000) Now that we’ve been able to extract the proper number of days since lastlogin, let’s send out the email notifications. Click Add an action and search for “Condition”. Select DateDiff variable as the value. Select is greater than as condition. Enter 60 as the value (or whatever aligns to your criteria) Click Add an action and search for “Send an email”. Select Send an email v2. Provide a name (e.g. More than 60 Days Email notification) Enter the necessary information to the fields as necessary for your environment. See below as an example. Figure 13: Sample email template. Once you’re past the Apply to Each scope, Click Add an action, and search for “Terminate.” Set the Status to Succeeded. Return to the initial criteria Conditon to setup the the If no process. Scroll up in the workflow to access this setup. Click Add an action and search for “Set variable.” Select Set Variable. Enter a name (e.g. lastLoginResult-Value) Value enter Blank The entire flow process should look like the image below. Once you’ve completed adding in steps to your automation flow, you’re ready to test the solution. You can run a manual test or wait till the schedule task kicks off. Finally, you should receive an email like the one below: Admin Email Notification NOTE: WE WILL UPDATE THIS ARTICLE IN THE NEAR FUTURE TO INCLUDE THE ADDITION OF UPDATING A TABLE IN POWER APPS AND A FRONT FACING APPLICATION WHERE ADMINS CAN TAKE ACTION TO RECLAIM WINDOWS 365 LICENSE! STAY TUNED!!! 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.Windows 365 Frontline Cloud PC in shared mode – Quick Start Guide
Windows 365 Frontline Cloud PC in shared mode overview Windows 365 Frontline Cloud PC in shared mode builds upon the flexible licensing and usage model of Windows 365 Frontline by enabling the provisioning of shared Cloud PCs for groups of users to access on an occasional or part-time basis. With Windows 365 Frontline, IT administrators can provision collections of standardized, shared Cloud PCs that are assigned to groups of users and dynamically allocated on a one-user-per-PC basis for the duration of their work. When a user signs in, a new user profile is created to facilitate their task, and upon sign-out, the user profile is deleted, preparing the device for the next user. This efficient model allows for optimized resource utilization and streamlines device management, making it an ideal solution for environments requiring flexible and shared computing resources. Recommended use cases Retail, manufacturing and other Frontline staff: Ideal for environments where multiple users need brief access to a Cloud PC to perform specific tasks. For example, retail staff can use shared Cloud PCs to enter inventory information or update data in a line-of-business application. Contractor Scenarios: Contractors who need temporary or occasional access to a company resource for specific projects. Training and Labs: Shared Cloud PCs can be used in training sessions or educational settings where multiple users need access to the same resources at different times. Not recommended use cases Information workers: If users require regular, persistent and personalized access to their data and applications, a dedicated Cloud PC (provided by either Windows 365 Enterprise or Windows 365 Frontline Cloud PC in dedicated mode) is recommended. Licensing To get started with Windows 365 Frontline Cloud PCs in shared mode, you’ll first need some licenses. If you already have Windows 365 Frontline that you’ve been using for “Dedicated” mode, you can use some of those same licenses for Frontline Cloud PC in shared mode. If you don’t have any licenses yet, you can find them on the Microsoft 365 admin center. The following trial is available: A 2 vCPU, 8 GB, 128 GB (1 license/1 month) It’s important to note that Windows 365 Frontline licenses are not assigned to individual users, instead they are surfaced in the Windows 365 provisioning experience and in shared mode, one license allows you to provision one shared Cloud PC. Learn more about Windows 365 Frontline licensing on Microsoft Learn. Provisioning Cloud PCs Provisioning Windows 365 Frontline Cloud PC in shared mode is simple and familiar if you have already used Windows 365. After purchasing Windows 365 Frontline licenses, go to the Microsoft Intune admin center, then Devices and then find the Windows 365 option under device onboarding. Choose the provisioning policies tab. Create a new provisioning policy: License type choose “Frontline” Frontline type choose “Shared” Continue provisioning policy creation with settings optimal to your organization. For best results, we recommend the following modern and simple, cloud-based settings: Join type: Microsoft Entra Join Network: Microsoft hosted network Geography and Region: Choose based on your needs. The supported regions are listed below. On the Image page, we recommend choosing the default Gallery image option, as this is the latest release of Windows (Windows 11 Enterprise 24H2) and it's automatically updated with the latest Windows updates each month. Depending on your scenario, choose between the gallery image with or without Office (Microsoft 365 Apps) already installed. On the Configuration page, configure any optional settings such as choosing appropriate Language & Region settings, applying a device naming template or linking an Autopilot Device Preparation (Preview) policy to ensure Intune Apps and Scripts are applied during provisioning. The optional Autopilot Device Preparation setup steps are covered in more detail below. On the Assignments page, choose the group of users you’d like to have access to shared Cloud PCs once they are provisioned, then choose additional assignment options: Select Cloud PC size. Here you will see the different Windows 365 Frontline licenses you have available in your tenant. You can also see how many licenses are remaining to use in this provisioning policy. Under Assignment name, choose a friendly name that represents the pool of shared Cloud PCs. Choose a name that users will recognize when navigating between different Cloud PCs in the Windows App. The name that you choose here will also be visible on the All Cloud PC list and on IT admin reporting experiences. Under Number of Cloud PCs, choose how many Cloud PCs you’d like to provision and make available to this group of users. Once you complete creating the Provisioning policy, the Cloud PCs will start Provisioning. Review progress in the All Cloud PCs list. Autopilot Device Preparation (Preview) Autopilot Deployment Preparation (AP-DP) profiles can be included in Windows 365 Frontline shared provisioning policies to ensure that essential Intune required, device-targeted apps and scripts are installed on shared Cloud PCs during the provisioning process, before user sign-in. This feature helps increase standardization of shared Cloud PCs while reducing the management overhead that comes with IT admins creating and managing their own custom images with pre-installed applications. Autopilot device preparation tracks the installation progress of specified Intune applications and scripts during Cloud PC provisioning. Instead of marking Cloud PCs as “provisioned” after Intune enrollment, Autopilot and Windows 365 wait until those workloads are fully installed. IT admins will see a new status of “Preparing” reflected in the console while device preparation is underway. Preparation Policy integrating into Windows 365 Provisioning Policies to provision and prepare Cloud PCs. To set up Autopilot Device Preparation for Frontline Cloud PCs in shared mode there are four key steps: 1. Create an Entra ID device group Under Intune > Groups, create a new group. This group is an “assigned” group (also known as a static group) which will initially have no members. It will be populated with Cloud PCs that enroll into Intune during the provisioning process. To enable allow this process to happen, you must assign the “Intune Provisioning Client” as a group owner. Tip: If you have trouble finding this service principle in your tenant, it may have a different name or need to be added. See the Autopilot documentation on Microsoft Learn. 2. Create and assign Intune Apps and Scripts Each Intune Application or Script that you want to install on Cloud PCs must be added to Intune and assigned to the Entra ID device group created in the first step. Tip: You must also ensure that each application and script supports AP-DP and is also configured to install in the “System” context. Learn which Intune app types are supported on Microsoft Learn. 3. Create a Device Preparation Profile In the Intune admin center, under Devices>Enrollment, select Autopilot Device Preparation, create a new Device Preparation Policy: Choose Automatic (Preview) for the type of AP-DP profile. Under Groups, choose the device group you created earlier. As Cloud PCs apply this preparation profile, they will be dynamically added to this group. Under Configuration, choose each of the Intune apps and scripts that must be installed during the Cloud PC preparation phase. 4. Create a Cloud PC provisioning policy Now that you have created the AP-DP profile, the next step is to associate it to your Frontline shared Provisioning policy. Under the configuration tab of a new or existing Windows 365 Provisioning Policy, choose the profile you created in the previous steps and adjust some optional parameters based on your requirements: Minutes allowed before device preparation fails: 30 minutes as a general default but you may need to allow longer for large apps or long-running scripts. Prevent users from connection to Cloud PC upon installation failure or timeout: Unchecked as a recommended default. Enable this checkbox if you want Cloud PC provisioning to fail if AP-DP apps and scripts fail to install or timeout, for example if one of the apps is a mandatory security or compliance requirement. Windows 365 Frontline Cloud PC in shared mode: User experience Once Cloud PCs are provisioned for users, a tile will appear in the Windows app (on web, desktop and mobile platforms) and are tagged with "Frontline shared". Users can have multiple Cloud PCs, including Enterprise, Shared and Dedicated appear for them and can organize and pin them as favorites. When users connect, they are dynamically routed to one of the available shared Cloud PCs in the collection and have a new Windows profile created for them that lasts the duration of their task. The connection and Windows profile creation experience has been optimized to provide employees with a fast connection so that they can get productive immediately. Once signed in, users can access Microsoft and line-of-business applications to complete their tasks. OneDrive sync and Edge are pre-configured so that users can save and persist files and browser settings via between sessions. Once a user finishes their tasks, they can sign out and know that any changes made to the shared Cloud PC will be removed along with their profile, and that the device will be reset for the next user to be immediately productive. Users do have the option to keep sessions active by choosing to “disconnect” from the start menu or closing the Windows app if they need to resume tasks from another physical endpoint. If in any case the Cloud PC becomes unresponsive during use, users are able to get connected with a new Cloud PC by going to the Windows App and selecting “Reset” on the Cloud PC tile. This will restart the currently connected Cloud PC and the user to immediately connect to a new Cloud PC. Planning for and monitoring usage of shared Cloud PCs One consideration for organizations starting out with Windows 365 Frontline Cloud PC in shared mode is determining the appropriate number of shared Cloud PCs (and licenses) needed for a group of users. Windows 365 allows one active user on a shared Cloud PC at a time, so organizations need to consider how many shared Cloud PCs to provision for the scenario at hand. When planning, there are two general approaches for determining the right number of Cloud PCs to provision: If you are migrating a scenario from another VDI solution, it’s helpful to review reports that show maximum concurrency. This is the number of Cloud PCs you will need to provision. If you are designing and building a new solution that requires connection from physical endpoints, for example setting up a new retail store, consider the number of physical endpoints that are available for employees. This is the number of Cloud PCs you need to provision. Concurrent Frontline Cloud PC connections report The Concurrent Windows 365 Frontline Cloud PC connections report can be used to monitor the usage of Windows 365 Frontline Cloud PCs and make adjustments to the number of Cloud PCs over time. For example, if a retail floor staff group is approaching concurrency limits consistently, there is the option to increase the number of shared Cloud PCs available for these users. Coming soon: In addition to observing concurrent usage up to the maximum limit, IT admins will be able to see which users were prevented from connecting to Cloud PCs as pictured above. Learn more about the Connected Frontline Cloud PCs report on Microsoft Learn. Alerts for Frontline Cloud PCs near concurrency limit In addition to the reports, IT Admins can configure email alerts to be informed about approaching concurrency limits and take action. Alerts are configured in the Intune admin center under Tenant Administration > Alerts > Alert rules > Frontline Cloud PCs near concurrency limit. Learn more about the Alert rules and experience on Microsoft Learn. Adjusting Frontline shared assignments Windows 365 Frontline makes it easy to adjust the number of shared Cloud PCs available to users. To increase the number of Cloud PCs: Select the provisioning policy that you have created and assigned to users. In the “Assignments” section click “Edit.” Select “Cloud PC size” which will give the option to adjust the number of Cloud PCs available in the collection. The number of shared Cloud PCs can be increased, for instance, from 20 to 25 Cloud PCs. IT admins can also adjust the idle and disconnect timeout limits for a group of shared devices. By default, Cloud PCs in shared mode will automatically transition shared devices from "Active" to "Idle" after 15 minutes of no user inactivity, and then automatically disconnect and make the Cloud PC available for other users after another 30 minutes. The default policy can be changed based on the organization’s preferences. Learn more about how to set idle session policies on Microsoft Learn. Keeping shared Cloud PCs in a desired state ready for task productivity To ensure task productivity and operational efficiency, many organizations need to standardize the experience for their employees. To revert all devices back to a known-good working configuration or to roll them forward to a newer configuration, IT admins can go to the Provisioning policy and choose Reprovision. When reprovisioning, IT admins can opt for either immediate reprovisioning or a scheduled reprovisioning. When combined with the "Gallery Image" option, scheduled reprovision is a great way to ensure that the collection of Cloud PCs is always running the most up-to-date and secure versions of Windows. For example, IT admins can choose the “Monthly” option and then select “Second Friday of the month” to ensure that devices are reprovisioned with the latest and most up to date Windows 365 Gallery image, which is updated by Microsoft each month. Both Immediate and Scheduled options ensure that user productivity remains unaffected by allowing administrators to designate a percentage of shared Cloud PCs to remain available. Importantly, invoking a bulk reprovision action does not immediately disconnect users with active sessions, but waits until those users sign out to begin the process. Learn more about bulk reprovisioning on Microsoft Learn. Supported regions when provisioning Frontline Cloud PCs in shared mode Windows 365 Frontline in shared mode is expanding into data centers around the world. The following Azure regions are currently supported, with many more on the way: Australia East Canada Central North Europe Central India Japan East Japan West South Africa North UK South Central US East US East US 2 West US 3 South Central US East Asia Southeast Asia UAE North (Coming Soon) Germany West Central (Coming Soon) Norway East (Coming Soon) Switzerland North (Coming Soon) Korea Central (Coming Soon) Next steps This blog post covers key capabilities and features of the new Windows 365 Frontline Cloud PCs in shared mode solution. To get a deeper understanding of the solution, we recommend trying it out in your organization and diving into the product documentation on Microsoft Learn. If you have any feedback on your experience with this solution or if there are things you'd like to see as this product evolves, please let us know!Windows 365 Hybrid AAD Join Health Check PC?
Hello, We have recently deployed W365 Enterprise in our environment. Upon provisioning our first PC using Hybrid AAD Join we have noticied an additional computer object labelled "CPC-Hth*". Is this something required for the health checks of the service? Cannot find informaiton on the MS Docs regarding what this object is used for. Some one has posed the question on the Github repo for the docs but yet to receive an anwer from MS. No mention of health check devices · Issue #2714 · MicrosoftDocs/memdocs (github.com) Anybody got any ideas? Cheers, IanWindows 365 now supported in Mexico and Spain
Today I am pleased to announce that we have enabled Windows 365 in Spain and Mexico. You can now deploy your Cloud PCs into Spain, in the Spain Central region and in Mexico, in the Mexico Central region. Within a provisioning policy if you select the European Union geography, you can then select Spain Central. This increases the number of regions available in the European Union region grouping to six. The Mexico Central region is available from within the new Mexico Geography. Whilst you can select each region specifically we always recommend you select the “Automatic” option to take advantage of more of the benefits the SaaS nature of Windows 365 provides now and in the future. Spain Central: Mexico Central: In the future we will be making some exciting improvements to the provisioning of Cloud PCs by simplifying the region and network selection within your provisioning policies. This expansion increases the number of Azure geographies that Windows 365 supports, giving you more choices for locating your Cloud PCs. This means you can place them closer to your user estate, reducing latency for users in these locations. We are committed to providing more choice and flexibility for your Cloud PCs by enabling new Azure regions over the coming years. This ongoing expansion demonstrates our dedication to evolving the service into a truly global service by growing into existing and new Azure geographies, ensuring you can provide the best service to your organization. Stay tuned for more updates as we continue to enhance Windows 365 and bring it to more locations worldwide.[On demand] Delivering like-local Windows experiences from the cloud
Learn how Windows cloud features like RDP Multipath and TURN improve connectivity and reduce connections times, while HEVC hardware acceleration and enhanced device redirection boost performance. Watch Delivering like-local Windows experiences from the cloud – now on demand – and join the conversation at https://aka.ms/LikeLocalInTheCloud. To help you learn more, here are the links referenced in the session: Hardware-accelerated HEVC (h.265) graphics encoding is currently in public preview! See Enable GPU acceleration for Azure Virtual Desktop | Microsoft Learn for more details For more free technical skilling on the latest in Windows, Windows in the cloud, and Microsoft Intune, view the full Microsoft Technical Takeoff session list.[On demand] Enhancing resiliency with Windows 365
Dive deep into key Windows 365 features like point-in-time restore and the newly launched Cross-region Disaster Recovery. Watch Enhancing resiliency with Windows 365 – now on demand – and join the conversation at https://aka.ms/Windows365Resiliency. For more free technical skilling on the latest in Windows, Windows in the cloud, and Microsoft Intune, view the full Microsoft Technical Takeoff session list.[On demand] Skill up! Cloud PC management and reporting
Get to know the tools you can use today to track Windows 365 utilization, identify underutilized Cloud PCs, and monitor connected Cloud PCs. Watch Skill up! Cloud PC management and reporting – now on demand – and join the conversation at https://aka.ms/CloudPCReporting. For more free technical skilling on the latest in Windows, Windows in the cloud, and Microsoft Intune, view the full Microsoft Technical Takeoff session list.
