Azure

Everything about the Microsoft Azure Portal

AzureWindows365

The complete Windows365 setup guide: Custom Image, AAD-join, Azure network connection, MEM

Posted on 30.09.2022by adminion

Windows365 Cloud PCs seem still much underestimated, but maybe that’s just my opinion. Just a couple of thoughts and options, what you can do with it and what you’ll learn in this article:

  • Use it as a PAW (Privileged Access Workstation) for IT-Admins or external users
  • Use it as a cloud-only VDI solution (Use Azure AD created users and groups, with Azure Fileshare or Teams-Channels you don’t need a file server)

Content

Step 1: Buy and assign Win365 licenses
Step 2: Mange Win365 Cloud PCs in MEM
Step 3: Create a Win365 Custom Image
Step 4: Configure your Image VM and create the Image
Step 5: Upload custom image to MEM
Step 6: Set up Azure network connection
Step 7: Create a Provisioning Policy
Step 8: Test it
Step 9: Win365 Networking (Azure Firewall)

Introduction

Windows365 is a Microsoft-Managed Cloud PC. Under the hood it may run on a Microsoft-Managed AVD platform, but who knows. Win365 is available in two different options:

  • Business: Basic, Standard, Premium (different CPU and RAM options)
  • Enterprise: same models, but you’ll get MEM integration, what is essential for a productive use

This article is not about showing price plans or comparing them. Please check the official MS site for more details:
Windows 365 enterprise plans and pricing | Microsoft

Step 1: Buy and assign your Win365 licenses

Your Win365-journey starts unspectacular with buying a license 😉 Go to the admin.microsoft.com Portal, Billing, Purchase services. We’re buying and configuring a Win365 Enterprise with 2 vCPUs, 8GB RAM and 128 GB Storage.

(or maybe you’ll need to buy the licenses from your CSP).

After you purchased your Win365 license, it will become available under Licenses:

Click on it and assign it to a user or a group:

This will kick off the deployment process of your Win365 Cloud PC in the background. You’ll see it in the next step.

Step 2: Manage Win365 Cloud PCs in MEM

Head over to the MEM portal: endpoint.microsoft.com. Under Devices, Windows365, you can see your Cloud-PC is already waiting for its deployment:

Before we actually deploy it, we would need to create a Provisioning policy. But we’re going to take a step back and have a look, how to create a custom image and an Azure network connection. After we’ve completed that, we’ll continue with creating the provisioning policy.

 

Step 3: Create a Win365 custom image

Head to the Azure Portal, create a resource group like: p-rgr-win365imgvm-01 or similar. Create a Virtual Machine from the Azure Marketplace. Choose a name and region. When it comes to image, it’s really important that you click on See all images:
 
This will lead you into an Image Marketplace. Scroll down and look for Windows365 Enterprise – Cloud PC:
 
If click on the arrow, you’ll see that you can choose between many different images for your Windows365 Image:
 
For our demo, we’re choosing Windows 11 Enterprise Cloud PC, including M365, x64 Gen2:
 
Choose a descent VM size, create a Localadmin Username and Password. Later, you want to RDP into this VM of course. I would not recommend to deployed it with Public IP. If you have a S2S VPN in place, it’s not a problem at all. Otherwise you could deploy an Azure Bastion Host, which is a Microsoft Managed Jumpserver.
 
Choose your desired virtual network and after that, finally deploy your Image VM.
 

Step 4: Configure your Image VM and create the Image

Now it’s time to connect your Image VM. In my case, I’m using Azure Bastion. As you can see the Azure Marketplace includes M365 apps and they’re all preconfigured!

Now it’s time to customize your image. Install apps of your choice, configure the settings you want, until it’s all ready to build the image. In our case, we’re just installing Visual Studio Code (system installer):

Don’t forget to execute a Sysprep to generalize the VM:

When Syprep is finished, the VM will shut down. Go back to the Azure VM Overview and click on capture:

For now, Win365 doesn’t support loading Images from an Azure Compute Gallery. That’s why we’re choosing “No, capture only a managed image” on the next screen. Give it a nice name and create it:

After some time, a image resource will show up in your resource group:

Step 5: Upload custom image to MEM

It’s time to go back to the MEM portal, under the Win365 console, choose Custom Image and click on Add:

Enter an Image Name and a Version. Then choose the right Azure Subscription and the Image created before:

The upload could  take over 30 minutes. After it’s completed, the image is ready to use later on:

 

Step 6: Set up Azure network connection

In most cases, you’ll want to place your Cloud PCs into an Azure VNET, that is peered to the hub and connected to onprem through a S2S VPN. For that, we need to set up an Azure network connection. In MEM, Win365 console, Azure network connection, choose create. Now it’s also time to decide if you want to go with hybrid oder AAD join.

  • Hybrid join: A computer object for the Cloud PC will be created in your onprem AD. You can apply GPOs on it.
  • AAD join: The cloud PC will show up in Azure AD and MEM. You can deploy configuration profiles on it.

For now, we’re choosing AAD join.

Enter a network connection name, choose the subscription (where your desired VNET is), the VNET and the subnet:

The Win365 service needs a couple of RBAC permissions, that will be set automatically during the deployment:

Click Create. After some time, the network connection should appear as ready in the console:

 

Step 7: Create a Provisioning Policy

Now, everything’s ready for creating a Provisioning Policy. Click Create Policy:

Enter a Name, Choose Azure AD join and the Azure network connection we’ve just created:
 
Click next. Choose Custom Image and the Image we’ve uploaded before:
 
Click next. Choose your language and region settings. You could also choose that your Cloud PC is managed by Windows Autopatch. I’ll test this another time, but don’t forget that you have that option.
 
Click next. On the assignments page, you’ll need to choose an Azure AD Group where my policy gets applied. Don’t forget: The users in this group need to have an Win365 license too. In my case, my user is the only one in that group:
 
Click next. Check all your settings and if everything is correct, create the policy:
 
 
If your user is in that assignments group and has a license the Cloud PC deployment will start automatically. You can check the status on the All Cloud PCs blade:
 
Coffee time! The deployment of the Cloud PC can take up to 45min.
After that, you’ll see the provisioned Cloud PC in your console. I didn’t find a way yet, to rename it. If you have found one, please leave a comment below.
 

Step 8: Test it

Now it’s finally time to connect to our customized Win365 Cloud PC. You’ve got two options available:

I would recommend you download the client and install it. After you’ve done that, open it up and Click Subscribe. Enter your Azure AD credentials:

After that, you should see your Cloud PC ready to connect:

Bonus tip: Right-click the icon, Settings, to configure the RDP settings:

Double click the icon. After a super smooth login, you’re ready to use your Cloud PC (please note that Visual Studio Code is installed, because we’ve included it in the image before):

 

Step 9: Win365 Networking (Azure Firewall)

Now your Cloud PC is ready to use. It depends on the scenario, but in most cases, you’ll want to access some onprem Resources. I would definitly recommend to add some specific Firewallrules for Win365. In our demo here, we have the following situation:

  • S2S VPN from onprem to Azure
  • All traffic routed through an Azure Firewall (classic hub/spoke architecture)

Let’s see if we can find our Cloud PC in the Azure VNET. Go to the Azure Portal and look for the VNET, that you’ve chosen for the Win365 Azure network connection. Under Connected devices, you should see your Cloud PC (besides the Image VM and the Bastion Host):


Conclusion (and notes from the field)

Maybe you’re thinking of the same as me in this moment: Does it make sense to activate it for all my VMs? Especially if I have a lot of them? Not really.

In my case, I decided to install the Azure Connected Machine Agent on my Hyper-V host machine. This allows me to RDP into my host and start the Hyper-V console. In Hyper-V, I can start RDP session into my VMs from there.

Either way, I would recommend that you install the Azure Connected Machine Agent on all your VMs to get a complete view of your environment. Then activate Windows Admin Center only on your host machine. That should do it.

Happy remote-administering from everywhere!

AzureWindows Admin Center

RDP for on-prem VMs in the Azure Portal with Azure Arc

Posted on 24.08.2022by Martin

Now you can establish an RDP connection to your onprem-Server directly in the Azure Portal with Azure Arc and Windows Admin Center. Connect from everywhere and say goodbye to VPN.

Introduction

Maybe you’ve already heard these news: If you are using Azure Arc for your servers (wherever they are), there’s an option to activate Windows Admin Center.

So far so good, but that is opening up a whole new world of capabilities. In the following article I’ll show you how it works.

Step 1: Arc-enable your servers

To start, you’ll need to install the Azure Connected Machine Agent on your VMs. Follow the guidance in my last blogpost, Step 1-4:

https://azureblog.org/update-management-center/

Step 2: Activate Windows Admin Center

If you followed the steps correctly, you should now see your servers in the Azure Arc console:

 

Now click on a server of your choice and look for the Windows Admin Center option:

Click on Set Up to activate Windows Admin Center. The standard port is 6516, click on install. This will install the Windows Admin Center extension.

Step 3: Set RBAC permission for WAC

After a couple of minutes, you’ll see a message, that you need to set the RBAC permission for your WAC machine:
 
Click on the banner. That will redirect you into the IAM blade of your Arc server. Click on Role Assignments and Add role assignment:
 
Search for Windows Admin Center and choose “Windows Admin Center Administrator Login”:
 
Click on Next. Now click on Select members and add the member of your choice:
 
Click on Review + Assign two times. Now the user has been added at the bottom of your IAM screen.
 

Step 4: Connect to Windows Admin Center

Click on the Windows Admin Center button again. Now you should see a connect button coming up:

Click on Connect. The WAC console will start and now you’ll need to enter the local admin credentials of that VM:

Click on Sign in. Now you’ll see the Windows Admin Center console appearing right in your browser!

Step 5: Establish an RDP session

Now you’ll see all your favourite management tools for your servers. In my case, I’m trying out RDP. Click on Remote Desktop. Enter the localadmin credentials again:

Click on connect. Now you’ll see the RDP session in your browser! How awesome is this:

Now you’re ready to work on your server. Don’t forget: You can use all the other Windows Admin Center Management tools, like:

  • PowerShell (shoot a script from the Azure Portal right into your server)
  • Check performance and monitoring
  • Manage your certificates
  • and so on…

Conclusion (and notes from the field)

Maybe you’re thinking of the same as me in this moment: Does it make sense to activate it for all my VMs? Especially if I have a lot of them? Not really.

In my case, I decided to install the Azure Connected Machine Agent on my Hyper-V host machine. This allows me to RDP into my host and start the Hyper-V console. In Hyper-V, I can start RDP session into my VMs from there.

Either way, I would recommend that you install the Azure Connected Machine Agent on all your VMs to get a complete view of your environment. Then activate Windows Admin Center only on your host machine. That should do it.

Happy remote-administering from everywhere!

Azure

Update Management Center (UMC)

Posted on 29.07.2022by Martin

Long awaited: On July 18th, Microsoft announced the Public Preview of Update Management Center in Azure:
Announcing Public Preview of Update management center – Microsoft Tech Community

Introduction

UMC is a native Azure service for patching your servers, wherever they are. As mentioned, the service is in public preview and it looks like, there’s a lot more to come. But, my first impression shows already some really nice benefits:

  • No more Log Analytics Workspace and Azure Automation Account (native Update console in Azure)
  • Azure Arc Connected Machine Agent only: No more messing around with different agents. Simply install the Azure Arc Agent (you’ll get the other Azure Arc benefits)
  • Use of Azure Arc Private Link: Now you can patch your servers through the S2S VPN tunnel
  • More Options for your update deployments

Step 1: Create an Azure Arc Resource Group

If you follow the Azure landing zone concept, I would suggest, you should create a new resource group for Azure Arc in the management subscription. Name like: p-rgr-azurearc-01

Step 2: Create a Service Principal in Azure Arc

Enter Azure Arc in the Azure Portal search bar and click on Service Principal. Now click create a new service Principal:

On the following page, you can choose the resource group you create in Step 1. Please copy/paste the ID and the secret to a safe please. You’ll need it later.

Step 2: Create Azure Arc Connected Machine Agent Powershell Script

In the Azure Arc console, click on servers:
 
The assistant will guide through a few simple questions (Please note: UMC isn’t available in Switzerland north, you would have to choose West Europe).
Now you can make use of Azure Private Link and patch your servers through your S2S VPN tunnel. Check the documentation here:
For the demo, we’ll leave it on public endpoint. At the end, you’ll get a ready to use Powershell-Script. You only have to insert your secret.
 

Step 3: Run script on your VMs

There are multiple ways to run your script on your onprem VMs. A central scripting server, software deployment tools and so on. To get a complete view of all your VMs, I would install the agent on as many servers as possible (Windows and Linux).

Step 4: Check your servers in Azure Arc

After you run the script on your VMs, it takes just a really short time, until they appear in the Azure Arc server console:

Step 5: Asses servers in UMC

Head over to the UMC console by typing Update Management Center in the Azure Portal searchbar. Click on machines, select your machines and click on Check for updates.

Coffee time! This will take some minutes to complete. If you just onboarded the servers, it could be that you see some error messages. Just wait a little bit longer and start the update assessment again.

If you see error messages during the assessment: I noticed, if you just installed the agent it could take some hours until the assessment goes through. In my case, on the next morning everything was fine.

Step 6: Schedule your first maintenance configuration or do a One-time update

Now you’re ready to start patching! After the assessment went through, you should see your missing updates:

Patch deployments are now called “maintenance configuration”. Click on Deploy Updates in the UMC console. You’ll see tons of options for your deployment, that you can explore/configure on your own. In my case, I decided to patch my 3 servers every Wednesday on 8 pm:

It seems that the maximum patch window duration is (for now) 3h55min. Hit next and choose the VMs you want to patch:

At this moment, unfortunately, there seems to be no option for groups. Let’s hope that will be coming soon. On the next screen you can decide which patches you want to include or exclude. Don’t forget to include all update categories (if you want to do a complete update deployment).

Now go ahead, set your tags and create the maintenance configuration. After creation is done, you’ll see a new resource showing up in your Azure Arc resource group!

Step 7: Patching time

Like a perfect swiss clock, at 8pm my patch deployment starts.

Step 8: Additional features

Periodic assessment by Azure Policy

In Azure Policy, you’ll see some specific UMC policies. With remediation, you could automize your patching (maybe not your prod, but for dev environments this could be very nice).

Defender for cloud

You’ll see your Azure Arc enabled server and your missing patches in DFC too.

Conclusion (and notes from the field)

UMC seems to work pretty fine and I’m sure, there will be a lot of new features soon. The steps above showed a demo environment. As I started working with UMC in costumer environments, I noticed, that some configs have to be in place:

I’ll continue to work on this and provide more details about that as soon as possible.

Happy Patching folks!

Azure

JSON View in the Azure Portal

Posted on 25.04.2022by Martin

Have your ever noticed that small button called “JSON View” at the top right of the Overview of Azure Resources?

This button becomes quite handy, especially when you are coding, for example with Azure Bicep. Sometimes it can be hard to find the needed parameters.

A hint for this is, deploy your Azure resource through the marketplace and come back here to look at the JSON. It describes all the parameters you have chosen and you can copy them over to your bicep code.

Happy Coding Folks!

Azure Networking

Delete Azure Load Balancer in front of VM Scale Set

Posted on 25.04.2022by Martin

If you ever have tried to delete an Azure Load Balancer that is configured with an Azure VM Scale Set as the backend pool, you will get an error in the Portal. You could delete all resources and start from fresh, of course. If you need to keep the scale set, here’s the solution:

  1. Run the following command in the Azure Cloudshell:
    az vmss update –resource-group <<RESOURCE_GROUP_NAME>> –name <<VMSS_NAME>> –remove virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].ipConfigurations[0].loadBalancerBackendAddressPools 0

  2. Upgrade the VM Scale Set instances:
    az vmss update-instances –instance-ids “*” -n <<VMSS_NAME>> -g <<RESOURCE_GROUP_NAME>>

  3. Delete the load balancer:
    az network lb delete -g <<RESOURCE_GROUP_NAME>> -n <<LB_NAME>>

 

 

AzureAzure EA Portal

Change the Account Owner of an Azure Subscription

Posted on 06.10.2019by Martin
Problem

Every Azure subscription has an Account Owner and a Service Administrator. If you are an Azure Admin and can’t see costs or details of a subscription, you should check if you are the Account Owner, or at least the Service Administrator.

You chan check the Account and Service Administrator in the Azure Portal, Subscriptions, Select your Subscription, Properties:

Read More