Monitoring is an important part of all IT operations, and knowing when something fails is crucial. Also knowing before end-users starts calling is even better!
Microsoft has released a new feature in Microsoft Endpoint Manager admin center (MEM) which could help with this called Alerts, which is currently in public preview for Windows 365 features.
With Alerts you can setup notifications, both in the MEM admin center but also through email. This would allow you to get the information and take action as soon as something happens.
There are today three types of alerts you can configure:
Azure network connection failure
Upload failure for custom images
Provisioning failure impacting Cloud PCs
Set up your alerts
Setting up your alerts are really simple. Start by browsing to the Microsoft Endpoint Manager admin center (https://endpoint.microsoft.com).
Then navigate to Tenant Administration > Alerts (Preview) > Alert rules. This is where you will see available alerts, configure and enable them.
Click the alert rule you want to configure, in this case we will configure the “Provisioning failure impacting Cloud PCs” alert.
You have three sections to configure: Conditions, Settings and, Notifications.
Under Conditions you can specify how many events need to happen before an alert is triggered. For this alert we can either choose a number of Cloud PCs or a percentage of Cloud PC needs to fail before we get an alert. I would consider the suggested setting in this case to be good, since I want to know if one or more Cloud PCs fail.
Next part is Settings where we need to select the severity of the alert and the status of the alert. Microsofts recomendation is to clasify this as critical, which sounds like a good setting and we will set the status to On since we want to enable this alert.
Last and final part is the notifications, if you want to get a notification in the portal and by email. By enabling “Portal pop-up” a notification will show up in the portal if a provisioning fails.
The email part is for where an email notification should be sent. You can add multiple recipients, and I’ve added my Service Desk email adress in this instance, since I want them to get the information. This could also be set to an administrator or the operations team for Cloud PCs, that totally up to you!
After doing all our settings, click “Apply” at the bottom of the screen and your rule will be enabled.
You can at any time easily turn on or off an alert rule by checking the check-box next to it and use the “On” and “Off” buttons.
And now you just need to sit and wait for the alerts to hopefully never show up!
Since making the Cloud PC provisioning isn’t something I’ve figured out how to do on command, I’m not able to do on command I don’t have any screenshots of the alerts.
If you want to see some screen shots of this, I suggest you head over to my fellow MVP Morten Pedholts blog, who actually got a machine to fail in provisioning.
Final thoughts
Alerts in MEM has great potential, and I can really see this expanding going forward to other things than just Windows 365 and the three alerts we are limited to today. Really looking forward to see how this feature will evolve!
Here is something I learned the hard way in my own tenant. Windows 365 kind of messes with your account security if you are consuming Microsoft 365 services from another device than your cloud PC. Especially if you live in a country like Sweden where the Windows 365 service is yet not available in Sweden Central. Further more, it seams to only affect you the first few times you sign in, before the algorithms learn your behavior.
What happened to me was that Identity Protection and user risk blocked me out from my Cloud PC, since I had defined it to block if user risk was too high and not password change.
It took me a while to just realize what had happened, and how to get around it (since Identity Protection is not an area I’m to familiar with).
Why is that?
Well, there is something called “Impossible travel” or atypical travel which is used to assess the risk of your account being compromised, which means that it’s very unlikely that you would travel from let’s say Stockholm to Amsterdam within a few seconds. This is a very good thing to have in place since it will increase the security of your accounts a lot!
This feature is a part of the Identity Protection part of the Azure AD (which requires a Azure AD P2 license), and can help you identify and take action on risky sign-ins performed by users, or detect if their credentials has been stolen.
There are two key parts of this, Sign-in risk and User risk, and you can control what happens if a user does not live up to the expected level. And of course, Multifactor Authentication (MFA), plays a key role.
Conclusion
I’m not going to dig deep into this at all, just sharing an observation basically. If you want to read more about Identity Protection, I really recommend you having a look at the Microsoft Learn documentation, it provides a good overview.
Like I stated in the beginning of my post, this was something I noticed in my lab, but I’ve not seen it in the wild so far in any production environment. For my environment, I solved it by dismissing the risk for my user which eventually allowed me to sign in.
I’ve spent a good amount of time trying to reproduce this sign-in block, but I haven’t been able to yet.
Some of you might have seen something called Microsoft Dev Box flash by in your feeds. Something called Dev Box doesn’t really sound like something device-related, it sounds more like something your developers would care about. They probably will, but there is a big reason you should care too.
Microsoft Dev Box is a new tool in the toolbox for you, this time to provide Cloud PCs to your developers or such. There are many similarities between Dev Box and Windows 365, but also Azure Virtual Desktop (AVD). However, your developers can themself deploy computers to your tenant based on a template that you create, which means that a developer could create a new test PC when they need one without really involving you as an admin.
Microsoft Dev Box is not licensed-based like your Windows 365 Cloud PC, instead, it’s consumption-based like an AVD. But you have the simplicity of setting up new computers from Windows 365, so it’s almost like a mix of the two. However, the user target group is different since you can get more powerful machines that are deployed by the user themself.
You can read more about the Microsoft Dev Box here, and what Microsoft calls a “Dev Workstation in the cloud”.
Getting started with Microsoft Dev Box
To get started with Microsoft Dev Box you need the following:
An Azure subscription
Azure AD
Intune tenant
Windows licenses (typically as part of your EMS or M365 license)
Setting up the Microsoft Dev box is completely taken care of in the Azure portal, not the Microsoft Endpoint Manager admin center.
To start off, you need to head over to portal.azure.com and make sure you have an active Azure subscription to provision this. Then, search for Microsoft Dev Box.
This is where your different environments will be hosted. You can have multiple Dev Boxes set up for different parts of the organization. In each Dev Box, you can also create different projects. In the real world, you would probably configure this in a landing zone specifically set up for your dev-users who will work on certain projects.
The first step is to create a new Dev-center by pressing “+ Create” in the Microsoft Dev Box pane. Select what subscription and resource group you want to deploy this too and give your Dev-center a name. You will also need to select an Azure region where your machines will be hosted. Since this is a preview, the selection of what Azure data center regions are available is limited. Once you have selected this, press “Review + Create” and create your Dev-center.
Once the Dev-center has successfully deployed, you need to create a Network Connection where you define if your Dev Box PCs should be hybrid-joined or Azure AD joined. Head back to the Microsoft Dev Box pane and select Network Connections (or search Azure for Network Connections).
Select “+ Create” to create a new Network Connection by selecting what subscription and resource group to use. Also, give the network connection a name and select what Azure Vnet you would like to use (if you haven’t created a Vnet already, you will need to do that first). Press “Review + Create” and create your Network Connection.
In this example I’m using Azure AD joined devices as selected as “Domain join type”. If you want to use Hybrid join instead, you will need to add some additional information about your domain.
Once you have created your Network Connection, you will need to create a project. This is where gather each project you would like to use the Dev Box PCs in and define what machines are available by creating Dev Box pools. In the Microsoft Dev Box pane, select Projects.
To create a new Project, click “+ Create” and select what subscription and resource group you want to use. Select which Dev-center you would to use and give your project a name. Press “Review + Create” and create your Project.
Now we need to define what machines are available for our users by creating a Dev box pool. There are a few different “sizes” available, and you can read more about them on Microsoft site about Microsoft Dev Box, where you can find out the pricing for each.
To create a new Dev box definition, navigate to the project you created earlier and select Dev box definition on the bottom of the left-hand menu.
To create a new Dev box definition, select “+ Create“. Give your definition a name and then select a Windows image to use, in this example we will use a Microsoft-provided image, but you could upload your own if you would like. Make the appropriate selections of what size you would like on the machine and click “Create”.
The next step is to create a Dev box pool in your project, do this by navigating to your project you created earlier and selecting Dev box pool.
Create a new Dev box pool by pressing “+ Create” and giving your new pool a name. Select the Dev box definition created earlier and also the network connection. You will also need to confirm that your organization has Azure Hybrid Benefit, you can read more about what that means here.
Once you have filled out this, create the dev box pool by clicking “Create” at the bottom of the page.
The last thing we need to do is to assign users the rights to consume machines and work in our project. Prior to this, it’s a good idea to create an Azure AD group that will contain our users.
To configure the access to our project we will head into “Access control (IAM)” in our project.
To add a new assignment, click “+Add” and select “Add role assignment”. In the list of roles, find and select the “DevCenter Dev Box User” role and press next.
On the next page, add your Azure AD group which contains the users who should have access to the project. Once you have added this group to “Members” press “Review + assign” to finalize your role assignment.
You can verify that the assignment was successful by looking in the list for the role and validating that your group is listed.
And that’s it! You have now successfully prepared your environment to use Microsoft Dev Box!
User experience
For users to create new Microsoft Dev Box machines, they will need to access devbox.microsoft.com and sign in with their user account.
Once signed in, the experience is similar to the Windows 365 end-user portal, but there is a new button called “+New Dev box” where users can deploy machines themself.
Once you click that button, a fly-out will appear where you can see the specification on the machine you are allowed to deploy (based on the definition we made earlier) and you are asked to give your machine a name. Once you have given the machine a name, which will be the name displayed to you for your convenience (MEM will show a CPC-xxxxx name), press “Create“.
The creation of a machine will take somewhere around 30-90 minutes. Once the machine is done, it will show in the portal where you are right now but also in the Remote Desktop app where you have all your other Windows 365 machines. A bonus fact is that it will also appear in the Windows 365 portal, marked as Dev box, but you cannot create new machines from there.
Once the machine has been created, you can connect to it and start using it!
One thing you will notice if you are deploying Cloud PCs is that the Enrollment Status Page (ESP) from Windows Autopilot will or might appear when a machine is being set up. I’ve seen numerous instances where the ESP has failed causing the Cloud PC to lock out the user at the initial start. This is usually fixed by reprovisioning, but an unnecessary call to the service desk can cause frustration with your users and your administrators.
The ESP is not an important part of the Windows 365 provisioning in most cases, hence it can be disabled by a custom policy.
Create the policy
To create a custom configuration policy, go to the Microsoft Endpoint Manager admin center (endpoint.microsoft.com) and navigate to Devices > Windows > Configurations Profiles.
Select to create a new profile and select Custom as template.
Give your profile a name based on your naming convention and press Next.
Select to target All devices, but filtered to only target Windows 365 devices. You can read more about how to do that in this blog post about filters.
Finish the wizard by clicking Next until you reach the last step, then click Create.
You have now successfully created a configuration profile that will skip the ESP for all your Cloud PCs.
Summary
The ESP is something that in Windows Autopilot is very useful, but for Windows 365 it’s not crucial. This will also reduce the risk of random errors during provisioning.
Applications that are needed before the user starts working can be assigned using the assignments to “All Devices” and filter out your Cloud PCs since this will evaluate a lot faster than Azure AD groups.
Securing the access to Windows 365 could is important. Today, MFA something everyone should use and you should definitely use it to access your Cloud PCs!
Given that you have Azure AD Premium P1 or P2 (it’s included in at least the Enterprise SKU of M365), you are able to use Conditional Access (CA) to enforce MFA. It’s a great idea to always require MFA for all cloud services.
Windows 365 is like you might have guessed a cloud service, which will in that case get the MFA requirement.
But what if you want to add other conditions that are specific to Windows 365 and Cloud PCs? Making sure that these are only accessed from e.g. your managed devices. There are some caveats to this however what I’ve noticed, like for example if you have added the Cloud PC to the Remote Desktop app it will only evaluate the CA rules when adding the account, but if you are using the browser the policy hits each time.
If you set up the CA rules prior to getting your users going however, you will be able to control this in a much better way.
Creating the policy
To create the Conditional Access policy, you must first of have the correct role to do so (e.g. Security Administrator, Conditional Access Administrator, or Global Administrator).
Next up, in Microsoft Endpoint Manager, navigate to Devices > Conditional Access and press “+ New Policy”.
Start by giving your new policy a name.
Next step is to select what users to include in this CA rule. In this example I’m assigning this to all users.
We now have to select what cloud apps are included in this CA rule by going to “Cloud apps or actions”.
Choose “Selected apps” as included, search and add “Windows 365” and “Azure Virtual Desktop” to make sure that your rules applies to all your cloud PCs.
Once you have selected the apps, go to Conditions.
Here we will add Any Device under “Device platforms”.
And also Browser and Mobile apps and desktop clients under “Client apps”.
Once you have added these, move further to Grant under Access control and add your requirements for granting access.
In this example, I’m only allowing compliant devices to sign in to the service, which means devices which are marked as compliant in Microsoft Endpoint Manager, which means that they are managed and healthy devices. You can also add additional requirements here and have it set to require to fulfill only one of the requirements, e.g. complaint OR require MFA. You can of course also set it to require both being compliant AND require MFA, this is controlled under the “For multiple controls” section. In this case, I’ve left it to it’s default value.
Once you have added all your settings, make sure to set the “Enable policy” switch to ON instead of “Report-only” to activate the policy. However, be aware that you could potentially look your self out by doing a faulty CA rule.
Click create at the bottom of the screen and your policy will take effect within minutes!
The experience
So what happens when this Conditional Access rule hits?
For the Remote Desktop app, it will only take affect when adding a new account. So if you already have an account added, nothing will really happen.
But when you try to add a new account, it will not grant you access unless you meet the requirements set in the policy.
For the browser, when accessing your Cloud PC through the Windows 365 portal (https://windows365.microsoft.com) you will also be met by a message not granting you access. This message is however a bit more cryptic and doesn’t really tell you what’s wrong. But
Conclusion
That is a quick guide how to get started with controlling the access to your Cloud PCs using Conditional Access. You could do a lot of cool stuff with this based on your scenarios and needs. You could also throw some session control into this or only granting specific user roles access to this combined with a few more policies to create a cloud based Privileged Access Workstation (PAW).
You could also compliment the policy with a session control to control how often it needs to be re-evaluated.
This configuration I didn’t doesn’t really support the “work from any device” concept, but I just wanted to show what was possible!
It has finally arrived, and while writing this we are hopefully getting close to a general availability release. I’m talking about the Azure AD joined Windows 365 machines!
This is something that makes this solution a truly cloud-based solution since we can now let go of the on-premises AD for the device part (let’s face it, we still have our users in there in the real world).
However, there are still use cases for both scenarios, depending on what your want’s and need’s are! So there is a decision to make here, and it might be that you need both!
The difference
Let’s start of by briefly looking at what the difference between Azure AD joined and hybrid joined is, and I’ll simply A LOT now.
Having a Azure AD joined computer means that the device is only registered to the Azure AD, which is your cloud AD so to speak. This AD is a lot different than your traditional AD since you are missing things like OUs and GPOs for example. The cloud relies on a flatter and different approach to handling objects and settings. I’ve once gotten Azure AD explained to me once as one big AD forest where each tenant is an OU, just to put it in perspective. Joining a computer only to Azure AD also means that there will be NO trace of the computer object in the on-premise AD, hence we cannot use the computer object to authenticate towards things but you can still use e.g. Kerberos for SSO.
If you join your computer to the Azure AD you would typically manage it from Microsoft Intune.
Having a Hybrid Azure AD joined computer means that we join the computer to both the on-premise AD and the Azure AD. One could say you get the best out of both worlds. That is to some extent true, but you are still very reliant on your computer talking to a domain controller to get policy updates, since you would in many case manage these computers with GPOs.
Hybrid Azure AD joined devices are typically co-managed by Configuration Manager and Microsoft Intune. But you can of course manage them using only Microsoft Intune as well.
With that said, it comes down to your tools and needs in what approach is best for your Cloud PC.
Advantages hybrid Azure AD joined Cloud PC
So one of the biggest advantage with hybrid Azure AD joined Cloud PCs are that you know this already and most likely this is how you manage your physical PCs today. You have them hybrid joined, manage them with some GPOs, maybe some Intune policies and you also add some Config Manager stuff on top. Nothing strange here, this is just another computer but is virtual. You still need the Microsoft Endpoint Manager admin center to configure your Cloud PC provisioning, but the rest is like you know by heart. A setup you know, love, and trust!
Using hybrid join is also great for those applications requiring a computer object to be present in the AD for authentication or such. Or it could just be as simple that you need “system” to be able to access a file share. Then this is perfect!
Hybrid joined Cloud PCs are no different from your regular PCs in that sense, they are just physically in the Microsoft datacenter.
BUT by using hybrid joined Cloud PCs you still have great dependency towards your on-premise infrastructure.
Advantages Azure AD joined Cloud PC
The benefits with the Azure AD joined Cloud PC can be argued to be the exact opposites as the hybrid join. No GPOs, no ConfigMgr, no hybrid. No legacy stuff. Just cloud.
However, I would say that that’s not where the strength lies with Azure AD joined Cloud PC. The strength that I’ve seen when you combine this with thinking about where these computers should be hosted. With Azure AD joined you can either host them on a Azure VNet you manage, or you can choose to use the Microsoft managed VNet which is basically on internet.
Hybrid joined Cloud PCs can only be hosted on a Azure VNet in your subscription, which is great! You are in full control of the traffic flows and can put them on the corporate network if you like. This also goes for Azure AD joined.
Azure AD joined Cloud PCs are similar to having a “cloud only” physical client. You manage it with only cloud tools and you shouldn’t have o big dependencies towards on-premise services. You will manage it from Microsoft Intune and GPOs are now a thing of the past.
For many organizations, this is a journey. Moving to cloud based management is a journey which many are on. Utilizing Windows 365 Cloud PC to get going could be a great place to start, since your users will then potentially have both of your two worlds!
Conclusion
Choosing one or the other comes down to what your needs are, and how you would like to manage your devices.
If you are yet not on your road to Azure AD only devices, well then you will probably need the hybrid joined version for the time being. But like I said earlier, you can of course have both and transition over.
If you have a group of users who only need access to e.g. SaaS based applications, then what’s the point in putting them “behind the firewall”? There are so many scenarios for which you can say the one or the other is the best, but what’s best for you might not be the best for someone else.
I personally is a firm believer and advocate for going cloud only for device management so I always try to challenge to see how far you can take it. It’s usually further than you would think. Same goes for Windows 365, make use of the fact that it’s a cloud service and native to Microsoft Endpoint Manager by going Azure AD only. You can still put the device on “corp-net” using Azure VNets, but skip the on-premise AD stuff.
Adding Azure AD joined will increase the scenarios, and it’s actually a lot easier to get started with Azure AD only then involving on-premise AD, which in an IT organization often means that you need the identity team to help you to some extent.
If you want to get started with cloud management for devices, looking at setting up Azure AD join for Cloud PCs and manage them through Microsoft Endpoint Manager is a great place to start!
There are a few ways you can access your Cloud PC. You probably have your favorite way to access your Cloud PC, but I though I would go through them all and the benefits with each.
Microsoft has also announced an upcoming Windows 11 feature called Windows 365 Switch which will be a native Windows 365 app in Windows 11. I will not cover that in this post since it’s yet to be released at the time of this blogpost.
Browser
Connecting to your Cloud PC through the browser is in my humble opinion the coolest way, and really convenient since you can then access your computer from what ever device you are using without any issues (as long as the browser is a modern browser like Edge, Chrome, Safari, or Firefox). Okay, not any device, but Windows-, macOS-, ChromeOS-, or Linux-based device.
You access the Windows 365 service through https://windows365.microsoft.com and sign in with your account.
In this portal, you will see all Cloud PCs assigned to you.
To connect to the Cloud PC, you simply press “Open in browser” and the Cloud PC will open in a new tab.
You can also perform some remote tasks on the Cloud PC such as restart, restore, rename or troubleshoot. Or see System information.
The restart is exactly what it sounds like, you will remotely restart your Cloud PC. Restore can be used to go back to a previous point in time (I cover that in this blogpost).
Rename option will allow you to give your Cloud PC a new friendly name instead of the generated name.
If you as an end-user are experiencing issues with connecting to your Cloud PC, you can use Troubleshoot to see what’s causing the issues. It will check that the service is healthy and that there aren’t any connectivity issues.
If you click the “System information”, you will see some details about your Cloud PC such as device name and license.
Remote Desktop app
Working with your Cloud PC everyday, I would say that this is the best option to connect.
Simply download the Remote Desktop app from Microsoft for your desired operating system. For Windows I would suggest to use the desktop version and not the Microsoft Store version, the desktop version works a little bit smoother in my experience.
One thing that is good to keep in mind is that if you are using macOS, you cannot currently have multiple accounts in the Remote Desktop app.
When you have downloaded and installed the application and start it for the first time, you will be asked to sign in. Sign in with you account and the resources you have assigned to you will be added. These could be Windows 365 resources, but also Azure Virtual Desktop resources and published apps.
As you can see by the picture, running the app in Windows I can have multiple accounts and resources in the same place, giving me easy access to several environment.
To launch the Cloud PC, I simply dubble click on the computer icon, provide my credentials and I’m signed in.
I can choose to run this in a full screen experience or a windowed experience depending on my personal preferences.
Using the Remote Desktop app, you don’t get all the remote features as you do in the web-portal, but you have easier access to your Cloud PC on a daily basis.
Mobile app
Lastly, mobile app. There is a Remote Desktop app available for iPhone/iPad and Android devices which can be used to connect to your Cloud PC. I will show some screen shots from and iPhone which is maybe not the smoothest way to work with the Cloud PC due to the screen size. For this, and iPad would be a much better option.
To connect, click the + sign at the top right corner and select “Add workspace“. You will need to enter the subscription URL found here and then sign in with your account. One thing to keep in mind with the mobile app is that you can only have one account associated with the workspace, so no support for multiple accounts.
Once you have signed in, you will see all resources which are assigned to this account.
To connect, simply tap on the computer you which to connect to and enter your credentials when asked to and you will be connected to your Cloud PC.
You can now use your Cloud PC from your mobile device, and keep working where you left your desktop! This is a great option when you have to check something on the go, to simply just connect to your Cloud PC.
Feature vice, the mobile app is pretty limited but you can easily connect to your desktop. If you have a larger screen, the experience will be better so an iPad or Android tablet with a keyboard would be ideal even though it works surprisingly well using an iPhone as you can zoom in and out if needed.
One pretty neat feature with virtual clients is that you can have restore-points. If you have ever used Hyper-V, you have probably used or seen the checkpoints which you could use to go back to a previous state. This kind of feature is available in other virtualization platforms as well, but Hyper-V is the one I’m familiar with. Citrix, being an old player in the VDI game, also offers this feature.
The restore point option is now also available for Windows 365 and your Cloud PC. Meaning that if you mess something up or manage to delete something really important you had stored locally, you can roll your device back to a previous state. Please be aware that this is stilla preview feature, so the final feature might not be the exact same things as shown in this post.
You can restore either as an admin, or have your end-user do the action. To allow your end-users to do this, you need to configure this setting.
If you enable this for your users, they can restore on a much tighter intervall than you can as an admin. You as an admin have 12 hour restore points, but you can configure for your end-users to be able to configure to have restore points every 4 hours.
Of course, if a backup is restored from a restore point, any data stored on the Cloud PC between the current time and restore point time will be lost.
Setting up user initiated restore
To configure the restore point service, navigate to Devices > Windows 365 and select the User Settings tab.
Press “+ Add” and give your profile a name.
In the “Point in time restore service” part of the profile, check the check-box for “Allow user to initiate restore service” and then select the frequency for your restore points.
Hit Next and assign your profile to a group of users, I’m assigning it to the group I’m using for my provisioning profile.
Press next to review your settings and than create the profile.
The user restore point service will only be available to users included in the group you have assigned the profile to.
Restoring as an admin
As an admin, you can restore Cloud PCs on a 12 hour interval. You can restore the Cloud PC by going to Devices > Windows > Windows devices and find your Cloud PC.
Once looking at the device, you can choose “Restore (preview)” from the ribbon and it will show you all available store points.
Once you click “Select” and confirm that you want to restore, the restore is initiated. If you look under Devices > Windows 365 and the All Cloud PCs tab, you will see that restore is in progress.
Restoring as an end-user
To restore my Cloud PC as an end-user, I need to brows to the Windows 365 portal, windows365.microsoft.com and sign in.
Once signed in, I will see my assigned Cloud PCs.
To initiate a restore, I simply click the gear icon on the Cloud PC I want to restore and select “Restore (preview)“.
Once I click that, I get this screen telling me as an end-user what will happen and I need to confirm that I really want to restore and then select which point.
Once I’ve clicked restore the Cloud PC will get a banner saying “Restoring Cloud PC” and which indicates that the process has started. I will see the same thing if a administrator has initiated a restore for me as well.
Once the restore has completed, my Cloud PC is ready to use again and will contain the same data as it did at the point in time of the restore point I selected.
Updated on the 25 of September 2022 due to new functionality released to downgrade Cloud PCs
As you might know, the size of a Cloud PC is based on the license you have purchased and assigned to a user. However, sometimes you might assign a too small machine for a user which is causing performance issues for them. It could also be the other way around, that the user has a too powerful machine, which drives an increased cost for your organisation.
How your Cloud PC is performing is measured and presented to you under Reports > Endpoint Analytics in the Microsoft Endpoint Manager admin center (MEM). The report called Resource performance will show you how your Cloud PCs are performing, and if you need to upgrade any of them. (Note that it will take up to 24 hours before you can see data on your Cloud PC)
As you can see, the top two machines have a very low performance score, and if you look at the individual machines they have different needs for an upgrade, one needs more RAM and the other a better CPU.
There are however two caveats to re-sizing a machine.
You can upgrade or downgrade (only upgrade, not downgrade)
If you are using group-based licensing, this does not work
You can not resize Azure AD joined Cloud PCs
The benefit to resizing a Cloud PC compared to just assigning a larger license to the user is that the Cloud PC will remain, just the specification will be upgraded. So all user data is preserved, however, the user will get kicked out of the session while the resizing is happening.
Resize a Cloud PC
Resizing a machine is really simple, you simply navigate to the device in MEM and click the “Resize (preview)” button in the ribbon.
When you have clicked this button, a fly-out menu will open to the left showing you the different sizes. You will be able to see all sizes, but you can only select and apply the size that you have licenses for, so if you select a size you don’t have licenses for it will show an error message as in the picture below and you cannot continue.
You can upgrade vCPU, RAM, and disk space. However, you are limited to only downgrading vCPU and RAM, disk space will not be possible to decrease.
When you have selected the new license through the resizing portal and clicked Resize, the machine will re-provision itself which will take a while.
Once the machine has been reprovisioned, you will notice that you have the same stuff on your Cloud PC as before the resizing but with a different configuration.
One of the best ways to access your Windows 365 Cloud PC is by using the Remote Desktop application which you can either download from the Microsoft website or deploy from Microsoft Intune if you are using a managed client.
This post was inspired by a blog post from Microsoft that seems to have disappeared.
To simplify the “adding your Cloud PC/Azure Virtual Desktop to Remote Desktop” process for your users, you can actually create a configuration profile in Microsoft Endpoint Manager which automatically adds the signed-in user to the Remote Desktop with the correct subscription URL.
Please be aware that depending on which version of AVD (Azure Virtual Desktop) you are using, the URL might vary so check the documentation beforehand!
Let’s start by adding Remote Desktop to MEM.
Adding Remote Desktop as an application
The first step is to download the Remote Desktop application, which can be found here.
When you have downloaded the MSI, you will need to use the Microsoft Win32 Content Prep Tool to create a .intunewin file of the MSI.
Download the tool from GitHub and run the tool in PowerShell.
When the tool has successfully created the intunewin-file, you will find the .intunewin file in the output folder you specified.
Head over to Microsoft Endpoint Manager and navigate to Apps > Windows and select “+ Add” and then Windows app (Win32) as App type.
On the first page, find your .intunewin file created in the earlier step and upload it. Update any information about the application as needed add press next.
Leave all settings to default on the next tab.
On the Requirements tab, update Operating System Architecture to correlate to the version of Remote Desktop you downloaded and add which the minimum OS version needs to be. In this case, I’m using a 64-bit version of the app and I require Windows 10 21h1 or newer.
On the next tab, Detection rule, add a custom detection rule using MSI as rule type and leaving all values to default.
Leave Dependencies and Supersedence empty and add a group on which you wish to deploy the application. In this example, I’m deploying it to all users but filtering out that it needs to be a Windows 11 computer.
Review your settings and then create your application. It takes a few minutes for the application to upload.
Automatically adding virtual machines to remote desktop
The next step is to create a new configuration profile, based on a setting from Settings Catalog.
Navigate to Devices > Windows > Configuration Profiles and create a new profile by clicking “+ Create profile” and then select “Windows 10 and later” as a platform and “Settings catalog” as Profile type.
On the first page, give your profile a good name and press next.
On the next page, click “+ Add setting“, find and click Remote Desktop in the list, then check the box next to “Auto-subscription (user)“. Then close the flyout using the X in the upper right corner.
Add the subscription URL to the settings. The one used in this example works for Windows 365 and Azure Virtual Desktops.
Press next and assign your profile to a group, in this example I’m using the same settings as for the Remote Desktop app (All users and a filter for Windows 11).
Click next and skip the Scope section. Review and create your profile.
User experience
When the user opens the Remote Desktop the first time, they will see all Cloud PCs and AVD that they are assigned to.
If they are not assigned to any virtual clients, they will get a message saying that no machines are assigned.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
