Windows 365 Watermarking - QR Codes Missing in Screenshots/Teams from Within Session?
Hi all, I've implemented watermarking on our Windows 365 setup using the official Microsoft guide, and I'm seeing behaviour that I'd like to confirm is expected. Current Situation: Watermarking is enabled and working (QR codes appear when I screenshot from my local client PC) However, when taking screenshots FROM WITHIN the Cloud PC session itself, no QR codes appear Similarly, when screen sharing via Teams from within the Cloud PC session, participants don't see the QR codes My Question: Is this the intended behaviour? Should QR codes only appear when capturing externally (from the client device) but not when capturing internally (from within the Windows 365 session itself)? I've read through the Microsoft documentation but can't find explicit clarification on whether internal screenshots should show watermarks or if the protection is specifically designed for external capture attempts. Can anyone confirm this behaviour or point me to official documentation that explains the internal vs external capture distinction? Thanks in advance!
Access Denied message when loading godaddy.com
Beginning 6/15/23 I started receiving an error message when attempting to open http://www.godaddy.com. I've tried different browsers, private/incognito mode, clearing cache/cookies/etc. but the result has been the same. I've tried accessing the site from multiple CPC's and they all produce the same error. When accessing http://www.godaddy.comfrom a local managed PC or from personal PC's, there are no errors, and the site is accessible. Any assistance is greatly appreciated. The error is: Access Denied You don't have permission to access "http://www.godaddy.com/" on this server. Reference #18.4ead3c17.1687548046.57b4032
Windows 365 disconnects on lock, possible to change timeout?
We enabled the SSO/MFA preview and now when our Windows 365 RDP sessions time out they are booting the user off of the RDP session with the message "Windows Remote Desktop Client - You were disconnected because your session was locked." This is apparently by design because of the ability to use passwordless authentication and the fact the lock screen can't support this. The timeout appears to currently be 15 minutes which is fairly short if the VDI is not your only system you are working in. I am wondering if anyone knows of a way to extend this timeout to 30 or 60 minutes. This timeout does not occur if the SSO option is disabled in the provisioning policy. This is on Windows 365 not Azure VDI so there are no backend RDP server settings to change. Also, if anyone at Microsoft is reading this why does it pop up 2 of the exact same message boxes at the same time for this disconnection message? Kind of annoying.
Enable FIDO Token (RSA DS100) passthrough to W365 Machine via Windows App
Hi There, Working with Enterprise license, trying to establish the approach to allow FIDO Token, specifically the RSA DS100, to redirect from the Host device. The users can only connect via the Windows application, not via the RDP client. I have the Device Class/Driver ID of the token. It is key that removable storage is not enabled as a result of this, for obvious reasons. Ideally the allowance would be scoped to only include the token. Thanks in advance.Expanded TURN relay regions for Windows 365 and Azure Virtual Desktop
Starting June 15, 2025, we are launching a dedicated TURN relay IP range across the Microsoft Azure public cloud. This new range—51.5.0.0/16—enhances RDP Shortpath connectivity and delivers faster, more reliable performance for Azure Virtual Desktop and Windows 365 users in 40 regions worldwide. What is TURN? TURN (Traversal Using Relays around NAT) enables devices behind firewalls to establish reliable UDP connections. With RDP Shortpath for public networks, TURN acts as a fallback when a direct UDP-based connection isn’t possible—ensuring low-latency, high-reliability remote desktop sessions. As part of this transition, connections will gradually move away from the existing ACS TURN Relay range (20.202.0.0/16). This change will occur behind the scenes, but, to ensure uninterrupted service, you will need to proactively bypass the new TURN relay range (51.5.0.0/16). This new TURN relay range is part of the ‘WindowsVirtualDesktop’ service tag in Azure, making it easier for you to manage access and security configurations at scale. Benefits of the new TURN relay This change isn’t just a technical update—it’s a regional expansion. We’re scaling from 14 to 40 regions globally, bringing the TURN relay infrastructure closer to users, reducing latency, and improving connection reliability. Combined with a dedicated IP range for Azure Virtual Desktop and Windows 365 traffic, this initiative offers you more control, optimized routing, and a higher success rate for UDP-based communications. Here are the benefits in more detail: Expanding regional coverage By expanding from 14 to 40 regions globally, organizations will benefit from: Lower latency: Data travels shorter distances, resulting in faster connections and reduced lag. Improved reliability: Fewer dropped connections and more stable sessions, especially for real-time applications. Higher UDP success rates: Better performance for voice, video, and real-time data—even under variable network conditions. Dedicated IP Range for Azure Virtual Desktop and Windows 365 traffic This rollout introduces a dedicated IP range tailored for Azure Virtual Desktop and Windows 365 traffic, distinct from the ACS TURN relay. Benefits of this improvement include: Optimized traffic flow for Azure Virtual Desktop and Windows 365. Improved control over network security configurations. Customers can navigate restrictive security setups without compromising performance. Enhanced quality and speed for traffic, free from generic filtering Supported regions Below is a list of supported regions with the new TURN relay. A TURN relay is selected based on the physical endpoints, not the Cloud PC or session host. For example, a user physically located in the UK will use a relay in the UK South or the UK West regions. If the client is far from a supported region, the connection may fall back to TCP, potentially impacting performance. Australia East Japan East Spain Central Australia Southeast Japan West Sweden Central Brazil South Korea Central Switzerland North Canada Central Korea South Taiwan North Canada East Mexico Central UAE Central Central India North Central US UAE North Central US North Europe UK South East US Norway East UK West East US 2 Poland Central West Central US East US2 EUAP South Africa North West Europe France Central South Africa West West US Germany West Central South Central US West US 2 Israel Central South India West US 3 Italy North Southeast Asia How to prepare for this change This new IP subnet will form a critical part of the resilient and performant connectivity provided for Windows 365 and Azure Virtual Desktop. As part of the ongoing transition, traffic will be progressively redirected from the current Azure Communication Service (ACS) TURN relay range (20.202.0.0/16) to a newly designated subnet (51.5.0.0/16). While this shift is designed to be seamless, it’s essential that you preemptively configure bypass rules for the new range to maintain uninterrupted service. With both IP ranges properly bypassed, end users will not experience any connectivity issues. You therefore need to ensure that traffic is both accessible and optimized. Accessible Your environment should have this subnet accessible from all networks used for Windows 365 or Azure Virtual Desktop connectivity, both on the physical network and cloud side. For Microsoft Hosted Network deployments in Windows 365 this underlying connectivity is already in place. For Azure Virtual Desktop and Windows 365 – Azure network connection ANC deployments, the ‘WindowsVirtualDesktop’ service tag contains this subnet so connectivity may already be in place. Optimized The subnet should also be optimized to ensure this critical, latency sensitive traffic has the most performant path available, this means: No TLS inspection on the traffic. This traffic is TLS encrypted transport with a nested TLS encrypted tunnel. TLS inspection yields no benefit but carries high risk of performance and reliability impact and puts significant additional load on the inspecting device. Locally egressed, meaning traffic is sent to Microsoft via the most direct and efficient path. In Azure this means directly routed onto Microsoft’ backbone and for customer side networks, directly to the internet where it will be picked up by Microsoft’s infrastructure locally. Bypassed from VPN, Proxy and Secure Web Gateway (SWG) tunnels and sent directly to the service as demonstrated in the example here. On the Cloud side this may involve using a User Defined Route (UDR) to send the Windows Virtual Desktop traffic direct to ‘internet’ instead of traversing a virtual firewall as can be seen in the example here. Learn more To learn more about RDP Shortpath and how to configure it for public networks, see our documentation on RDP Shortpath for Azure Virtual Desktop.Provisioning Windows 365 Enterprise fails
We are setting up a test for with Windows 365 Enterprise. We have setup the polices and we have assign the licenses. And we see actually that the Cloud PC should be made ready, but the status is pending. When looking at the details it says: But we don't have any in the pending status and we have the licenses assigned otherwise they would not show up there at all. In Office 365 for that account it shows the license is assigned. What could be the issue that makes it think that the are no licenses available? Any suggestions is greatly appreciated. Andreas
W365 Disk partitioning
Dear All, I tried some disk partitioning on a Windows 365 machine. I shrunk the default C: drive that came with W365 machine after provisioning and created successfully another drive (named it 😧 drive). I have a couple of questions here: 1. I have found that my D drive doesn't show on "My PC" of this Windows 365 Cloud PC, but it is accessible and works fine, I can save files there. Could you please help clarify if this is intentionally not shown on My PC? (only c drive with used and remaining space after partitioning is visible at the moment.) 2. Can I manage to do disk partition for multiple Windows 365 Cloud PCs centrally from endpoint management portal or somewhere? Note: I tested this on Windows 365 Business Edition but these questions should cover Enterprise edition as well. Thank you very much
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.
