stephanvdkruis.com

Securing Windows 365 Enterprise with Azure Firewall

Configuring Azure Firewall in combination with Windows 365

To increase security on your Windows 365 hosts you might want to put your Windows 365 clients behind a firewall. There are several options but one of the options that you have is to use the Azure Firewall. The Azure firewall is a powerful SaaS solution of Microsoft, but also an expensive one. Recently Microsoft announced the preview of a new Firewall sku, the Azure Firewall basic. The solution is more aimed to midsized companies. It lacks the advanced features of the Standard and premium Firewall but is does provide you with enough features to better secure your environment. Besides it also in a lower price range so it should be more attractive to midsized companies.

Azure Firewall Premium is recommended to secure highly sensitive applications (such as payment processing). It supports advanced threat protection capabilities like malware and TLS inspection.
Azure Firewall Standard is recommended for customers looking for Layer 3–Layer 7 firewall and needs auto-scaling to handle peak traffic periods of up to 30 Gbps. It supports enterprise features like threat intelligence, DNS proxy, custom DNS, and web categories.
Azure Firewall Basic is recommended for SMB customers with throughput needs of less than 250 Mbps.

In this blog I will show you the basics of setting up the new Azure Firewall Basic sku in combination with Windows 365 Enterprise. Unfortunately, Windows 365 Business is not suitable for Azure Firewall because you will need to redirect the traffic through the Azure Firewall. With Windows 365 business you do not have any control over the networking, since it’s managed by Microsoft. The article builds upon the blog series of Windows 365, so if you need information on how to set up Windows 365, I recommend reading through those articles first.

Azure Firewall

This feature is in preview, so you might need to register the new Azure Firewall Basic Provider. To do so:

Connect-AzAccount
Select-AzSubscription -Subscription “subscription_id or subscription_name”
Register-AzProviderFeature -FeatureName AzureFirewallBasic -ProviderNamespace Microsoft.Network
Check Registration: Get-AzProviderFeature -FeatureName AzureFirewallBasic -ProviderNamespace Microsoft.Network  
Wait until the provider is registered

From a networking perspective an Azure Basic Firewall needs 3 subnets within a vnet. It needs a management subnet, Azure firewall subnet and a subnet workload subnet. The management and the Azure firewall subnet need specific names otherwise you won’t be able to deploy the Firewall. So, in your vnet you need to create 3 subnets:

Subnet : AzureFirewallSubnet, in my case I am using a 10.3.4.0/24 subnet
Subnet: AzureFirewallManagementSubnet, in my case I am using a 10.3.2.0/26 subnet
Subnet: Workload subnet 10.3.5.0/24

Required subnets

In production environments it is considered better to create a hub spoke network topology where you Firewall is in a separate Vnet than your workload. You connect your Vnets via network peering. The functionality doesn’t change is you have 1 or multiple Vnets.

Now you have set up the subnets in your Vnet its time to deploy the Azure Firewall. Sign into the Azure Portal and search for Firewalls and select Create.

To set up Azure Firewall sign into the Azure Portal and search for Firewalls and select Create.

Subscription. Where the Azure firewall will be deployed. This needs to be the same subscription as where your vnet is created.
Resource Group. Select or create a resource group to deploy the Firewall
Name. Give you Firewall a name.
Region. Select the region for your Firewall. This also needs to be the same as the region of you vnet.
Availability zone. If the region supports availability zones you can select a zone or leave it to none
Firewall SKU. Select Basic, or a higher sku.
Firewall management. Is greyed out is you choose Basic
Firewall Policy. Create a new policy. This also needs to be deployed in the same region.
Virtual network. Choose a virtual network. Pick the network where you want to deploy the Firewall. If you did not create the necessary subnets, you will get an error.
Public IP address. Create a new Public IP address
Management public IP address. The basic sku also needs a public management IP. You won’t be able to connect to this IP, but it is necessary for Microsoft to manage your Firewall.

Choose review and create. The deployment will start and can take up to 30 min, so go grab yourself a cup of coffee.

While waiting for the deployment we can already create a route table. With a route table we can redirect network traffic within Azure. Otherwise the Windows 365 clients network traffic will leave Azure without passing through the Firewall.

In the Azure portal search for Route Table and create a new Route table

Subscription. Same subscription as the vnet to which you want to connect to route table
Resource Group. A resource group of your choosing.
Region. Select the same region of your vnet
Name. A clear name, such as route-to-fw
Propagate gateway routes. Depending on your config, but you can leave it on yes.

When your route table has been created go to the route table and select Routes and select Add

Add the following to the new route:

Route name. A clear descriptive name
Address prefix destination. Choose IP Addresses
Destination IP addresses/CIDR ranges. Enter 0.0.0.0/0 this way all traffic will be forwared.
Next hop. Choose Virtual Applicance
Next hop address. This is the IP of the Azure firewall. This is the first available IP in the AzureFirewallSubnet. In my case the range is 10.3.4.0/24 so the first available IP will be 10.2.4.4. You can also check this by going to the Firewall.

The next step is to associate the route table to a subnet, this way all devices in that subnet will use the route defined in the table. Be aware that associating the route table will result in disconnecting your Windows 365 user sessions. You need to configure the firewall as described in the next section. To associate the route table, select subnets and choose associate. You can there select the Vnet and the subnet of where your workload is deployed.

Configuring Azure Firewall

You now have a firewall and you route all the Windows 365 traffic through that firewall. This also means that the traffic that is required for users to connect to the Windows 365 machine is also blocked. So if a user tries to connect to its machine it will get the following message. So if you are deploying the firewall to a production environment wait with applying the route table otherwise your users won’t be able to connect to their machines.

You will need to make some firewall rules. Unfortunately, there is no official Microsoft documentation of which firewall rules you need to create in order for Windows 365 to work (At least I haven’t found it). There is however documentation available on firewall rules for Azure Virtual Desktop. The two basically share the same connection method so that should give us a good starting point. You can find the AVD documentation here https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?tabs=azure#create-network-rules . In the Azure Portal search for Firewall Policies. A policy was created when you deployed the Firewall so there should be at least one policy there. Open that policy and let’s start with Application rules. In the Application rules you have to have at least one rule collection. A rule collection is a logical set of rules that allow or deny traffic. Select Add a rule collection. Give the collection a name, for example Windows365Applicationrules. For type use Application and give the collection a priority. The priority determines the order of the collection to be deployed. If you don’t know how many rule collections you are going to have pick a number witch gives you flexibility in deploying higher of low collections. So don’t start with 100 since that is the highest priority. For Rule collection group you can leave the DefaultApplicationRuleCollectionGroup for now. Next you can define the rules.

Enter the following rules. The source is my subnet range where I deployed my Windows 365 machines.

Name	Source Type	Source	Protocol	Destination Type	Destination
Login Microsoft Online	IP Address	10.2.2.0/24	Https:443	FQDN	login.microsoftonline.com
AVD	IP Address	10.2.2.0/24	Https:443	FQDN	*.wvd.microsoft.com
W365 Monitor	IP Address	10.2.2.0/24	Https:443	FQDN	*.prod.warm.ingest.monitor.core.windows.net
catalogartifact	IP Address	10.2.2.0/24	Https:443	FQDN	catalogartifact.azureedge.net
W365 Monitoring	IP Address	10.2.2.0/24	Https:443	FQDN	gcs.prod.monitoring.core.windows.net
W365 blob storage	IP Address	10.2.2.0/24	Https:443	FQDN	mrsglobalsteus2prod.blob.core.windows.net
Microsoft	IP Address	10.2.2.0/24	http:80, Https:443	FQDN	www.microsoft.com

Application rules

Next go to Network rules. Here also select Add a rule collection. Give the collection a name, select for rule collection type Network. Give a priority and for Rule collection action select Allow. For rule collection rule group select DefaultNetworkRuleCollectionGroup. Enter the following rules:

Name	Source type	Source	Protocol	Destination Ports	Destination Type	Destination
Azure Services	IP Address	10.2.2.0/24	TCP	80	IP Address	169.254.169.254, 168.63.129.16
AVD Services	IP Address	10.2.2.0/24	TCP	443	Service tags	Select WindowsVirtualDesktop, AzureFrontDoor.Frontend, AzureMonitor
DNS	IP Address	10.2.2.0/24	TCP, UDP	53	IP Address	*
azkms.core.windows.net	IP Address	10.2.2.0/24	TCP	1688	IP Address	20.118.99.224, 40.83.235.53
kms.core.windows.net	IP Address	10.2.2.0/24	TCP	1688	IP Address	23.102.135.246
	IP Address	10.2.2.0/24	TCP
	IP Address	10.2.2.0/24	TCP

Network rules

After the policies are applied (and you have applied the route table) you should be able to sign in to your Windows 365 environment. However, browsing through the firewall logging ( you can enable this in the diagnostic settings of your firewall) I was still getting a lot of deny hits for Microsoft services. Even though I was able to connect to the Windows 365 machine, Windows 365 is depending on more services. For example it also communicates to Intune. So I have also added the following application rules:

Name	Source Type	Source	Protocol	Destination Type	Destination
servicebus.windows.net	IP Address	10.2.2.0/24	Https:443	FQDN	*.servicebus.windows.net
self.events.data.microsoft.com	IP Address	10.2.2.0/24	Https:443	FQDN	self.events.data.microsoft.com
.azure-devices.net	IP Address	10.2.2.0/24	Https:443	FQDN	*.azure-devices.net

Application rules

The Firewall logging seemed a lot better after adding the extra rules. You now have configured the bare minimum for allowing the Windows 365 services to you hosts. But that doesn’t mean you are ready. Users are still not able to browse the internet of access any of the other Microsoft 365 services. So, you will need to configure additional rules. We did create a rule to browse to www.microsoft.com, but if you want to go to www.google.com your connection will be blocked. The next step would be op further configure the firewall rules depending on the needs of your organization.

I hope this blog was helpful, if you have any questions or some parts needs additional clarification please let me know in the comments.

Windows 365 Enterprise – Hybrid Join

Deploy Windows 365 Enterprise Hybrid with in depth info about hybrid joining devices

Blog series

In the previous article we deployed Windows 365 cloud pc Azure AD only. In this article we will deploy a cloud pc as Hybrid join. So what is hybrid join? Hybrid joining the machine joins the machine to both the Azure AD as well as the Active directory. When would you choose for a hybrid join set up? There are a couple of scenarios when you would want to choose for a hybrid set. For example you are still highly relying on configuring your devices with Group policies, or you have some legacy application that require machine authentication, or you want to use the hybrid join option in your Conditional access policies. All are valid reasons to use hybrid join. In my opinion Azure AD joining is preferable because it eliminates some moving parts in your configuration. These parts can break time to time so not having them will make your life easier.

When you hybrid join a machine the machine is first joined to the Active Directory and then synchronized to Azure AD. This is done via a certificate. AAD connect by default does not synchronize the certificates and therefor you need to adjust AAD connect for hybrid join.

Configure AAD Connect

So, the first step is to configure hybrid Join in AAD connect. Open AAD connect and select Configure device options. You will see an overview screen where you can select Next. Enter your Azure AD global administrator credentials. Select Configure Hybrid Azure AD Join and Next. Then you select Windows 10 or later domain-joined devices and select Next. You now need to add the SCP configuration. This SCP contains information for the device about where to look for its information as it needs to be joined to Azure. Here you select your forest, authentication service which is most likely Azure Active Directory and select add to enter your enterprise admin credentials. When you hit next some final validations will be done and finally you can choose Configure. Later I will show how to validate the Hybrid Join and what process actually got into motion. Also, if you are planning to deploy the cloud pcs in a specific OU make use the OU is also in sync scope. The OU needs to syn the attributes to Azure AD.

Azure Network Connection

Now AAD connect is ready you can configure Windows 365 for hybrid join. In order to do so go to endpoint.microsoft.com and choose devices and Windows 365. There you select Azure network Connection.

On the tab select create and choose Hybrid Azure AD Join. Enter a name which tells you something about the connection, for example what the vnet is you are connecting to. Select the subscription that has the vnet and select the subnet you want your machines to join to. It’s important that your vnet is in the same region as where you want to deploy your cloud pcs as vnet are bound to a specific region. Select next and create the connection. Make sure your account has the appropriate permissions on the subscription (Owner) and within Endpoint manager.

With Hybrid join you need to add additional domain information. Enter the AD DNS name, optional the OU where the devices should be joined into (make sure this OU is syncing to Azure AD), and credentials of a user which has sufficient rights to join multiple pcs.

Azure network connection, domain settings

Microsoft will start running some checks and if all went well, you will get a checks success status. Note that you can have both join types of Azure AD and Hybrid Join pointing to the same vnet and subnet.

Provisioning policies

The next step should be creating a Provisioning Policy. These policies determine how the Windows 365 pc should be created. From the Devices section select Provisioning policies and select create policy. Enter a name and description. For Join type make sure to select Hybrid Azure AD Join. So, choose for Azure network connection and select the hybrid network connection you just created in the previous step.

At the image tab pick a gallery image, or a custom image if you have one. Check this article if you’re interested in how to create a custom image. At the configuration tab select the language and region. This will automatically install the required language packs on the machine. For additional services you may choose Windows Autopatch. Windows Autopatch manages updates for you. It’s not really a Window 365 services but you can read more about it in this blog Blog | Get current and stay current with Windows Autopatch | Tech Community (microsoft.com)

Finally assign the policy to a group which contains your users. When you have finished creating the provisioning policy you are basically set. When a user has a valid license (a Windows 365 enterprise and a license containing Intune) and is a member of the group which is assign the provisioning policy the cloud pc will be created.

Now I assign the following licenses to my test user in order to start the provisioning of the device. My test user Mickey has 2 licenses: a Microsoft 365 E3 and the Windows 365 Enterprise 2 vCPU, 8 GB, 256 GB license.

Hybrid Join

So how is a device hybrid joined? This process is pretty interesting and does not only apply to Windows 365 but also to normally hybrid joining clients. Hybrid joining set a scheduled task in motion. You can find the scheduled task in \Microsoft\Windows\Workplace Join called Automatic-Device-Join, which is triggered from in this case an event Microsoft\Windows\User Device Registration\Admin. The scheduled task calls upon dsregcmd.exe. One of the first steps in this process is for the computer to create a userCertificate.

This certificate is then uploaded to Azure AD. This is why you needed to reconfigure AAD connect for this process to work. Without the certificate the device won’t synchronize with AAD.

Sometimes the hybrid join process won’t kick off, you can manually start the process by running the scheduled task (\Microsoft\Windows\Workplace Join\ Automatic-Device-Join) or by running dsregcmd /join from PowerShell.

Also verify that the pc shows up as hybrid joined in the endpoint manager portal.

Windows 365 Enterprise- Custom Images

Step by step creating and capturing a custom image for Windows 365 Enterprise

Blog series

Introduction

Windows 365 Enterprise has a great integration with Endpoint manager. So, your configurations and app deployment should primarily come from there in my opinion. But in some cases, not everything that you need to configure can be (easily) done with Endpoint manager. Sometimes you run into an installation or configuration that is just really hard to accomplish with just Endpoint Manger. An example could be installing language pack (although this process is now included in the provisioning policies). But I’m sure there are other examples out there. This leaves you no other choice than to create your own custom image and use that image to be deployed to your users. In this blog I will walk you through the steps into creating a custom Image.

Prepare your Master Image

First step is to create a new Virtual Machine in Azure. It’s important that for your image you search and select a Windows 10/11 Cloud pc. Other important steps are that you connect your VM to a network you to which you can connect, and you want to disable any boot diagnostics or monitoring options.

Now please consider the following. When you run sysprep the machine won’t be able to start again. This means that if you want to save your master image to make some changes later on you will have to reinstall and configure all your settings again. In order to save your master image for future adjustments is best that you clone your master image VM and sysprep the clone. This way the original master image will be saved for future adjustments. If you want to save your master image vm for future use you can follow along, otherwise skip straight to the sysprep section.

Clone your VM

1 Shutdown your master image vm, until a deallocated state.
2 Create a snapshot of the disk
2a Go to your master image VM
2b Select Disks

2c Select the OS disk
2d Select Create Snapshot

2e Now most settings you can leave as default. I would set storage type to standard HHD

3 Create a new disk from the snapshot
3a Go to your newly created snapshot and select create disk

3b Here you can also leave all the defaults as is. Make sure that you select the same disk size as you original VM. By default, the size if 128 GB.

4 Create a new VM from that new disk
4a Go to the newly created disk. From this disk you can now create a new Virtual Machine

4b Use the same settings as when you created the original Virtual Machine, the only difference should be the image, which should be your created disk.

Sysprepping and capturing your image

Now your master image VM is ready to sysprep. You have created a clone, or you used the original VM the next steps are to sysprep your machine and to create an image from that machine. So, connect to your VM. Navigate to C:\Windows\System32\Sysprep and start sysprep.exe. Use the following setting:

System Cleanup Action: Select Enter System Out-of-Box Experience (OOBE) to configure the behavior on startup
Select Generalize
Shutdown Options: Select Shutdown

After some time, the machine will disconnect. Wait until the machine is in a stopped state in the Azure Portal. When it’s in a stopped state you can select Capture.

On the create image screen it’s important to select No, capture only a managed image. Azure Compute Galleries are not supported. Give your image an easy to recognize name. Also, it’s easy to select Automatically delete this virtual machine after creating the image since the machine won’t be able to function after the sysprep and capture procedure.

When everything went successfully you end up with an image.
Its best to test the image by creating a new VM from this image and validate if the image works as expected.

Add image to Windows 365

After you have validated the image you can add the image to Windows 365. Go to endpoint.microsoft.com and navigate Devices > Windows 365 > Custom images and select Add.

Give your image a name and a version, select the subscription where you saved your image and select the image you created.

The image will now be uploaded to the Windows 365 services. This process can take a while to complete. After the image has been successfully uploaded you can use the image in your provisioning policy. Instead of choosing a marketplace image your select custom image and you should be able to find your newly uploaded image.

This was the final post of the Windows 365 blog series. I hope the information was useful and you were able to follow the steps.

If you mis any information, please let me know and I will try to incorporate the information into the blog series.

Windows 365 Enterprise – AAD Join

Setting up Windows 365 AAD Join step by step

Windows 365 Enterprise – AAD Join

As we have seen in Getting Sta rted with Windows 365 Business setting up Windows 365 Business is pretty straight forward. With Windows 365 Enterprise you will see you get a lot more options. This makes setting up Windows 365 Enterprise a bit more complicated, because you have more design decisions to make.

One of the decisions you will have to make is how to enroll your Windows 365 clients. You have 2 options. The first option is to hybrid join the devices (see https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-hybrid-azure-ad-join). This means that you join the device to the Azure AD and the Active Directory. This functionality is also possible with normal Windows 10/11 clients. Most often this solution is used in combination with Conditional Access policies, Group policy management or SSO with on premises application. Please note that SSO is also possible to on premises application without hybrid joining the devices. In my experience most applications will SSO without the need of hybrid joining the devices. Accessing file shares and for example shared printers will work fine if you Azure AD join the devices and only sync users between Active Directory and Azure AD with AAD connect without any fancy configurations. That said, it’s always worth testing because it limits the amount of configuration you have to do for SSO. Hybrid joining devices requires extra configuration within AAD connect and line of sight to a domain controller. Only AAD joining does not require any extra configuration besides a sync with AAD connect, which in most scenarios is already present. This means that AAD joining, and Windows 365 Enterprise only requires a network connection and your good to go. Pretty easy ????

So, to demonstrate this we will deploy a Windows 365 Enterprise Azure AD joined device, that will be able to access a file share.

A small overview of my setup in Azure. I have a simple vnet containing 2 VMs, 1 domain controller which is set up to sync identities with AAD connect and a file server. The new Windows 365 machines are being joined to the same network, but in the Windows 365 subnet. In a production environment you could see that the vnet is connect to on premises resources via a vpn or Express Route, or that there is a hub spoke design with multiple vnets.

Azure Network Connection

The first step would be to connect the Windows 365 services to your vnet. In order to do so go to endpoint.microsoft.com and choose devices and Windows 365. There you select Azure network Connection.

On the tab select create and choose Azure AD Join. Enter a name which tells you something about the connection, for example what the vnet is you are connecting to. Select the subscription that has the vnet and select the subnet you want your machines to join to. It’s important that your vnet is in the same region as where you want to deploy your cloud pcs as vnet are bound to a specific region.

Select next and create the connection. Make sure your account has the appropriate permissions on the subscription (Owner) and within Endpoint manager.
Microsoft will start running some checks and if all went well, you will get a checks success status.

Provisioning policies

The next step should be creating a Provisioning Policy. These policies determine how the Windows 365 pc should be created. From the Devices section select Provisioning policies and select create policy. Enter a name and description. For Join type make sure to select Azure AD Join. For network it’s important to not choose Microsoft hosted network, this way you won’t be able to integrate with your vnet and the setup is more like the Windows 365 business deployment. So, choose for Azure network connection and select the network connection you just created in the previous step.

At the image tab pick a gallery image, or a custom image if you have one. Check out this article if you’re interested in how to create a custom image. At the configuration tab select the language and region. This will automatically install the required language packs on the machine. For additional services you may choose Windows Autopatch. Windows Autopatch manages updates for you. It’s not really a Window 365 services but you can read more about it in this blog Blog | Get current and stay current with Windows Autopatch | Tech Community (microsoft.com)

Finally assign the policy to a group which contains your users. When you have finished creating the provisioning policy you are basically set. When a user has a valid license (a Windows 365 enterprise and a lisence containing Intune) and is a member of the group which is assign the provisioning policy the cloud pc will be created.

Now I assign the following licenses to my test user in order to start the provisioning of the device. My test user Pluto has 2 licences; a Microsoft 365 E3 and the Windows 365 Enterprise 2 vCPU, 8 GB, 256 GB license.

By assigning the license the provisioning starts. Let this process complete.

Connect to fileserver

Now that the provisioning is ready let’s sign in. As mentioned in the beginning of this article SSO to most of your on-premises resources will work without any extra configuration. So, in my case I have a file server (cluster) which I can connect to via \\filecl02.wvd.local\Bestanden even though I sign into the Windows 365 cloud pc with my Azure AD credentials, pretty cool.

As you can see my cloud pc is only Azure AD joined and not domain joined, but still able to access on-premises resources based on my Active directory permissions.

That sums up this part of the series, please continue reading at the next article, where we Hybrid Join the Windows 365 Enterprise cloud pc.

Getting started with Windows 365 Business

Step by step deployment instructions of Windows 365 Business

Please read my introduction blog, Starting with Windows 365 if you are looking for Windows 365 basic information.

Blog series

Windows 365 Business – Prerequisites

In order for Windows 365 Business to work you will need to enable the ability for users to join devices to the Azure AD. You can enable this by going to portal.azure.com selecting the Azure Active Directory and then Devices and Device settings. Here you can select All, or scope it to a group of users.

Before assigning any licenses its good to set the organization default settings. Here you can choose whether a user should be a standard user or local administrator, what operation system should be deployed and the language. These settings are only deployed when assigning a new cloud pc. You can also those to enroll the new devices into Microsoft Endpoint Manager, but your user will also need a separate Intune license. You can modify these settings my signing in to https://windows365.microsoft.com/

Select Update organization setting:

In my case I also enroll new cloud devices in Endpoint Manager since I have a suitable license.

Assign your user with a license

My test User Goofy is a user who is synced from Active Directory with AAD Connect to Azure AD. You do not need a synchronized user, a cloud only user is also fine. I’m assigning Goofy a Microsoft 365 Business Premium license. This includes Intune so I can manage the device. I’m also assigning the Windows 365 business 2 vCPU, 8 GB, 128 GB license. By assigning the Windows 365 license Microsoft immediately starts provisioning a new cloud pc for the user. This process does take some time to complete. You can monitor this process by selecting the user and by selecting Devices:

After some time you will see that the device is ready for the user to work with:

Since I also selected the option to enroll the device into Intune you can also find the device there.

End user experience

When the user sings into Windows 365 (microsoft.com) they will see the first launch experience:

The user can then launch the Cloud pc

The user can also use the remote desktop application. If possible, I would recommend using the app, because it has better performance than the browser. The user can download the app from the Microsoft Docs.
Open the application and select subscribe and sign in with your credentials

You can now also use the new Windows 365 app which has been announced at Ingite 2022.

Managing Windows 365 Business

As an administrator you would want to administer the device. You have a couple of options. If you have enrolled the device into Intune then your options are limited. When selecting the user in the windows365.microsoft.com portal you have a couple of options:

Restart – will reboot the device
Reset – will completely give you a fresh installed device. This will reinstall Windows and remove all apps and files from the device
Rename – lets you rename the device
Change account type – lets you change the user from a standard to a local admin or vice versa.
Restore cloud pc – Overview of restoring a Cloud PC to a previous state with Windows 365 Business | Microsoft Learn

Managing the device with Intune

Since the device is enrolled with Intune we can also push configurations to the device. I did notice some differences with enrolling normal clients into Intune. There also seem to be some differences with the Windows 365 Enterprise. When opening the device overview in Intune.

There seems to be no primary or enrolled by users, and the device model is stated Virtual Machine. If you compare this with an Windows 365 Enterprise enrollment you see that the primary user and the device model is stated

The lack of an primary user isn’t really an issue, the reason for this is properly that Microsoft uses a different enrollment process like a build enrollment token to enroll the device. The other difference doesn’t seem big until you want to create custom filter rules Create a filter for your Cloud PCs | Microsoft Learn. This option can be useful when you want to target specific Windows 365 cloud pc’s in your environment. Unfortunately this option is not available.

Otherwise, all options that you can use for managing your devices is also possible with Windows 365 business. You can deploy apps, and configurations to your devices as your company requires.

Starting with Windows 365

Welcome to the blog series around Windows 365. During the series I want to provide you with the necessary information and installation steps to build and configure Windows 365 services. This first post is meant to provide you with some basic information around the Windows 365 services.

What is Windows 365?

Stating the Microsoft documentation:
Windows 365 is a cloud-based service that automatically creates a new type of Windows virtual machine (Cloud PCs) for your end users. Each Cloud PC is assigned to an individual user and is their dedicated Windows device. Windows 365 provides the productivity, security, and collaboration benefits of Microsoft 365.

Windows 365 provides user with a single dedicated virtual machine that users can remotely sign in to.

Windows 365 comes in two flavors: Enterprise and Business. Windows 365 Enterprise is aimed to companies who are already invested in Microsoft’s Endpoint Manager and using Endpoint Manager to deploy and manage their Windows 10/11 devices. This means that if you want to start using Windows 365 Enterprise you will also need a license that includes Intune.

Windows 365 Business is aimed to small companies (up to 300 seats) who just need a pc to work from. This means that a user just gets a cloud pc. You do not need an Intune license. But if you want to manage the device an Intune license is required. Windows 365 Business also does not support joining to a custom (Azure) Vnet. So, if you would like to connect your cloud pcs to your network so they can access a file server for example you won’t be able to do so.

Basically, it comes down to this. If you want to have a quick lightly managed device for your end users, you should go with Windows 365 Business. If you want to have more control, you should go with Windows 365 Enterprise. To see a full comparison, check out the docs from Microsoft Compare Windows 365 Business and Enterprise | Microsoft Learn

Azure virtual Desktop

But then there is also Azure Virtual Desktop, where does this fit in? Because you can also deliver one to one desktop using the AVD technology. AVD is the next step from Windows 365 Enterprise, and it would provide you with maximum flexibility when deploying desktop for your users. Both Windows 365 and AVD make use of some overlapping technology, so they may seem similar but there are major differences. One big difference is that Windows 365 does not support multi session and the billing of AVD is based on usage. Where Windows 365 is a single subscription per user.

Nerdio has created a nice overview

Windows 365 vs. Azure (Windows) Virtual Desktop | Nerdio (getnerdio.com)

Upcoming features

As Im writing these blog series, Microsoft Ignite is happening. This events always leads to new announcements and product updates. Also for Windows 365. Here are my favorite developments:

Windows 365 app – Microsoft Store on Windows. With Windows 365 app, you can access your Windows 365 Cloud PC from the taskbar or the Start menu, enjoying a full Windows 11 experience while moving between your local and Cloud PCs. Supported by all Windows 11 devices, the app delivers high-performing and reliable experiences optimized for Microsoft Teams and your other Microsoft 365 apps.
Single Sign on – To provide a seamless user experience while also reducing the risk of credential theft in your environment, we will soon be releasing single sign-on features as part of Windows 365.

Read all the announcements here: What’s new in Windows 365: Microsoft Ignite 2022 edition – Microsoft Community Hub

Deploy Dropbox as a Win32 App with Intune

Package Dropbox as a Win32 app to deploy it using Microsoft’s Intune

Dropbox is a widely adopted platform to save and share your documents. Although Microsoft’s OneDrive may be the most logical choose when using Microsoft products there still are companies actively using Dropbox as their cloud file storage solution. In this blog I will share how to deploy the Dropbox client in your organization by using Intune. This is what you need:

The Win32 Content Prep Tool https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool
The latest version of Dropbox. You can find the installation from the Dropbox download site https://help.dropbox.com/installs-integrations/desktop/enterprise-installer

On your PC create a new folder. The folder will contain three files: The Dropbox installer you downloaded and you create 2 additional files, an install.cmd and an uninstall.cmd file.

For the install.cmd you use the following lines:

@ECHO OFF
PUSHD "%~dp0"
"Dropbox 139.4.4896 Offline Installer.exe" /NOLAUNCH

You can validate the command by running the install.cmd as an admin.

For the uninstall.cmd file you use the following lines:

@ECHO OFF
"%PROGRAMFILES(x86)%\Dropbox\Client\DropboxUninstaller.exe" /S

Also on your machine take a look in the registry which version is installed. Apparently the version that the installer states is different than what is found in the registry. You can check the version in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Dropbox\Client

Now that you have prepared the files its time to wrap them into a intunewin file.

Source folder: specify the files which contains your installation files
Setup file: is the Dropbox offline installer files
Output folder: a folder where you want to save the intunewin file. Choose a different location than your source folder
For catalog folder choose no

Now that you have prepared Dropbox its time to deploy it via Intune. Follow this link to get to Windows Applications https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/AppsWindowsMenu/windowsApps

Choose Add and for App type Windows app (Win32). For package file select your Dropbox intunewin file. Fill out the required app information and choose next.

At the second step for the install command enter install.cmd and for the uninstall command choose uninstall.cmd. The install behavior should be set to System.

At the requirements choose the system architecture and a minimal operating system version. The fourth step is the detection rules. For Rules format choose Manually configure detection rules:

Rule type: Registry
Key path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Dropbox\Client
Value name: Version
Detection method: Version comparison
Operator: Equals
Value: 139.4.4896 ( or whatever value you installed)

Finally assign the application to a user or computer group, and wait for the installation to take place.

Hope this blog was helpful, if you have any questions feel free to post them in the comments.

Deploy Zoom as a Win32 App with Intune

Deploy the Zoom client and the Zoom Outlook plugin using the Win32 app format in Intune

In this article I will show you how to can deploy Zoom as a Win32 app using Microsoft’s Intune. When following the guidelines from Zoom, they only show you how to deploy Zoom by using the Line-Of-Business method. Although this works you get much greater flexibility when deploying Zoom as a Win32 app. You can make use of delivery optimalization and better targeting to for example only 64-bit operating systems and more. Furthermore, when you want to deploy new clients via Autopilot you cannot mix line-of-business installations with Win32 app installations. So I would always be my recommendation to use the Win32 app deployment.

You need:

Personally I always like to work with and install.cmd and a uninstall.cmd to deploy my applications. You can however just repackage the msi installer and use the commands in the installation parameters in Intune. When using the install.cmd and uninstall.cmd files I can be more flexible when I need to copy files for example.

Copy the ZoomInstallerFull.msi to an empty folder. Create two new files in the folder named install.cmd and uninstall.cmd. The Zoom msi comes with a variety of installation parameters to customize your deployment as needed. You can for example disable auto update and to configure the required firewall ports. You can also use zConfig to set configurations that cannot be changed or use ZRecommend to make settings users can change. In my example I use the following installation command, which is the command in the install.cmd file:

msiexec /i "%~dp0ZoomInstallerFull.msi" /norestart /qn ZConfig="nogoogle=1;nofacebook=1;" ZoomAutoUpdate="false" FirewallPortStart="7200" FirewallPortEnd="17210"

You can test your install.cmd by running it as an administrator. For the uninstall.cmd you use the following command:

msiexec  /x {51AFD52B-0614-4100-91E0-204AC1EF0A3B}

You can find the GUID for the application in the registry HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{51AFD52B-0614-4100-91E0-204AC1EF0A3B}

You now should have a folder containing ZoomInstallerFull.msi, install.cmd and uninstall.cmd.

Start the Win32 Packaging tool and enter the following parameters:

The location of your source folder containing the ZoomInstallerFull.msi, install.cmd and uninstall.cmd.
The setup file is ZoomInstallerFull.msi
Create a new output folder where you want to save the new package.
Select no for creating a catalog folder

To deploy the application with Intune go ahead and add a new application and for app type choose Windows app (Win32)

On the App information page, provide the Naam, Publisher, app Version and whatever information you want to share. At the program page use install.cmd for the installation command and uninstall.cmd for the uninstall command. For install behavior make sure to select system. Finally select No specific action for device restart behavior.

At the Detection rule page I like to use the version number to detect if the application is installed. I you want to deploy an other version in the future you can use the Supersedence option which makes detecting on a specific version easier. So fo the Detection rules choose Manually configure detection rules:

Rule type: Registry
Key path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{51AFD52B-0614-4100-91E0-204AC1EF0A3B}
Detection method: Version comparison
Operator: Equals
Value: 5.9.2481 (or whatever version you are deploying)

Finally deploy the application to a group in your organization.

To install the Zoom plugin for Microsoft Outlook you can use the same procedure. Create a folder which contains: ZoomOutlookPluginSetup.msi, install.cmd and uninstall.cmd.

Install.cmd

msiexec /i "%~dp0ZoomOutlookPluginSetup.msi" /norestart /qn

uninstall.cmd

msiexec /x "{BC6BA982-1260-4284-8B1F-68184984021B}" /q

Start the Win32 Packaging tool and enter the following parameters:

The location of your source folder containing the dp0ZoomOutlookPluginSetup.msi, install.cmd and uninstall.cmd.
The setup file is dp0ZoomOutlookPluginSetup.msi
Create a new output folder where you want to save the new package.
Select no for creating a catalog folder

Deploy the package using Intune using the same options as for the Zoom client. For detection rules use:

Rule type: Registry
Key path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{BC6BA982-1260-4284-8B1F-68184984021B}
Detection method: Version comparison
Operator: Equals
Value: 5.9 (or whatever version you are deploying)

Hopefully you found the article informative. I you have any question or comments feel free to use the comments section below.

Configure Windows 10 Web sign in – 2

Configuring Windows Web Sign in with Intune – 2

I wanted to write a quick follow up to my the Configure Windows 10 Web sign in article. Since then Microsoft has made the configuration of the Web Sign in functionality a lot easier. Further more this feature can now also to used in combination with Temporary Access Passes, a new functionality in Azure AD.

In stead of using custom OMA-URI policies you can now use the Session Catalog to configure web sign in. To use the Session Catalog create a new Device Configuration Profile targeted to Windows 10 and for profile type you select Settings Catalog

Give your Profile a name and a clear description, and select Next

In the Configuration Settings tab, select Add Settings. Here you select Authentication, and select Enable Web Sign in and you can optionally select Preferred Aad Tenant Domain Name.

Close the Settings picker and you now have two options you can configure. For the Enable Web Sign In select Enabled. Web Sign-in will be enabled for signing in to Windows. For Preferred Aad Tenant Domain Name you can enter the domain name of your tenant. This will ensure the user will get a themed version of the sign in window (if you have any customizations).

Choose next and assign the policy to an group that contains computer objects.

Hope this quick follow up helps you with configuring Windows Web Sign in.

Deploy Acrobat Reader DC with Intune

Use Intune to deploy an up to date version of Adobe Acrobat Reader DC using the Win32 app deployment.

One of the first applications that is put on the list to distribute with Intune is Acrobat Reader DC. There are several blogs that describe how to do this, however they all use the default Adobe Acrobat Reader DC Distribution executable. Only installing this executable will get you the 2015 version 2015.07.20033, which is by now (2021) extremely out dated. This article will focus on how to deploy an up to date version of Adobe.

First you still need the default Adobe Acrobat Reader DC Distribution executable, which you can download from https://get.adobe.com/uk/reader/enterprise/ . Select your required operating system, language and version. Once you have downloaded the exe you will need to extract the contents of the exe. You do this by adding the following switches after the exe. Specify your own output location.

.\AcroRdrDC1900820071_nl_NL.exe -sfx_o"C:\InstallFiles\Blog\Extract" -sfx_ne

Next you need to download the latest update from Adobe. Writing this blog this is the September 2021 update, which you can download from https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/continuous/dccontinuoussept2021.html Download the Reader update. Make sure to choose correct bit version. In my case I need the AcroRdrDCUpd2100720091.msp file.

Place the download update in the same folder where you extracted the content of the executable. In the same folder you create two files. The first is named install.cmd and the second is called uninstall.cmd

The content of the install.cmd file is:

msiexec /i "%~dp0AcroRead.msi" ALLUSERS=1 /qn TRANSFORMS="AcroRead.mst" /Update "%~dp0AcroRdrDCUpd2100720091.msp" /norestart

Here its important that you reference the correct update file which in this case is AcroRdrDCUpd2100720091.msp.

You can use the Adobe Customization Wizard DC to further customize your Adobe installation . This will generate the mst file which is also referenced in the install.cmd file. I wont to in to detail, there are plenty of blogs which will explain this.

The contents of the uninstall.cmd file is

msiexec /x "%~dp0AcroRead.msi" /q

The content of your Adobe folder should look quite similar like this:

Test you installation by running the install.cmd and the uninstall.cmd files before continuing to the next steps.

You are now ready to put all the contents of your Adobe folder into a Win32 package and distribute it to your clients. First use the Win32 wrapper to combine all the files into a single package. If you need more information on how to do this please read this article.

Source folder: Is the location where all the Adobe files are located
Setup file: in this case it’s setup.exe
Output folder: location where the intunewin file is saved
Catalog folder: choose no

When you have your .intunewin file you can upload this to Intune and start deploying it. I won’t go in to detail but some points to take in to account:

At Program:

Install command: install.cmd
Uninstall command: uninstall.cmd

At Detection Rules use:

Manually configure detection rules and use the Registry Rule type:

Key Path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{AC76BA86-7AD7-1043-7B44-AC0F074E4100}
Value Name: DisplayVersion
Detection method: String Comparison
Operator: Equals
Value: 21.007.20091 (or whatever version you install)

Hope this article gives you some more information on how to deploy an up to date version of Adobe Acrobat Reader with Intune.