Custom images

 You can use custom images (also referred to as a golden image) if desired. To do so, you need to pre- load your images via Azure as a Managed Image or the Shared Image Gallery. To learn more about creating custom images with Windows 365, see https://learn.microsoft.com/en-us/windows-365/ enterprise/add-device-images.

To get the benefits, like simple and unified management options of modern management, we strongly recommend using the gallery images included in Windows 365 and using Intune to install applications. While in VDI, you may have updated your image on a weekly basis, using a gallery image eliminates the challenge of repeatedly updating your custom image whenever a single component changes. All images will be updated monthly by Microsoft at patch Tuesday. We recommend customers use Win- dows Autopatch to simplify Windows Updates in conjunction with Windows 365.

Figure : Selecting Windows 365 images

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

The transition to modern management with Microsoft Intune

 Microsoft Intune is an integrated solution that simplifies management across multiple OSs, cloud, on-premises, mobile, desktop, and virtualized endpoints including Cloud PCs, and it lowers the Total Cost of Ownership (TCO). It empowers organizations to provide data protection and endpoint com- pliance that supports a Zero-Trust security model. This unified management tool brings together device visibility, endpoint security, and data-driven insights to increase IT efficiency and improve user experiences in any work environment.

Figure : The path to modern IT

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Microsoft Intune device limit restrictions for Windows

In this article, we will learn how to limit the restrictions for a device. Let’s get started.

To configure the enrollment restriction for Windows, follow these steps:

1.  In the Microsoft Intune admin center, go to Home | Devices | Windows | Windows Enrollment | Device limit restriction and Create restriction:

•  Name: Enter Device limit restriction – HR

 Figure : Microsoft Intune admin center – Device limit restriction

2. You can set Device limit to a number from 1 to 15. The default in Microsoft Intune is a limit of 5:

Figure : Microsoft Intune admin center – Device limit restriction

3. For the Assignments step, select HR Department.

When you are creating a custom enrollment restriction, you can scope it to apply to specific user groups in your organization, departments, countries, and so on:

Figure: Microsoft Intune admin center – Device limit restriction – Assignments

4. In the following screenshot, you can see an overview of the default device limit restrictions.

Figure : Microsoft Intune admin center – Enrollment restriction – an overview

If you have restricted personal enrollment, your end users will be met with the Something went wrong screen if the devices are Entra joined and the devices are not in the Windows Autopilot service:

Figure : Windows 11 – an OOBE error

In the Something went wrong screenshot, note the error code 80180014; this means that you are blocked from MDM enrolling your devices. However, as you have configured automatic MDM enrolment for your devices, Intune enrolment restriction will cover you here and ensure that your end users are only able to enrol corporate-owned Windows devices. If the error message came from Entra ID when joining the device, it would have been a different message.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Microsoft Intune device restrictions for Windows

 In this article, we will see how to create enrollment restrictions for Windows devices:

1.  Sign in to the Microsoft Intune admin center (intune.microsoft.com). 

2.  Select Devices | Enrollment device platform restrictions:

Figure : Admin center – Enrollment device platform restrictions

3.  Create a restriction. Enter Device type restriction – HR as the name:

Figure : Admin center – enrollment restrictions

4.  Select the block and allow both for MDM and personally owned devices to allow or block Windows enrollment.

If you are allowing Windows (MDM) platform enrollment, you can block personal devices; see the following section to understand what blocking personal Windows devices means.

Allow min/max range for the OS version only blocks devices on enrollment and has no effect on devices already enrolled into Microsoft Intune; enrollment restriction is only validated on enrollment.

Figure : Command Prompt – ver

5. For the Assignments step, select HR Department.

When you are creating a custom enrollment restriction, you can scope it to apply to specific user groups in your organization, departments, countries, and so on.

Change the assignment settings to filter, based on any restrictions you want to provide to avoid groups from enrolling into MDM Intune:

Figure : Admin center – enrollment restrictions – Assignments

6. In the following screenshot, you can see an overview of the default device type restrictions:

Figure : Admin center – Windows restrictions

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Using Azure Virtual Desktop with Microsoft Intune

The following steps are not needed within Windows 365, as the enrolment into Intune happens automatically. Also, make sure that you have followed the previous step (setting MDM user scope to All and MAM user scope to None) before continuing.

Prerequisites:

•  Running Windows 10 Enterprise, version 1809 or later, or running Windows 11.

•  Set up personal remote desktops in Azure.

•  Microsoft Entra hybrid joined and enrolled in Intune in one of the following methods:

            •  Configure Active Directory group policy to automatically enrol devices that are Microsoft Entra                 hybrid joined.

            •  Configuration Manager co-management.

            •  User self-enrollment via Microsoft Entra join.

            •  Microsoft Entra joined and enrolled in Intune by enabling Enroll the VM with Intune in the                        Azure portal. 

Keep in mind that the following Windows 10 desktop device remote actions aren’t supported/recom- mended for Azure Virtual Desktop virtual machines:

•  Autopilot reset

•  BitLocker key rotation 

•  Fresh start

•  Remote lock

•  Reset password

•  Wipe and Retire

Deleting VMs from Azure leaves orphaned device records in Intune. They’ll be automatically cleaned up if the built-in cleanup rules are configured for the tenant.

Let’s get started configuring the GPO that configures automatic MDM enrolment for Hybrid Entra joined devices with a device token:

1.  Log on to your session host.

2.  Open Local Computer Policy and click Administrative Templates | Windows Components | MDM:

Figure : Local group policy – MDM

3. Set the policy to Enabled.

4. Set the credential type to Device Credential:

Figure : Local group policy – MDM

5.  Confirm the MDM enrollment of your session hosts into Entra, which should look like the following examples:

Figure : Admin center – all Windows devices

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Enabling Windows automatic enrollment

 Automatic MDM enrolment means when a Windows device joins Entra, the device will automatically be enrolled into Intune with the MDM enrollment flow.

To configure automatic Windows enrollment, follow these steps:

1.  In the Microsoft Intune admin center, go to Devices | Windows | Windows enrollment followed by Automatic Enrollment:

Figure : Microsoft Intune admin center – Windows automatic MDM enrollment

User enrollment can also be scoped to a group of users, if all your users have an Intune license assigned. The best option is to leverage Intune enrollment restriction to configure which Windows devices a user can enroll.

2.  Make sure to select All for MDM user scope:

Figure : Microsoft Intune admin center – MDM user scope

Here’s what all the options for MDM user scope mean:

            •  None: MDM automatic enrollment is disabled.

            •  Some: Select the groups that can automatically enroll their Windows devices. 

            •  All: All users can automatically enroll their Windows devices.

For Windows Bring Your Own Device (BYOD) devices (personal enrollment), the Mobile Application Management (MAM) user scope takes precedence if both the MAM user scope and the MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users).

The Windows Information Protection without enrollment scenario in Microsoft Intune is no longer supported, and you are not able to create a new policy for that scenario.

If you encounter a warning like this:

Figure : Microsoft Intune admin center – Automatic MDM enrollment

It means that you do not have an active Entra ID Premium subscribe in your tenant.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Intune Administrator Licensing

 All Intune administrators need a Microsoft Intune license by default. You can change this in the Mi- crosoft Intune admin center (https://intune.microsoft.com) at a later point, allowing you to give administrators access to Microsoft Intune without requiring an Intune license.

To get an administrator license, you need to follow these steps:

1.  Go to Tenant admin | Roles | Administrator Licensing. 

2.  Click Allow access to unlicensed admins:

Figure : Microsoft Intune admin center – Administrator Licensing

Figure : Microsoft Intune admin center – Administrator Licensing after the change

3.  In the Microsoft 365 admin center, go to https://admin.microsoft.com. If you are a global admin, you can assign your Intune license:

Figure : Microsoft 365 admin center – license assignments

The Microsoft Intune license is a part of Microsoft 365 E3/E5, Microsoft 365 F1/F3 for Firstline Workers, EMS E3, as well as standalone Microsoft Intune.

There are many other licenses that give you access to Microsoft Intune. Always consult your license partner to find out the correct license for your scenario.

A user in your tenant also requires a license to enrol their device into Intune.

One suggested approach for allocating Intune licenses to your users is to utilize Entra group-based licensing.

Entra group-based licensing

Microsoft paid cloud services, such as Microsoft 365, EMS, Windows 10, Office 365, Dynamics 365, and other similar products, require licenses. These licenses are assigned to each user who needs access to these services. Administrators use one of the management portals (https://admin.microsoft.com or https://entra.microsoft.com) and PowerShell cmdlets to manage licenses. Entra is the under- lying infrastructure that supports identity management for all Microsoft cloud services. Entra stores information about license assignment states for users.

Entra includes group-based licensing, which means one or more product licenses can be assigned to a group. Entra ensures that the licenses are assigned to all members of the group. This includes non-members who then become a member of the group. When they leave the group, those licenses are removed. This licensing management eliminates the need for automating license management via PowerShell to reflect changes in an organization and departmental structure on a per-user basis.

For any group assigned a license, you must also have a license for each unique member. While you do not have to assign each member of the group a license, you must have at least enough licenses to include all the members. For example, if you have 10,000 unique members who are part of licensed groups in your tenant, you must have at least 10,000 licenses to meet the licensing assignment.

Licenses can be assigned to any security group in Entra. Security groups can be synced from on-prem- ises using Entra Connect. You can also create security groups directly in Entra (also called cloud-only groups), or automatically via the Entra dynamic group feature. Office 365 groups cannot be used for group-based licensing.

When a product license is assigned to a group, one or more service plans in the product can be dis- abled by the administrator. Typically, this assignment is done when the organization is not yet ready to start using a service included in a product. For example, the administrator might assign Microsoft 365 to a department but temporarily disable the Yammer service.

Entra automatically manages license modifications that result from group membership changes. Typically, license modifications are effective within minutes of a membership change.

A user can be a member of multiple groups with license policies specified. A user can also have some licenses that were directly assigned, outside of any groups. The resulting user state is a combination of all assigned product and service licenses. The license will be consumed only once if a user is assigned the same license from multiple sources.

In some cases, licenses cannot be assigned to a user. For example, there might not be enough licenses available in the tenant or conflicting services might have been assigned at the same time. Adminis- trators have access to information about users for whom Entra could not fully process group licenses. They can then take corrective action based on that information.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Using Intune filters when assigning

 Intune filters is a feature of Microsoft Intune that enables administrators to filter and target specific groups of devices or users based on certain criteria. It helps admins in application or policy assign- ments, and filters help to remove some of the conflicts in application deployments. With filters, you as IT admin have more flexibility when it comes to assignments. This means that you can assign to a group of users or devices and leverage the filter to include or exclude devices based on attributes that are supported with filters. Filters are evaluated promptly when devices check in to the Intune service, making them significantly faster than Entra dynamic groups, which operate on a scheduled basis.

We will give you some examples of filters that can be useful when assigning different apps, policies, etc. To start creating filters, you need to follow these steps:

1.  In the Intune portal, go to Tenant admin | Filters.

2.  Click Create.

3.  In the first example, we will create a filter for AVD Multi session.

            •  Enter a Filter name: AVD Multi session

            •  Select a Platform: Windows 10 and Later

Figure : AVD Multi session filter 

4.  In the Rules section, fill in the following details:

            •  Choose a Property | rule builder: operatingSystemSKU (Operating System SKU) 

            •  Operator: Equals

            •  Value: ServerRdsh (Windows 10/11 Enterprise multi session (175))

Figure : Value ServerRdsh 

This gives you a rule syntax (device.operatingSystemSKU -eq "ServerRdsh").

Here are some other examples of rule syntax: 

            •  Windows 11 filter:

                    •  (device.osVersion -startsWith "10.0.22")

            •  Manufacturer filters:

                    •  (device.manufacturer -eq "Microsoft")

                    •  (device.manufacturer -eq "LENOVO")

            •  Model filters:

                    •  (device.model -eq " Surface Pro 9")

                    •  (device.model -in ["Surface Book 3", "Surface Book 2"]) 

                    •  (device.model -startsWith "Surface Book")

            •  Enrollment profile name:   

                    •  (device.enrollmentProfileName -eq "Autopilot HL2")

                    •  (device.enrollmentProfileName -eq "Windows Autopilot Local admin")

                    •  (device.enrollmentProfileName -startsWith "Windows AutoPilot KIOSK")

            •  deviceTrustType (Microsoft Entra join type):

                •  (device.deviceTrustType -eq "Azure AD  joined")

                •  (device.deviceTrustType -ne "Azure AD  registered")

                •  (device.deviceTrustType -in ["Hybrid Azure AD  joined","Azure AD  joined"])

When using some of the filters that we just have described, like an OS version such as device.osVersion, you can target a policy or apps more dynamically than with Entra groups alone. You can deploy a spe- cific Win32 app that is hardware vendor-specific, which means it only applies to that hardware type. An example of that could be Lenovo or HP update tools that you only want to deploy to those models. Another example is creating a compliance policy where you want to exclude HoloLens, as they do not support the same policies as Windows Desktop does.

Possibilities with filters:

•  Assign policies and apps to a specific group of devices or users based on criteria in your filters. 

•  Dynamically target managed devices based on a device.

•  Include or exclude devices or apps in a specific group based on the criteria you enter.

•  Create a query of device properties based on different properties, like TrustType, an enroll-ment profile, model, vendor, etc.

In addition, using filters can help you reduce latency in an assignments workload and improve de- ployment performance, especially in large Intune environments, as filters are evaluated with device check-in into Microsoft Intune, unlike Entra dynamic groups that run on a schedule.

This concludes the section on Intune filters; next up, we have a list of built-in Entra roles that are supported within Microsoft Intune. These roles can be set using the Entra admin portal.

Thant Zin Phyo@Cracky (MCT, MCE, MVP)

Name resolution scenarios and options

Name resolution scenarios and options

DNS servers host records that translate human-readable domain names into machine-readable IP addresses (used by computers to communicate with each other). For example, Figure shows the DNS server for the azurecourses.xyz domain zone, which has a single A record that translates the www.azurecourses.xyz hostname into the IP address 1.2.3.4. Clients that want to communicate with the web server called www.azurecourses.xyz can make a DNS request to their DNS resolver to translate the name into an IP address. The DNS resolver will then go through an iterative process to make a record request to the DNS server.

Figure – DNS server and name resolution

To facilitate network communications, there are two name resolution scenarios that we will cover:

• Internal name resolution: Providing name resolution for private/internal clients hosted in our virtual networks
• External name resolution: Providing name resolution for public/internet clients that need to access our public/internet-facing applications and services

Let’s start with the internal scenario and the options that we have to implement this.

Internal name resolution scenarios and options

Azure virtual network workloads need to be able to resolve internal and external domain names to IP addresses. A comprehensive Azure internal name resolution implementation should cover the translation of domain names for the following scenarios:

• Scenario 1 – name resolution for resources within the same virtual network

• Scenario 2 – name resolution for resources in different virtual networks

• Scenario 3 – name resolution for resources in connected on-premises networks (hybrid)

• Scenario 4 – name resolution for public domain names from VNet resources

Figure shows an example of this. By making name resolution requests to its DNS resolver (server), VM1 (deployed into Azure VNET-1) should be able to resolve the private IP address for VM2 (deployed into a separate subnet in the same Azure VNet), it should be able to resolve the private IP address for VM3 (deployed into another Azure VNet), it should be able to resolve the private IP address for VM4 (deployed into a connected on-premises network), and it should also be able to resolve public IP addresses for internet domain names. Of course, implementing these scenarios depends on what you are trying to achieve with your network architecture.

Figure – Internal name resolution for Azure workloads

So, what options can we implement to cover these scenarios? Which we can implement Azure virtual network internal name resolution scenarios:

Azure-provided name resolution

This is the default name resolution option for virtual network workloads. Anytime we create a new virtual network in Azure, the platform configures it to use this default option (Figure 2.9) and assigns a unique private DNS suffix to it in the <auto_generated_random_id>.internal. cloudapp.net format. Azure’s DHCP will also assign this DNS suffix to each VM in the virtual network to ensure that each host is resolvable within the VNet, using a Fully Qualified Domain Name (FQDN) of <vm _name>.<auto_ generated_random_id>.internal.cloudapp.net. If this does not make sense to you, don’t worry too much about it, as you will explore this in an upcoming hands-on exercise.

 

Figure  – Default VNet DNS server configuration

This default Azure-provided DNS server uses a virtual IP address of 168.63.129.16 to receive and respond to name resolution requests, as shown in Figure . This IP limits the number of requests from each VM to 1,000 requests per second. Anything above this gets throttled and queued.

Figure – Azure-provided DNS

The main advantage of this option is that it works out of the box, and we do not need to provision or manage our own DNS service for VMs within a VNet to resolve each other’s names. However, in terms of capabilities, it is quite limited! For example, it can only cover scenario 1 (name resolution for resources within the same virtual network) and scenario 4 (name resolution for public domain names from VNet resources) out of the four scenarios that we listed earlier.

There are other limitations with this option, including the following:

•      We have no ability to customize the configuration. For example, we cannot modify the auto- generated default DNS suffix assigned to our VNet (which is not very user-friendly). We cannot manually add additional DNS records to it beyond what is auto-registered. We cannot configure DNS forwarding for it so that it can resolve names using other internal DNS servers.

•    We cannot enable or configure logging capabilities. DNS logs may contain insights that could be used to detect active threats.

•      There is no WINS or NetBIOS support.

That’s a lot of limitations! Alright, that’s enough theoretical information – let’s get our hands dirty and explore this option in an Azure environment.

In the next hands-on exercise, you will explore the first option for internal name resolution in Azure – Azure-provided DNS.

 

A hands-on exercise – exploring Azure-provided name resolution

In this exercise, you will review and test the capabilities of the Azure-provided DNS option. Here are the tasks that we will complete in this exercise:

•      Task 1: Review and test the default name resolution option

Task 1 – reviewing and testing the default name resolution option

The steps are as follows:

1. In the Azure portal, in the search area at the top of the screen, type CoreServicesVNet 

and click on the virtual network resource that was created in the previous exercise.

Figure – Select the CoreServicesVnet resource

 

2.   In the CoreServicesVnet blade, click on DNS servers (in the Settings section). You should see here that the virtual network is configured as Default (Azure-provided). Leave the configuration as it is.

Figure – Review the default DNS server configuration

1.                  3. Go back to the SSH session that you previously opened in WebVM (if the session is closed, reconnect to it again). Review the default DNS client configuration with the following command:

You should see here that the virtual machine is configured to send name resolution requests to a virtual IP address of 168.63.129.16. You should also see the auto-generated DNS suffix here (it is not very user-friendly, is it? And remember that we cannot customize this name). Both values were provided to the client by Azure’s DHCP.

Figure 1 – Review the default DNS configuration for a VM

4.        Use the following commands to resolve the hostnames of VMs in the same virtual network as WebVM:

All the names should resolve successfully, as shown in the following screenshot. It works out of the box! Also, note that we didn’t need to specify the FQDN with the DNS suffix. It resolves with just the hostname. This is because the DNS suffix is in the search list that we reviewed in the previous step.

Figure 2.14 – Name resolution of the same VNet workloads

5.      Use the following commands to perform reverse DNS lookups for VMs in the same virtual network as WebVM:

All IP addresses should resolve successfully, as shown in the following screenshot. It works out of the box!

Figure 2.15 – Reverse DNS lookup of the same VNet workloads

6. Use the following commands to perform forward and reverse DNS lookups for VMs in a different virtual network:

Both lookups should fail, as shown in the following screenshot. The scope of the default Azure- provided DNS is limited to a virtual network! And because we don’t have access to modify its configuration, this cannot be changed.

Figure – Forward and reverse DNS lookup of workloads in a different VNet

7. Enter the following command to review how requests to the virtual IP address (168.63.129.16) are routed:

           8. Here is the output from the preceding command. As you can see, requests are routed through the defaul                      gateway of the Azure subnet.

Figure  – Azure-provided DNS route review

Thant Zin Phyo@Cracky (MCT, MCE, MVP)