In a previous blog post I showed you how you can resize Enterprise Cloud PC’s, you can review that here. In this blog post myself and fellow MVP buddy Paul Winstanley teamed up again to look at the resize ability provided by Microsoft for Frontline Cloud PC’s and show you how you  can use this new feature (new to Frontline). Microsoft announced this new ability a couple of weeks ago here.

Admins can now resize Frontline Dedicated Cloud PCs after provisioning to adjust compute and storage configurations without reprovisioning. This capability provides greater operational flexibility when user requirements change and helps reduce the overhead of managing capacity. Admins can respond more easily to evolving performance needs while keeping existing Cloud PCs intact. For more information, see Resize Windows 365 Frontline Cloud PCs in dedicated mode.

Why resize?

Imagine you have a user that has a Frontline Dedicated Cloud PC assigned, with the following SKU.

• Cloud PC Frontline 2vCPU/8GB/128GB

This may have been good enough for the tasks that that user was initially doing, but let’s imagine that they got access to new tasks that demanded more CPU/ram/storage, or that they simply noticed that the Cloud PC they were given was under powered.

Sometimes you may find that a Cloud PC is not powerful enough for a user, or is too powerful and not being used to it’s full potential (low utilization). With this new ability you can resize low or high utilization Frontline Dedicated Cloud PCs on the fly.

Identifying low utilization

You can now identify low utilization on Windows 365 Cloud PCs in the Intune portal directly. In the Reports node, expand Windows 365, select Cloud PC Overview and then select Cloud PC recommendations.

Unfortunately this report only seems to cover Enterprise Cloud PC’s and we are focusing on Frontline Dedicated in this blog post. But there’s another way, in Devices, expand Device Onboarding, select Windows 365 and select Resource performance.

This brings up Endpoint analytics with lots of resource performance details.

You could click on the highlighted Insights and recommendations

or click on the Model performance or device performance tabs to get more details.

And sure enough, there’s our Frontline Dedicated Cloud PC showing as needs attention due to CPU spike time and to a lesser degree, RAM spike time.

Now that we’ve spotted the Frontline dedicated Cloud PC’s that need help, it’s time to fix  the problem.

Resizing

So let’s take a look at the new feature. Take note of the role, ip address and other requirements as detailed here.

To resize a Frontline Dedicated Cloud PC, locate it’s provisioning policy, and scroll down to Assignments, click Edit.

Click on Cloud PC size highlighted in blue.

This will bring up a Select Cloud PC size window where you can select from available sizes.

From there, pick an option to fix the problem, in this case we’ll resize the current Frontline Cloud PC from one sku to another via the Available sizes drop down, as it’s only an example of the resize operation.

Note: In reality, to fix this problem you’d want to resize to a vCPU with more power and possibly more RAM too based on the endpoint analytics report, however we don’t have either of those available in this tenant.

Also to note, downsizing is not supported for lower storage or GPU.

Take note of the warning, which states that All the Cloud PCs provisioned from this assignment will be resized to the selected size. Connected Cloud PCs will be disconnected, and unsaved changes might be lost. This is important and you should most likely only resize when your Frontline users are not actually using these Cloud PC’s if possible.

Finally, click Next and click Update to update the provisioning policy assignment with the new resized SKU. You can see the entire operation in the GIF below.

Job done!

Read more

• Announcement – https://learn.microsoft.com/en-us/windows-365/enterprise/whats-new#week-of-march-2-2026
• Frontline dedicated Cloud PC resize – https://learn.microsoft.com/en-us/windows-365/enterprise/resize-cloud-pc-frontline

Summary

Resizing Frontline Dedicated Cloud PC’s is now a reality and available today in the Intune console. You have to modify the provisioning policy to resize the Cloud PCs which can mean several Cloud PC’s being impacted from this change, rather than just one. Still, it’s a welcome change and we are glad to see it.

See you in the next one!

The Remote Desktop client app is commonly used for connecting to a variety of devices including:

• Connecting to Azure Virtual Desktop (AVD)
• Accessing Windows 365 Cloud PCs
• Access Remote Desktop Services (RDS)
• Connecting to remote PCs (when configured for RDP)

The app is popular due to the fact that it has multi device support including Windows, macOS, iOS and Android, but it’s interface looks dated to say the least. Below you can see how it looks today including the end of support message on the top.

The app is soon to be end of support as of March 27th, 2026 and you are reminded of that in the banner on the app itself (shown above) and via the downloads webpage shown below.

You should start migrating the app on any devices that have it installed to the new Windows app. The remote desktop client app does not automatically upgrade to the Windows app so migrating it is needed. Migrating from the remote desktop client to the Windows App can be complicated. It can be used as-is or modified to suit your individual needs.

It performs the following actions:

• Installs the Windows App via MSIX package download
• Optionally uninstalls the legacy Remote Desktop client
• Sets registry keys to control auto-update behavior
• Logs all actions to a specified log file

Myself and my fellow MVP buddy Paul Winstanley look at a migration tool provided by Microsoft and show you how you can set this up in your Intune tenant based on the instructions that come with it.

Setting it up

To set it up do as follows, in Microsoft Intune select Devices, Scripts and remediations and select Platform scripts. In there click on Create and give the script a suitable name such as Migrate from remote desktop client to Windows app.

Click Next and in Configure script settings point to the downloaded Remote Desktop Client Migration script and set the following options:

These settings force the script to run in SYSTEM context (required to set registry keys and install provisioned packages, in addition to uninstall system-level apps).

Click Next and add a group of one or more targets to migrate from the Remote desktop client agent to the Windows app. You could also exclude a group containing devices that already have the Windows app.

Monitor the results

After deploying out the script you can check the results via the log. The log (on the target clients) is available at $env:windir\temp\RDC-Migration.log. Below is an example of that.

Within Intune itself, you can look at the script results,

if there are errors below are some common error codes.

If the Windows app is shown as installed in the log but not actually installed on the device you can run the following two Powershell checks to see why it’s reporting this.

# Check provisioned packages
Get-AppxProvisionedPackage -Online | Where-Object {$_.DisplayName -like "*Windows365*"}

# Check user installation
Get-AppxPackage -Name *Windows365* -AllUsers

In our case the Windows app was not available on the device any more (had been uninstalled prior to deploying the migration script). But still Windows thought it was installed even though we logged off/logged on again prior to the test.

Related reading

• Download the Remote desktop client app – https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/connect-windows-cloud-services?tabs=windows-msrdc-msi
• Migrating to Windows app – https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/migrate-msrdc-windowsapp
• Remote Desktop Client Migration script – https://github.com/microsoft/Windows365-PSScripts/tree/main/Remote Desktop Client Migration Script

Summary

The impending end of support of the remote desktop client app is coming in less than 20 days, so it’s a good idea to migrate your install base to the new supported solution, the Windows app.

Microsoft have been kind enough to provide a script, and it works as you’d expect a Powershell script from Intune. Powershell scripts however are limited when deployed this way and we think it would be better to deploy this migration tool as a Win32 app or even a remediation solution.

For example, you might consider wrapping it with PSADT (Powershell application deployment toolkit) or similar and deploy it as a Win32 app to get better results, otherwise you might see issues relating to the Remote desktop client agent app being in use and thus not removed or that the user didn’t login yet. Most of the observed issues are listed in the troubleshooting section of the downloadable script.

That’s it for this blog post we’ll see you in the next one!

Introduction

Windows 365 User Experience Sync (UES) is a cloud‑native capability designed to give users a seamless, consistent, and personalised Windows experience across Windows 365 Cloud PCs and Windows 365 Cloud Apps. Without UES in place on Frontline Shared devices, Windows personalisation, user settings, application settings, and application data are retained on logoff/logon which can be frustrating for end users who need to reauthenticate or reconfigure to set up their device how they need to use it, only to have to do this each time they log on to the Cloud PC.

Instead of relying on traditional profile‑management tools, UES automatically preserves the settings every time the user signs in. Microsoft manages the UES infrastructure, vastly decreasing the implementation complexity and cost compared to other profile based solutions.

At the core of User Experience Sync is dedicated, cloud‑hosted user storage that follows each user from session to session. When a user signs in, their individual storage is dynamically attached, providing immediate access to their personal settings and app data. As the user signs out, the profile is detached and stored securely ready for the next session.

In this blog post myself and fellow MVP buddy Niall Brady overview this new feature and show you how you can set this up for Windows 365 Frontline Shared Cloud PCs and Cloud Apps. Myself and Niall were part of the private preview for the solution and were heavily involved at that stage. The feature was made generally available in November and we will be interested to see that changes have been made to the solution, based on our feedback, in that time.

Requirements

The following requirements are needed at present.

• Windows 365 Frontline license
• Access to required Windows 365 and Microsoft 365 endpoints
• Intune management permissions

Setting it up

When it comes to setting up the Windows 365 User Experience Sync, the enablement of the feature is achieved in the configuration of the Frontline Shared Provisioning Policy. This can be done when creating a new policy, or an existing policy can be modified to add or remove the feature. Let’s focus initially on creating a policy and enabling the UES solution.

In the Intune admin center, navigate to Devices | Device onboarding | Windows 365. Select Provisioning policies from the menu and choose Create Policy.

When creating the provisioning policy, ensure that you select Frontline as the License type and enable Shared from the Frontline type choice. For Experience, you can choose either Access a full Cloud PC desktop, or Access only apps which run in the cloud, since both Cloud PCs and Cloud Apps support UES.

The Configuration section of the provisioning policy wizard is where we configure the UES solution. We have two choices to make; Enable user experience sync and User Storage Size. Check Enable user experience sync to turn on the feature.

Managing the UES storage

For the User Storage Size, Microsoft offer a predefined pool of user storage that comes included with your Frontline licence. The total available storage is determined by the Cloud PC’s OS disk size and is scaled based on the number of Cloud PCs assigned within the policy.

For our Frontline model, we have a Cloud PC Frontline 2vCPU/8GB/128GB licence and 1 Frontline device, therefore the amount of pooled storage available to us is 128 x 1 or 128GB.

The User Storage Size allows us to assign up to 64GB per user as you can see from the drop-down menu below.

Be aware of the pooled disk space limitations when assigning the the User Storage Size.

• Exceeded limits: When pooled storage runs out, new users can still sign in, but they receive a temporary profile and cannot create their own user storage. Users who already have allocated storage can continue signing in with their full personalised experience.
• Exceeded tolerance period: If the pooled storage limit remains exceeded, a 7‑day tolerance window begins. After this period ends, the system automatically removes individual user storage starting with the one that has the oldest “last attach” timestamp. Once the total storage usage drops back below the limit, the tolerance period resets and won’t start again until storage is exceeded in the future.

You can manage the user storage by selecting going to Provisioning policies and clicking your newly created policy.

Next, select User storage and you will be presented with a view of the Storage information which includes the Total, Available and Used data. Since we are currently provisioning the devices, nothing will be used.

Some recommendations to assist with UES are to:

• Enable OneDrive redirection
• Manage Edge for cache and temporary data retention
• Deploy Storage Sense to clean up temporary files, delete downloads and cloud backed files (OneDrive)

You can set up alert monitoring for the user storage. This is achieved by navigating to Tenant administration | Alerts | Alert Rules and clicking Frontline Cloud PC User Experience Sync Storage Limits.

In the System rule view, you can set to alert when used space is Greater then or equal to a certain percentage. You can set a Severity for the alert, if the Status of the rule is On or Off, whether to have a Portal pop-up Notification and if someone should receive an Email alert. You can enter multiple recipients for the email.

What’s Included and Exclude from User Experience Sync (UES)

The following is included in the UES solution:

User storage includes all data from C:\Users%username%, such as:

• User settings and application data
• Registry files, (NTUSER.dat and USRCLASS.dat)
• Personal files and folders

What’s not included:

• Nonroamable application data
• AppData\Local\Packages*\AC
• AppData\Local\Packages*\SystemAppData
• AppData\Local\Packages*\LocalCache
• AppData\Local\Packages*\TempState
• AppData\Local\Packages*\AppDat

Nonroamable identity data

• AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
• AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
• AppData\Local\Microsoft\TokenBroker
• AppData\Local\Microsoft\OneAuth
• AppData\Local\Microsoft\IdentityCache

The UES Experience

When a user signs on for the first time to a Cloud PC or Cloud App with UES enabled, the personal storage will be created and attached to the session and capture of settings will be automatically enabled and redirected to the storage. On the next login, the UES will be reattached and any saved configuration loaded.

Do bear in mind that UES does not roam or persist user installed applications, only settings and preferences are captured.

On a Frontline Shared UES enabled device, we are loading the store app Sticky Notes for the first time. We are requested to authenticate to use the app on first run.

After authenticating, we can create content in the app with the expectation that this is stored within the UES storage and retained for our next session.

If we do not have Frontline Shared UES enabled, then the end user would need to re-authenticate with the Sticky Notes app on each logon to bring up their personalised notes.

Installing apps

Another thing to note is if the user downloads and installs an app, let’s say Firefox. While this works during the session that the user is logged on to, once they logoff/logon any remnant of that (shortcut, etc) are gone. If you want apps to persist then install them in the base image (custom image).

Filling up the storage and reporting on usage

One of the areas we fed back on during the private preview, was the lack of warning or information for the end user when the UES becomes full. In the screenshot below, for example, the user has downloaded too many ISO files and filled up their allocation of 16GB. The only message the end user gets is Couldn’t download – Disk full. This isn’t informative enough for the end user in our opinion. Improvements to the experience should be forthcoming and we hope that this is one which is being taken into account by Microsoft.

When it comes to usage, the admin can take a look at what allocation of their Total amount is in use in the User storage section of the Provisioning Policy. Remember from earlier, you need to click Provisioning policies and select your policy.

Select User storage to view. We can now see that 16GB from the Total of 128GB has been allocated to a user. These stats do not give us a real time view of what a user has actually used from that 16GB allocation. This is another area that we fed back on that we feel needs improvement.

If we have set up alerts and total usage across all UES compromises the percentage stated in the rule, then the recipient of the alert rule will receive an email with details of the provisioning policy where the usage is a concern.

In Tenant administration | Alerts admins will be alerted with the relevant Severity and with a pop-up, if enabled.

Amending an Existing Provisioning Policy

To be able to amend an existing provisioning policy to add or remove UES, you first need to remove the the current group assignment from the policy.

Navigate back to Provisioning policies and select your Frontline shared policy.

Choose Properties.

Scroll down to the Assignments and click Edit.

Delete the assignment.

Click Remove to confirm the removal of the assignment. Click through the wizard to Update the policy.

Now Edit the Configuration section of the policy.

This is our UES policy with UES enabled. We can, therefore, remove UES by deselecting the Enable user experience sync checkbox. If this was a policy which never utilised UES, we could go into here and select to use and set a corresponding User Storage Size.

Once amended, Update the policy and head back to Assignments and Edit. Reassign the policy and enter the relevant Cloud PC size, select your Frontline subscription and Assignment details.

The Frontline shared devices will then be in a Provisioning state as the amended configuration is laid down.

Read more

• User Experience Sync for Windows 365 Frontline in shared mode – https://learn.microsoft.com/en-us/windows-365/enterprise/frontline-user-experience-sync
• Troubleshoot User Experience Sync for Windows 365 Frontline in shared mode – https://learn.microsoft.com/en-us/troubleshoot/windows-365/troubleshoot-user-experience-sync

Summary

Windows 365 User Experience Sync is a welcome feature for Frontline Shared devices which has been on the wish list for some time now. It is very simple to get up and running, without all the complexity of other solutions and provides instant access to storage of settings and application data.

Microsoft is taking into the account the feedback it received during the private preview and we should see some feature changes happening very shortly to improve the end user experience.

We look forward to seeing how this new feature matures and develops over time and we’ll blog about the feature improvements as they are released.

I started my day as always and launched the Windows app, I clicked my Cloud PC, entered my credentials and after a short delay I got an error shown below.

The error shown above was “something went wrong” with a very not useful error code, -895352830. I tried this on multiple tenants with the same error code being generated.

I asked Copilot what this meant and got the following details

Verifying the problem

A quick look in Intune, revealed that indeed the problematic CU was indeed applied to my Cloud PC’s and the PC I was making the connection from (Windows 11 25H2 ARMx64).

Here’s a sample. As you can see below

Below you can see the CU details…

• 10.0.26200.7623
• 10.0.26100.7623

https://support.microsoft.com/en-us/topic/january-13-2026-kb5074109-os-builds-26200-7623-and-26100-7623-3ec427dd-6fc4-4c32-a471-83504dd081cb

and within that you can see the known issues including the suggested workaround, which is to install KB5077744.

As it’s so new this update is not even available in Windows Autopatch so you cannot currently use expedite updates policy to deploy this.

wusa.exe windows11.0-kb5077744-x64_fb63f62e4846b81b064c3515d7aff46c9d6d50c8.msu /quiet /forcerestart
exit $LASTEXITCODE

powershell.exe -ExecutionPolicy Bypass -File Install_KB5077744.ps1

and the following detection script.

$sysinfo = systeminfo.exe
$result = $sysinfo -match "KB5077744"


if ($result) {
Write-Output "Found KB5077744"
exit 0

} else {
Write-Output "KB5077744 not found"
exit 1

}

Finally, after deploying the update to your affected clients, and waiting for it to install and restart, you’ll be able to connect again.

Phew.

What a relief.

The new Windows build number is highlighted below.

10.0.26200.7627 from a Windows 11 25H2 Cloud PC.

Related reading

Introduction

While Windows 365 Cloud PCs deploy robust perimeter defences—encrypted transmission channels and multi-factor authentication that thwart network-level attacks—a critical vulnerability persists at the endpoint itself. Malicious software operating on local devices, particularly keystroke capture tools, can intercept sensitive information before it ever reaches the cloud environment. These endpoint-resident threats create regulatory exposure and potential financial damage that traditional cloud security measures cannot address.

Windows Cloud IO Protection closes this gap by introducing a kernel-level driver and system-level encryption that sends keystrokes directly to the Cloud PC, bypassing OS layers vulnerable to malware. When enabled on a Cloud PC it enforces a strict trust model:

• Only verified physical endpoints can connect.
• Endpoints must have the Windows Cloud IO Protect MSI installed.
• If the MSI is missing, the session is blocked and an error is displayed.

This ensures a secure, uncompromised input channel between the Windows client and the Cloud PC.

In this blog post myself and fellow MVP buddy Paul Winstanley overview this new feature and show you how you can set this up for Windows 365 Cloud PCs.

Requirements

The following requirements are needed at present. The feature is public preview and could change as this becomes Generally Available:

• Host physical Windows 11 devices
• Devices must have TPM 2.0
• Host devices must have the Windows Cloud IO Protect agent installed
  • Download the Windows x64 release
  • Download the Windows ARM 64 release
• Windows App running 2.0.704.0 or later

The following is not currently supported:

• macOS
• iOS
• Android
• Windows 365 Link
• Using the Web client

Setting it up

When it comes to setting up the Windows Cloud Keyboard Input Protection feature, Microsoft has an interesting approach in that its documentation currently only supports using group policy to achieve this. The setting Windows Components > Remote Desktop Services > Remote Desktop Session Host > Azure Virtual Desktop > Enable Keyboard Input Protection needs to be enabled.

During our testing phase, we were fortunate enough to be part of the private preview release, we had to set the following registry keys for Windows 365 devices, with just the former key being required for AVD devices:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\
DWORD - fWCIOKeyboardInputProtection
Value - 1

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings
DWORD - SecureInputProtection.KeyboardProtection.IsEnabled
Value - 1

To assist with this on your Entra only Cloud PCs, we have created an Intune proactive remediation script to set the values, if they are not present on your Windows 365 devices. These scripts need to be targeted to the Cloud PCs, and not the host devices.

You can download the detection and remediation scripts from GitHub.

Adding the Proactive Remediation script for Keyboard Protection

In the Intune admin center, navigate to Devices | By platform | Windows | Manage devices | Scripts and remediations.

Ensure you are in the Remediation view and click Create.

Enter a Name for the custom script and add an optional Description. Click Next when done.

Click the browse icon for the Detection script file and upload the Detect-KeyboardProtection.ps1 downloaded from GitHub. Repeat the process for the Remediation script file by uploading the Remediate-KeyboardProtection.ps1 script. Leave all other options as default and click Next.

At the Assignments section, choose the group of devices that you wish to targeted. You can adjust the schedule for the execution of the remediation by clicking the Daily link under Schedule.

For example, for our testing we have set the remediation to run Hourly. Click Apply when you have made your adjustment.

The new schedule will be reflected accordingly in the Intune console.

When you have completed the proactive remediation wizard, you will see the new remediation listed and with a Status of Active.

When the script has executed against devices, the Detection status will be reported back to Intune with statuses of Without issues, With issues, Failed or Not applicable. Any Remediation status data will also be reported where applicable.

Installing the Windows Cloud Input Protect MSI Agent

Referring back to the Microsoft documentation, the MSI install is documented using a manual method of installation the application, and this would require local admin rights to achieve this. Instead, we can push the Windows Cloud Input Protect MSI via Microsoft Intune to an Intune managed host device.

We can configure the application as a Win32 app and, therefore, we need to use the Microsoft Win32 Content Prep Tool, which you download from https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool, to convert the app into the .intunewin format.

Here is a blog written back in 2019 on how to use the Content Prep Tool https://sccmentor.com/2019/02/17/keep-it-simple-with-intune-4-deploying-a-win32-app/

We can package the MSI into the required .intunewin format with three simple switches:

• -c – this points the tool to the source folder containing the binaries
• -s – this points the tool to the setup file used to execute the application
• -o – this tells the tool where to output the .intunewin to

Once the tool is run, it quickly creates the .intunewin file for the Windows Cloud Input Protect MSI.

We can now take this file and import it into Intune when we create the Win32 app.

Navigate to Apps | Platform | Windows, in the Intune admin center. Click Create.

From the App type drop-down, select Windows app (Win 32) and then choose Select.

You will now be navigating through the Add App wizard. Start by clicking Select app package file.

Click the browse icon and locate the .intunewin file that you created. Click OK to upload the file.

Details will be automatically added to the App information fields. The only mandatory field you will need to complete is the Publisher field. Feel free to add any further information you require. Click Next when done.

In the Program section of the wizard, further details will be automatically added, such as Install command and Uninstall command. We will use these default values for our application. Click Next to continue.

In the Requirements section, you can be selective on the specific requirements for the installation of the app. We have ensured that Yes. Specify the systems the app can be installed on is selected and we have chosen Install on x64 systems as we downloaded the x64 release of the MSI. You must also select a Minimum operating system level for the install. Click Next when you have completed this section.

For the Detection rules, we have kept this simple and chosen Manually configure detection rules from the Rules format drop-down and chosen the MSI type, which automatically uses the MSI ID for the application.

Finally, a reminder that when targeting the Windows Cloud Input Protect MSI agent, we are targeting Windows 365 host devices and not the Cloud PCs themselves.

When the Windows Cloud Input Protect MSI agent installs, you will see an entry for the Windows Cloud IO Protection driver in Program and Features on your host device.

and, hopefully, this is reflected in the Intune admin center in the apps Overview section.

Connecting from a host device which is not running the Windows Cloud Input Protect MSI agent

At present, there is no visual indication to let you know if the Cloud PC is running with keyboard protection enabled, and this was one of the feed back areas in the private preview. It is coming and we should expect something fairly soon.

When you attempt to connect from a device which is not running the agent, you will get the following error dialog box.

and Windows App will report similar. We expect to see something similar, like the AI-enabled heading on a device which has the AI features enabled. Fingers crossed that this arrives soon.

Connecting from a non supported device platform can produce different error messages that are less intuitive. For example, the screenshot below shows the error when connecting from the Windows App on an Android device. Hopefully, support will be extended to other device platforms over time, and error messages updated to reflect the connection issue.

Read more

• Keyboard Input Protection for Windows 365 and Azure Virtual Desktop now in preview – https://techcommunity.microsoft.com/blog/windows-itpro-blog/keyboard-input-protection-for-windows-365-and-azure-virtual-desktop-now-in-previ/4468102
• Windows Cloud IO Protection – https://learn.microsoft.com/en-us/windows-365/enterprise/windows-cloud-input-protection

Summary

Windows Cloud IO Protection is a powerful security feature that ensures keystrokes are encrypted and sent directly to the Cloud PC, bypassing OS layers vulnerable to malware. By requiring trusted endpoints with the protection agent installed, it creates a secure, uncompromised input channel that blocks keyloggers and prevents data leaks.

Microsoft is taking into the account the feedback it received during the private preview and we should see some feature changes happening very shortly to improve the end user experience.

Beyond this, we hope that support is adopted for all device platforms, so that this security feature becomes OS agnostic.

We look forward to seeing how this new feature matures and develops before being released to production.

Microsoft have invested a lot of time, effort and money on adding AI abilities to core parts of the Windows Operating System and the apps that run on it, for example Office 365 apps or dedicated AI apps such as Microsoft 365 Copilot.

Myself and my good friend Paul Winstanley took a look at a new feature to add select AI features to Windows 365 Cloud PC’s and share our thoughts below.

Windows 365 AI-enabled Cloud PCs run in Microsoft’s Cloud and stream AI-powered Windows to any device and platform. This allows you to use select AI features that would traditionally be found on physical NPU powered Copilot+ PC’s. Those select AI features are:

• Improved Windows search
• Click to Do

You can test these AI features on any device using your Cloud PC for example, below you can see an AI-enabled Cloud PC available from an Android powered phone.

Note: In the screenshots below from our Android phones, the AI-enabled Cloud PC has an AI-enabled label in the top left corner.

But first, let’s take a look at what you need in order to set this up.

Requirements

The requirements below will most likely change as this becomes Generally Available, but to test it right now in this Frontier release you’ll need to do the following:

• The end user must be registered in the Windows Insider program
• The Cloud PC must be in the Windows Insider Beta channel
• Enable Data diagnostics in your settings
• Have a Cloud PC that supports AI abilities (8vCPU, 32GB ram, 256GB HDD)
• The Cloud PC must be in a supported location

Setting it up

To set it up make sure you’ve enabled data diagnostics in your Windows Privacy settings, as shown here. Set the Send optional diagnostics data to On.

Next, enroll into Windows Insider Program and select the Beta Channel (Recommended).

Once done you’ll most likely have to restart the CPC, so go ahead and do that.

Next, you’ll need to configure a policy (targeted to users) which enables the feature for Cloud PC’s that meet the minimum requirements. To do that select the Windows 365 node in Intune, click Settings and select Create to create the policy. Select Cloud PC configurations (preview) from the options presented.

In the Configuration settings part of the wizard, select Enable from the drop down menu to enable AI features.

and on the Assignments screen, select a previously created Entra Id group with users that will be using this new ability.

Once done, make sure one or more users are in that group and the policy should flow to the CPC’s.

Exploring the new AI abilities

The first thing you’ll most likely notice is that your AI Enabled Cloud PC’s are now clearly labelled with an AI-enabled label in the Windows app.

After connecting to that Cloud PC, you’ll notice the search icon looks different.

AI-enabled Cloud PCs are marked by a magnifying glass with a sparkle icon within the search box on the taskbar.

Those of you who already have physical Copilot + PC’s will already be familiar with this new search icon.

The new AI search abilities are supposed to be better than built-in traditional search, so we put it to the test. We decided to start with by simply searching for a word via the search feature in Windows File Explorer on the users OneDrive. We performed the same search on the AI-enabled CPC as well as on a regular non-AI powered physical device.

The AI search results are on the left, and the traditional search results on the right. Look at the difference, 37 hits versus 10, not bad at all.

Lets try another search. This time again, more results from the AI search versus traditional search.

Click to do

Microsoft Click to do is a feature on all Copilot+ PC’s and Windows 365 AI-enabled Cloud PC’s. To use it simply search for it in the start menu and click the app.

Once started, you can browse websites with pictures of text (for example) and press the Windows key + mouse click anywhere in the website. This can give you options to do things with what it sees, such as copy text within an image

to paste into your favorite text editor,

Depending on what you click on you get more or less options, such as below when clicking on the image of a blue CRT.

Cool!

Changes in Intune

When using Windows 365 AI-enabled Cloud PC’s there are some additional things that you can see in the Intune portal to reveal the finer details. There’s a report here to show AI-enabled CPC’s and what (if anything) is wrong with them. To find it select Reports, and select Cloud PC overview.

Select the AI-enabled Cloud PC report, and you can then click through the Status column for any Cloud PC that has reported data up to Intune.

Once you’ve fixed the issues reported, which in our case we provisioned the Cloud PC in a location that was not yet supported for AI-enabled abilities, you’ll see a new status of Ready to use.

You can also see a new status in Cloud PC’s overview, called AI-enabled, which will report Yes or No.

Read more

• AI-enabled Cloud PCs – https://learn.microsoft.com/en-us/windows-365/enterprise/ai-enabled-cloud-pcs
• Experience next-gen productivity with Windows 365 AI-enabled Cloud PCs – https://techcommunity.microsoft.com/blog/windows-itpro-blog/experience-next-gen-productivity-with-windows-365-ai-enabled-cloud-pcs/4467875
• Experience next-gen productivity with Windows 365 AI-enabled Cloud PCs – https://youtu.be/CvL8UXCYzDk
• Using Microsoft Click-To-Do https://support.microsoft.com/en-us/windows/click-to-do-do-more-with-what-s-on-your-screen-6848b7d5-7fb0-4c43-b08a-443d6d3f5955

Summary

This new feature via the Microsoft Frontier Program has a lot of cool potential! It’s great to see that Microsoft is continuing its investment in Windows 365 Cloud PC development, and adding key features like this brings the power of AI to all devices, whether they are Android, macOS, Windows.

We look forward to seeing how this new feature matures and develops before being released to production.

Introduction

In a previous blog post I started troubleshooting why my Windows app showed a blank white screen instead of the usual User Interface. I did a bunch of troubleshooting but it didn’t lead anywhere or so I thought. No matter what I did, I could not use the Windows app any more.

So I kept digging. By checking the Details section of Task Manager, I could see where the Windows365.exe executable file was launched from.

C:\Program Files\WindowsApps\MicrosoftCorporationII.Windows365_2.0.366.0_arm64__8wekyb3d8bbwe

I browsed the files and folders in there and found an interesting to me json file called system_settings.json in the Resources folder, it referenced the Microsoft remote desktop client agent (msrdc)  and a quick search on the internet revealed that that version was not the latest.

So I downloaded the latest version and installed it. I then re-attempted to start the Windows app, but to no avail, it was still blank.

The MSRDC agent

I’ve been using the Windows app since it’s first iteration, so it was easy to forget about msrdc. Launching that Microsoft Remote Desktop Client agent allowed me to see and use my Cloud PC’s so that was at least a workaround for accessing them until the problem was resolved.

Back to the problem though. Looking through event viewer I could see lots of errors in AppXDeployment-Server, maybe they had something to do with my problem.

That error was:

Deployment Register operation with target volume 😄 on Package MicrosoftCorporationII.Windows365_2.0.365.0_arm64__8wekyb3d8bbwe from: (AppXManifest.xml) failed with error 0x80073D02. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.

I followed the link and it revealed the following for that error code.

Webview2 revisited

This ‘currently in use’ error got me thinking again about the Outlook New Webview2 problem, which I never managed to solve in part 1. But first, what is Webview2 ? see here.

WebView2 is a way for app developers to embed web content (such as HTML, JavaScript, and CSS) in Windows applications. By including the WebView2 control in an app, a developer can write code for a website or web app, and then reuse that web code in their Windows application, saving time and effort. See Introduction to Microsoft Edge WebView2.

So what was the Outlook New problem ? Namely every time I started Outlook New, it would prompt me to install Webview2.

As you can see in the previous part I tried to fix that and thought that I had, but in reality, the problem was still there and Outlook New always complained about the Webview2 requirement.

Could the Webview2 installer be stuck in a loop somehow and that could be affecting the Windows app from updating/deploying properly ?

When I tried to solve it in part 1, I launched Outlook New from an administrative command prompt, or chose “run as administrator” after elevating myself. However the solution we use for elevation only elevates processes such as cmd.exe or what you click on. It seems that the Webview2 installer, ignores the permissions that Outlook New is launched from.

Eureka

This became clear when I forgot my phone at home, and thus was not able to enter the MFA code to elevate a process in my continued troubleshooting., instead, I used ControlUp to elevate my session.

I then logged off, and logged on to Windows again, and tested my elevation, I was elevated. The difference here is my Windows session was elevated, not just a process.

I then launched Outlook New as administrator, got the Webview2 popup, clicked OK and …. some minutes later, Outlook opened, for the first time in days!

Clearly, Webview2 was now installed. I then launched the Windows app using ‘run as administrator’ and it too, launched, successfully !

Wonderful !

So at this point I’m fairly confident that Webview2 was the problem here, or if both the Windows app and Outlook New for some reason needed the Windows session elevated in order to complete pending Webview2 update actions. I’m also very happy that my Windows app is once again working on my Qualcomm ARM64 laptop !

If you are wondering whether Webview2 is even used for the Windows App, open task manager, search for View and launch the Windows app. Look what appears. I’ve placed red rectangles around three things, Outlook, Windows 365 and MS Teams.

Why the other apps ? during my the last week or so I also had serious lagging issues in Teams, and it too, uses Webview2 as you can clearly see in the image above.

Fixing the Webview2 installer in Outlook (New) via an elevated Windows session solved all my problems in the following apps:

• Outlook (New)
• Teams
• Windows App

Update

I’ve since had the exact same problem occur another 3 times and I’m getting much better at fixing it, especially after reading this. In a nutshell elevate your Windows session (as described above), then delete the following registry key:

HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}

Once done, run the Edge troubleshooter here. This will successfully download and reinstall Webview2 and life will be bearable again, for a while. I’m not sure what app or process breaking my Webview2 but I can tell you this much, it’s very very annoying.

We’re currently testing out Windows 365 in our organization and have noticed some performance issues. Specifically, app deployment on the Cloud PC seems quite slow before or during a user’s first login.

In some cases, it can take up to 45 minutes before the Company Portal and other apps are installed, which doesn’t match the usual Autopilot experience we’re used to.

Has anyone found a trix to pre-load or pre-provision apps on Windows 365 without creating a custom image?

Thanks in advance!

Ever wished you could spin up a Cloud PC not just for your employees, but for contractors, partners, or even external collaborators? Good news—External Identity (preview) support in Entra ID now makes that possible. You can invite external users into your tenant and give them access to Cloud PCs, extending the same secure, managed experience your internal users already enjoy.

Of course, there are a few strings attached. Prior to deploying out Cloud PCs to outside identities, you will need to be aware of a number of significant requirements and limitations so that everything runs smoothly.

In this blog post, myself and my good friend Paul Winstanley took a look at what you need to be aware of and how to set up and access.

Requirements

• The Cloud PC must be running Windows 11 Enterprise with the 2025-09 Cumulative Updates for Windows 11, version 24H2 (KB5065789) or later installed.
• The Cloud PC must be Entra only joined, hybrid is not supported.
• Single-sign on must be enabled in the provisioning policy.
• Connection to the Cloud PC must be via the Windows App or browser.

Limitations

• User based Intune device configurations profiles will not be applied to the external users Cloud PC. Ensure you target the profiles to devices.
• Windows 365 Enterprise, Business, and Frontline are supported, Windows 365 Government is not.
• Cross-cloud users are not supported, i.e. you can’t invite users from Microsoft Azure Government or Microsoft Azure operated by 21Vianet.
• Be aware of the token limitations for external identities – https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection#known-limitations
• Authentication to on-premises resources with Kerberos or NTLM is not supported for external identities.

Assigning the Windows 365 licence

Assigning the licence should be a simple case of heading over to the Microsoft 365 admin center, navigating to Billing | Licenses and selecting the required Windows 365 subscription.

When selected, we clicked Assign licenses and chose the guest user, in our case Niall’s guest account in Paul’s tenant. When finished we clicked Assign licenses.

In our tenant, we received the following error message ‘Failed to assign license for Niall Brady: Cannot process request because a referenced item has an invalid usage location.’ You may not receive this error and not have to perform the fix.

To fix this up for us, we went to the Entra admin center and clicked on Users. We located Niall’s guest account and clicked Edit properties.

Under the Settings menu, we clicked the Usage location drop-down and selected a location for his account, then clicked Save.

After a short period of time, we were able to assign a licence to Niall’s account with no issue.

Provisioning the Cloud PC for the External Identity

Back in the Intune admin center, under Devices | Device onboarding | Windows 365 | All Cloud PCs there should be a Not provisioned Cloud PC. It reports as Not provisioned as the user has not been assigned a provisioning policy.

To resolve this we can either create a provisioning policy and assign this or we can use an existing policy, so long as we have single sign-on enabled and that the Cloud PC is running with 2025-09 Cumulative Updates for Windows 11, version 24H2 (KB5065789) or later. If using an existing policy, take a look at the assignment to ensure that Niall’s account is targeted.

We decided to create a new provisioning policy using the new 25H2 release of Windows 11. We navigated to Devices | Device onboarding | Windows 365 | Provisioning policies in our tenant and clicked Create policy.

As mentioned, ensure Use Microsoft Entra single sign-on is enabled and Microsoft Entra Join is selected for Join type as hybrid is not supported.

We selected the Windows 11 Enterprise + Microsoft 365 Apps 25H2 gallery image to ensure that we met the O/S requirements.

When assigning the policy, we targeted a group called Windows 365 External Identities.

After completing the provisioning policy wizard, the policy was visible.

Next, we simply added Niall’s guest account to the Windows 365 External Identities group. We navigated to Groups and searched for the group and added his account.

Back in All Cloud PCs, a Cloud PC now reported a Status of Provisioning.

After a period of time, the Cloud PC reported as Provisioned.

Accessing the Cloud PC

The Cloud PC can be accessed via the Windows App or web browser, however prior to attempting to access the following registry key needs to be created on the host device.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsApp\Flights

DWORD - EnableIdSignInUx

Value - 0

There are slight variations to accessing via the app or the browser so let’s take a look at both. Also, thanks to our MVP friend Sune Thomsen for providing the details that steered us in the right direction to make this work!

Windows App

The user must be authenticated in the Windows App. They need to click their account profile picture on the top right of the application and click Sign in with another account.

If the registry key has been entered, then the following Sign in window will be displayed. Note Sign-in options is available. This would not be displayed if the registry key is not present. Click Sign-in options.

The next step is to click the Sign in to an organization option.

and enter the domain of the organization hosting the Windows 365 Cloud PC. In our case, sccmsolutions.co.uk.

Now, the guest account must authenticate in the tenant using their account credentials, and respond to any multi-factor authentication or other prompts.

When authentication is complete, the user will be presented with their Cloud PC in the Windows app.

The user is able to switch between organizations by clicking their account profile and selecting accordingly.

Web Browser

When navigating to windows365.microsoft.com, the user will authenticate with their account. Then in the top right hand corner of the web page, the user clicks their profile and then chooses Sign in with another account.

Now, choose Use another account.

The user will then have the Sign-in options available to select (if the reg key is present on the device).

After selecting Sign-in options, choose Sign in to an organization.

As with the Windows App, they enter the domain name of the organization hosting the Windows 365 Cloud PC.

and authenticate with their user account.

Finally, the user will be presented with the provisioned Cloud PC in the web browser.

Using either Windows App or the web browser to log on to the Cloud PC, will allow the guest account access to the device, where previously they would have had to have had an account created in that tenant for them to have a Cloud PC assigned.

As we can see, Niall’s account is accessing CPC-niall-ZMTAD in the sccmsolutions tenant.

This is a hotly awaited addition to Windows 365 Cloud PC features. We look forward to using this feature with our customers. We hope that the registry key requirement is soon removed and is added as part of the installation of the Windows App, as this will help reduce steps required for onboarding for guest accounts.

See you next time.

Introduction

In a previous post we took a look at how you can determine the health of the Windows app and you can read about that here. Please read it to understand the new feature and why this blog post improves things from an admin perspective.

In this blog post myself and my good friend Paul Winstanley took a look at yet another Windows 365 related ability and that is an Intune remediation solution called Windows App Health Check Log Reader.

Note: This remediation solution is not supported by Microsoft.

If your Windows app detects a health issue it’s logged in the following log file:

C\Users\<USERNAME>\AppData\Local\Temp\DiagOutputDir\Windows365\logs\health_checks.log

But that log file is on the device hosting the Windows app used to connect to your Windows 365 Cloud PC’s and that requires remote access by an admin or some other way of grabbing the log to determine the issue.

In this blog post we take a look at a remedition solution which does just that, it looks at  Windows devices that you target, determines if they have the Windows app installed and if that app matches a minimum version (needed for health checks), parses the health_checks.log file to see if there were any recent errors reported.

If so, based on the cadence you select, it will copy that log to the root of your Intune logs folder, which is located at the following path:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Doing this allows you to grab the logs via the Intune console collect diagnostics ability. So let’s take a look at how it works.

Get the scripts

Head over to Github and download the 2 scripts here. They’ve changed a bit lately based on feedback we submitted, so do check regularly for updates.

Once you’ve downloaded the scripts, extract them somewhere useful.

Create the remediation

In Microsoft Intune, create a remediation solution using these 2 scripts.

On the Settings page, point it to the 2 scripts as appropriate.

Once done, assign it to some devices that you want to monitor the health of the Windows app on, we used an Entra Id group containing some devices with and without the Windows app installed and we set a cadence of every hour to see the results quickly, however in production you’ll probably want to set that to run once a day.

Analyzing the results

After the remediation has run for some time, you can analyze the data it created by clicking on Device status in the remediation.

In here we can see that most devices are without issues (good) but one device reports a detection status of With issues and it has recurred.

Back in the Intune console, locate the device highlighted with issues, and click on the Collect diagnostics button.

answer Yes when prompted.

After some time those log files will be captured and you’ll see the status has changed.

Click on Device diagnostics to download those files, by clicking the three dots and then selecting download.

Within the extracted ZIP file, locate the (67) FoldersFiles ProgramData_Microsoft_IntuneManagementExtension_Logs folder and you’ll see the health_checks.log file.

Open that file in CMTrace to review the issue.

That’s a result!

With this new remediation solution, you (as an Intune admin) can automate the copying of the health_checks.log file to a location that is easy to remotely grab without needing to bother the end user or use remote access to their PC.

Awesome.

see you in the next one !

Microsoft has just pushed out yet another new feature for Windows 365 and Azure Virtual Desktop environments which is called health checks. Myself and my good friend Paul Winstanley took a look at the new feature and wanted to share our thoughts with you.

We looked at the new functionality of the Windows app on Windows devices but this new feature is available via the Windows app on the following platforms:

• Windows: version 2.0.703.0 or later
• macOS: version 11.1.8 or later
• iOS: version 11.1.7 or later
• Android: version 11.0.0.46 or later

What are health checks ?

Good question. Think of it as a way for the Windows app to carry out a series of checks to verify that everything is in place to ensure that you have a consistently good connection to your Cloud PC and if something is not right, to report that there’s a problem to you via the app and via logs.

These checks happen if it detects a network change, or can be triggered manually by the end user or automatically when the Windows App itself starts or when the user makes a connection to a resource such as a Cloud PC or Cloud App.

Let’s take a look

In the current version of the Windows app (2.0.704.0 at the time of writing), the health checks ability has been added. Please note that it is gradually rolling out to all regions, so if you have updated your Windows app and still don’t see the health symbol, don’t panic, it’s on its way.

To verify which version of Windows app you are running see here.

Before the feature rolls out your Windows app will look something like this.

After the health check feature is enabled for your region, the Windows app will appear something like this, notice the new heart shaped icon on the left menu highlighted with a green arrow.

Clicking it, brings up some information on the right side of the Windows app detailing the health of your connection.

In there you can see the computer name, and what it determines to be the state of the system, the date and time of the check and the result of the check, in this case Everything looks good.

You can also manually check the health by clicking Check again which will kick off the health checks, or click on Open log to see a log file containing what it has checked and the results of that check.

Below is what the log file content looks like when everything is OK.

The health_checks.log file location on Windows devices is:

C\Users\<USERNAME>\AppData\Local\Temp\DiagOutputDir\Windows365\logs\health_checks.log

You can also click on See all health checks to expand a list of what is checked.

that’s all fine when everything is working, but what about when you have an actual problem ?

Detecting network issues

If something is detected to be not working, such as a failure to reach a required endpoint, then the Windows app will alert you with a banner, and the Health Check icon will have a red dot to signify something is wrong. These changes to the Windows App appearance happen if a network change is detected.

Clicking on the health check icon itself, or clicking the Check device health warning button will allow you to check and reveal what the problem is.

At this point you have many options.

• Check again
• Open log
• See all health checks
• Open network settings

Clicking on See all health checks in this example reveals that the network connection is disconnected.

And as mentioned above, that was detected when a network change was detected, as is revealed in the log file by clicking on Open log.

Clicking on Check again in this failed state reveals (in the log) that this was a user initiated check.

After you’ve sourced the root of the problem (in this case the router was turned off to simulate a network failure), and resolved it, the log reveals that there was another network change, and this time all is good.

So there you have it, automated and manual health checks are now possible using the new feature in the Windows app.

More info

You can get more info about the new feature from Microsoft below:

• Run health checks to detect issues with Windows App connections – Windows App | Microsoft Learn
• https://techcommunity.microsoft.com/blog/windows-itpro-blog/enhancing-azure-virtual-desktop-and-windows-365-experience-with-health-checks/4446612

Summary

The new health checks feature is a very welcome addition to the Windows app, as more and more companies have complex environments that contains proxies, ssl inspection, network sniffers that can interuppt or block the necessary traffic routes.

The health check feature highlights when there is a problem with one or more of these endpoints, and alerts the end user with a popup. The admin in their turn can utilize the health check log to get more info about exactly what is failing.

Thanks Microsoft for the feature and in particular thanks to the very helpful PM, Pavithra Thiruvengadam.

Introduction

A new feature for Windows 365, and now in preview, is Windows 365 Cloud Apps. Instead of giving users a full remote desktop session, Windows 365 Cloud Apps are published as individual applications that run on a Cloud PC but look and behave like they are installed locally on the device. If you are familiar with Remote Apps, first introduced in Windows Server 2008 as part of Remote Desktop Services, then you will have an understand of how these operate. When Windows 365 Cloud Apps are published, you will be able to load up that individual application and if any interaction with another application is required, then that application will also fire up, even if it has not been published to the user.

Note that Windows 365 Cloud Apps are only available to you with a Windows 365 Frontline subscription.

myself and my good friend Paul Winstanley sat down to test run this new Windows 365 feature. It is nice and simple to set up so follow along.

Create the Windows 365 Cloud Apps Provisioning Policy

The first step is to create a provisioning policy for the Windows 365 Cloud Apps. This is done in the usual place for Windows 365 provisioning Devices | Device onboarding | Windows 365 | Provisioning Policies | Create Policy.

You will notice a new Experience section in the policy wizard, here you will need to select Access only apps which run on a Cloud PC (preview) as the selection defaults to Access a full Cloud PC desktop. When you select the Access only apps which run on a Cloud PC (preview) option, Frontline will be automatically selected for License type and Frontline type will be Shared. All other options are greyed out as they are not applicable to Windows 365 Cloud Apps as mentioned earlier.

Enter any other relevant information for join type, geography, region and SSO before proceeding through the wizard.

The selection of the Image type is crucial for Windows 365 Cloud Apps as the solution will make available any discoverable applications in the devices’ start menu (Appx and MSIX are currently not supported discoverable app type – therefore Teams is not available at this stage). You can import a custom image to take advantage of other applications which are not included in the Microsoft Gallery images.

Clicking the View link for Apps available on the image will display a list of the Cloud Apps that will be available to you when the device is provisioned.

When assigning the policy, you will need to select the Frontline Cloud PC size from your Available Cloud PC’s drop down and create an Assignment name and choose the Number of Cloud PC’s, this number will reflect the number of licenses that you have available to use.

After creating your policy, the Frontline Shared device, which will host the Cloud Apps will being provisioning. You can view this under All Cloud PCs.

Give the device some time to provision and once completed it will report as such.

Publishing some Cloud Apps

Whilst clicking though the menu system, you may have noticed a new All Cloud Apps option, this is where we need to go to publish the discovered apps, making them available to the assigned users.

We can see that 32 items were discovered from the image we selected and their App status is currently set to Ready to publish.

Simply select the apps you want to publish and click Publish.

Confirm your choice to Publish the apps.

The App status will change to Publishing.

and will, very quickly, become Published.

You now have the option to Unpublish apps. The process is identical. Select apps you want to remove and click Unpublish.

Confirm to remove them.

The App status will revert to Ready to publish.

How to access the Windows 365 Cloud Apps

Windows App is the place to go to access your Windows 365 Cloud Apps. Prior to publishing apps to the users, the application will display any device based Cloud PCs the user has access to.

With apps assigned a new option Apps appears. Look out for it as it’s a subtle addition and you could miss it initially.

Clicking on Apps will display the published apps that you have made available.

You can make an app a Favorite by clicking the ellipses.

When launching an app a RemoteApp connection to the Frontline device will initiate and you may be prompted to authenticate along the way.

and Allow remote desktop connection, depending on policies assigned to you.

If this is the first time connecting to the Cloud App, it will take a little long to load up. You can click Configuring remote session to see that Windows is being prepared.

You can identify the Cloud App from the icon on the Windows task bar, there is a Windows App logo on the top right hand corner of the icon.

Once launched, you will feel as it the application is running on locally on your device. Pretty cool!

Things to note

• To remove Cloud Apps from the All Cloud Apps view, you will need to delete the assignment of the provisioning policy.
• Since Cloud Apps run as Frontline Shared, the management of them is identical to management of a Frontline Shared Cloud PC, so be aware of any max connection limitations due to licencing.
• You can utilise policies assigned to Frontline devices, such as redirection. These will apply to Cloud Apps.
• When using a custom image, Windows 365 Cloud Apps will use a PowerShell script to scan the Start Menu for apps, so ensure that your tenant policies do not require extra authentication for PowerShell scripts to achieve this.
• Currently only apps discovered in the Start Menu are available. Microsoft are developing the ability to publish apps that are installed by Intune and are included in the Autopilot Device Preparation Policy associated with the Cloud App provisioning policy.

We hope this blog post gives you a tester of this great new feaure.

Introduction

Microsoft pushed out some new updates for Windows 365 Cloud PC’s recently and one that we thought was interesting was this one, the ability to recover a Cloud PC that was de-provisioned due to license expiration.

The de-provisioning of a Cloud PC normally means that it is unusable and unrecoverable, it’s a destructive action. However, with this new feature and as long as you have previously enabled Point-in-Time-restore explained here then you should be covered by this new ability (for Windows 365 Cloud PC Enterprise only).

In this blog post myself and my good friend Paul look at the new feature and test it out. We’ll be collaborating on more Windows 365 and Azure Virtual Desktop content during the year so stay tuned on the SCCMentor and windowsnoob websites!

The prerequisites

Before we test it, let’s look at what you need to have in place.

• To recover a previously de-provisioned Cloud PC, ensure that the expired Windows 365 licenses are renewed. The replacement licenses must be of the same SKU, so if the previous Cloud PC’s were Cloud PC Enterprise 2vCPU/8GB/128GB then the replacement license assigned must be for Cloud PC Enterprise 2vCPU/8GB/128GB.
• To recover a previously de-provisioned Cloud PC, ensure that the provisioning policy of the de-provisioned Cloud PC still exists.
• To recover a previously de-provisioned Cloud PC, ensure that assignments with the right users are assigned to the provisioning policy.
• To recover a previously de-provisioned Cloud PC, ensure the end users still exists, and are still assigned to the same Entra ID groups as before or the ones included in the policy assignments.

Testing the new feature

Ok now that’s all clear, let’s test it out. Before starting, we verified that our test Cloud PC had a point-in-time restore policy (User settings) applied.

We also made sure to place a file on the Cloud PC outside of Onedrive known folders.

And before continuing, we verified that there was at least one backup for this Cloud PC, and there were several.

Note: If you are also testing this feature and you are doing it on a newly provisioned Cloud PC, you can click on Create restore point to create a manual restore point.

As simulating a license expiry and then re-purchasing the same license is easier said than done we’ll simulate it by deleting a user that was assigned the following Cloud PC SKU: Cloud PC Enterprise 2vCPU/8GB/128GB. Below you can see that user (testuser100@windowsnoob.com) and their respective Cloud PC.

Next, we deleted our licensed user.

and were notified of that…

Shortly after, the status of the Cloud PC that that user was using, changed from Provisioned to In-grace period.

Clicking that In-grace period status and selecting Deprovision now, speeds up the testing process.

Which kick starts de-provisioning

Some time later, the Cloud PC was no longer in the Intune console and was no longer available to the (now deleted) end user to use.

At this point, the de-provisioning process was completed.

Recovering de-provisioned Cloud PCs

In the real world, to see this new feature you’d renew an expired license and make sure that the user/group/policy and so on didn’t change during that time period.  But we are simulating that, so to simulate it we’ll restore the user we deleted earlier, again, nothing else has changed other than that users Cloud PC’s went from in-grace period to de-provisioned.

So let’s restore the deleted user. In Azure (Entra Id) select users, click Deleted users and locate your deleted user. Select the user and click Restore users.

You’ll be notified of the restore.

And as the user was still in the same groups, they’ll pick up the Cloud PC assignments targeting them and a new Cloud PC matching the SKU in question will be provisioned.

After the Cloud PC is provisioned, you’ll see it appear with a new computer name.

We need to do some final actions. Select the newly provisioned Cloud PC and click the Restore option.

This will show a retention restore point.

Select it and click the Select option to restore that de-provisioned Cloud PC.

You’ll get a popup warning you about the restore.

Click Restore and the restore will be initiated, you’ll see the status change to Restore pending.

And during the restore the status will then change to Restore active.

and after a while refreshing that device will reveal a ‘Not found‘ statement (sorry no screenshot, we’ll add it shortly). However, if you navigate back to Windows 365 devices, you’ll see that the old name (old Cloud PC) is back !

and logging on to that Cloud PC using the same user will indeed reveal that the content is as expected.

Job done!

Read more

• To learn more about this new feature see Microsoft’s own page here.
• To learn how to use Point-in-time-restore read here.

Introduction

Microsoft recently released a new feature for Windows 365 Cloud PC’s namely the ability to move one or more Cloud PCs to another region. This involves editing a previously created provisioning policy and then deciding whether you want to move all Cloud PC’s or only a subset targeted by that policy. All data/settings etc on the device (except for stored snapshots) will be retained with the move, which is great from an end user perspective.

Microsoft themselves recommends testing this on a few Cloud PCs to review how the end to end process works for your users’ Cloud PCs.

Why change location ?

But first of all, why would we want to change the location of a Cloud PC ? Changing the location of a Windows 365 Cloud PC can be beneficial for several reasons:

• Improved Performance: Moving the Cloud PC to a location closer to the user can reduce latency and improve overall performance, making applications and services more responsive.
• Compliance and Data Sovereignty: Different regions have varying regulations regarding data storage and processing. Moving the Cloud PC to a location that complies with local laws can ensure adherence to data sovereignty requirements.
• Cost Optimization: Some regions may offer lower costs for cloud services. By relocating the Cloud PC to a more cost-effective region, businesses can reduce their operational expenses.
• Disaster Recovery and Redundancy: Relocating the Cloud PC to a different region can enhance disaster recovery plans by ensuring redundancy and availability in case of regional outages or disasters.
• User Experience: If a business has employees in different geographical locations, moving the Cloud PC closer to the majority of users can enhance their experience by providing faster access to resources.
• Scalability: Certain regions may offer better scalability options or more advanced infrastructure, allowing businesses to expand their operations more efficiently.
• Security: Some regions may have more robust security measures or offer specific compliance certifications that are important for certain industries.

So let’s dig in and see how this works in reality.

Moving one or more Cloud PC’s

In the Intune console, locate the Windows 365 node and select Provisioning policies.

Select the target provisioning policy, and click it to edit it. the policy details are revealed. Take note of the current location configured within the policy, this is optional but useful to know if you want to revert to that location later on.

Review location before change

At this point, pick a test Cloud PC to allow you to review that the move process goes smoothly.

On that Cloud PC, verify the current location using a site such as https://www.whatismyipaddress.com or https://mylocation.org/. Below you can see the approximate location of our test Cloud PC before any move is attempted.

As we can see it’s listed in Iowa, in the United States.

1. Inform the users

Now that we know which provisioning policy we’ll be editing, and what location our target Cloud PC’s reside in, we need to pick one or more users of those Cloud PC’s and inform them of what is about to happen (and why).

You need to explain to the users that they must save any open documents, close their apps and to sign out of their Cloud PC for the weekend. It’s a good idea to do the move over the weekend as obviously some Cloud PC’s will have more data/apps/settings to move than others.

2. Edit the policy

In the General section of the provisioning policy, click Edit and modify the Geography. I chose European Union as that’s where I want to move my target Cloud PC’s. You can fine tune the region and select an actual region such as Sweden, but it’s recommended to choose the Automatic (Recommended) option to avoid provisioning failure. For a list of supported regions see here.

As this is an actual move and not a provisioning, I chose Sweden.

after editing the policy, click Next followed by Update.

3. Pick one or more target Cloud PC’s

Now that you’ve changed the Geography and Region of your provisioning policy, click Apply this configuration to select one or more target Cloud PC’s.

To select one or more devices, click the third option which is Region or Azure network connection for select devices and click Apply.

That will bring up a list of devices to select. Select one or more targets and place a check in the Cloud PC’s will be disconnected and shutdown while the configuration is updating. Any unsaved work may be lost message.

Note that the disconnect only affects selected devices, not all targeted by this provisioning policy.

4. Review the Cloud PC’s status

The status of the selected Cloud PC’s will change to Moving region or network in the All Cloud PC’s section of the Windows 365 node.

Individual Cloud PC’s will also show new status in Intune devices via the Overview and Device action status areas of each device.

Also to note, the above statuses will have changed even before the move of the actual target takes place, so the Cloud PC may still be online for a brief period before it receives the instructions to shutdown.

You can also monitor the status using the Cloud PC actions report.

which reveals some more data for individual Cloud PC’s

plus, if you selected multiple Cloud PC’s, click on Bulk batches.

After some time, the status should update on the device to Completed

and the Cloud PC actions report will be updated with the new status.

And on the target PC itself, you can verify it’s location using the previously mentioned sites to confirm the new location.

Job done!

Final thoughts

Keep in mind that after you’ve completed your Cloud PC move operations, that any new Cloud PC’s targeted by that provisioning policy will also be provisioned in the new region. This new ability is great, and I’ve tested it successfully in multiple tenants.

I do however feel that with just a little bit more work it could be even better. What I’d like to see is native ability within Intune to send customizable emails/alerts/notification for any Cloud PC’s targeted by the move operation, both before and after the event to alert the end users about what is happening and when, and more importantly to let them know that operations are complete.

Great job Microsoft!

Introduction

I use my Windows app daily from a variety of devices to access my Cloud PC’s. Today like any day I clicked the Windows app icon but this time, nothing happened, the familiar Windows app did not appear.

So I clicked it again and this time it did appear but was blank.

Note: This problem occurred only on my ARM64 device, the Windows app worked just fine on other X64 devices.

As you can see in the screenshot above, it’s completely blank, empty of any content, so it’s impossible to use.

Trying to fix it

I thought the app somehow became corrupt, so I tried to reset & repair the app.

Neither of these options helped.

Next, I tried to end the processes for the Windows in task manager.

And killed the Windows365.exe process tree…

but these didn’t help either. The app simply refused to display it’s content.

While troubleshooting I noticed a Windows cumulative update was ready to install, you can see it below with the blank Windows app in-front.

so I let Windows update do it’s thing and manually restarted the computer.

It didn’t help.

What about the logs ?

Next I looked at the logs connected to the Windows app in %temp%\DiagOutputDir\Windows365\Logs as documented here.

The logs (4 in total) did not give me anything to go on other than to highlight that I did have a problem. The most interesting log snippet was this”

[2025-03-21 12:53:49.547] [async_logger] [error] [MSAL:0003] ERROR ErrorInternalImpl:134 Created an error: 8xg43, StatusInternal::InteractionRequired, InternalEvent::None, Error Code 0, Context ‘Could not find an account. Both local account ID and legacy MacOS user ID are not present’

but I saw that was repeated even when my Windows app was working, so I chose to ignore it.

So what else could I do at this point ? uninstall the app.

I then reinstalled the app from the store.

end result, same problem!

At this point I reverted back to the logs, and found this section, it reminded me of an error I saw this week when launching Outlook (New).

The Outlook (New) webview2 error is also shown on top of the log file below:

I never bothered to install that Webview2 component as it requires local administrative permissions to do so and I’m a standard user (as I should be).  So I elevated my session and tried clicking ok to the Outlook (New) message. That didn’t help, it just kept looping through a prompt asking me to install the new Webview2.

A google search led me to this post, and I downloaded the Webview2 client (for ARM64) from here. After deleting the reg key and installing the Webview2 update & restarting the computer I still had the issue with Outlook New prompting to install Webview2 and my Windows app not working.

Next up I checked the version of Windows app I was running and it was the latest, 2.0.365.0(ok there’s a insider preview version that’s newer but… I don’t think that’ll help).

At this point I’m out of ideas and will inform the Microsoft Group in charge of Windows 365 to see what they have to say about it, I’ll revert in part 2 once this is hopefully solved

cheers

niall