Tag: cloudpc

Categories
Windows 365

Custom name for Cloud PC

Giving computers custom names is something which is somewhat of a hot potato. We have been doing it for years, and I’ve even blogged about it previously (olastrom.com – Naming conventions). It’s something which is important for some, but from an asset perspective it has kind of played out its role since it is not persistent.

However, one thing that has been a really important thing for some, has been the possibility to configure the naming convention for Windows 365 Cloud PCs which has not been possible. Until now!

With the update in the end of March 2023, this is now doable. It follows the same pattern as the naming convention for Windows Autopilot enrolled devices. You can set a prefix followed by variables. For Cloud PCs, these are a bit different, but follow the same idea.

As you can see by the picture, the name can be between 5 and 15 characters and can include some additional characters except for numbers and letters. The computer name MUST include at least 5 random characters using %RAND:y% where y is the number of random alphanumeric characters. I can however leave out the username and only use random characters.

Configure Cloud PC naming

To configure Cloud PC naming, you can either create a new provisioning policy or change an already existing one. In this example, I will change one of my existing policies. This new setting is by default off in all existing policies and you will need to actively set this for new policies.

Head into Microsoft Intune (intune.microsoft.com) and navigate to Devices > Windows 365 and select the Provisioning Policies tab.

Either select “+ Create policy” or modify an existing policy. I’ve chosen to update my existing policy for my Swedish users. When you get to the “Configuration” step in the policy, you can enable the Cloud PC naming by checking the check-box. It will then display the option to enter a custom name.

As you can see by my example, I’ve chosen to set the policy to give my Cloud PC a name which is CPC followed by five random alphanumeric characters followed by SWE. So, the name could end up being CPC-ABC12-SWE.

Conclusion

“With great power comes great responsibility”. Use naming wisely. To be honest, for Cloud PC naming makes slightly more sense since we don’t have serial numbers or such as an identified. However, naming will change once re-deployed since we have a random part of the name if is enforced. But with this function we can adapt it to fit with the rest of our naming conventions a bit more. You could even just set the same as for all other PCs (except you will get alphanumeric and not numeric random characters).

Categories
Windows 365

Cloud PCs and the Impossible travel

Once upon a time, in a data center far far away….

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.

Have you seen something like this with Cloud PCs?

Categories
Intune Windows 365

Get started with Microsoft Dev Box

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!

Categories
Intune Windows 365

Disabling ESP on Cloud PC

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.

Add a new OMA-URI setting by pressing Add.

OMA-URI: /Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage

Data type: Boolean

Value: True

Save your setting 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.