MDM & GP Tips Blog

Personal Data Encryption (PDE) is a security feature introduced in Windows 11, version 22H2 that provides an additional encryption capability to Windows. PDE is different than BitLocker in that it encrypts individual files while BitLocker encrypts entire volumes. PDE utilizes Windows Hello for Business to link encryption keys with user credentials. This means you need only log on a single time while BitLocker requires a separate PIN be inputted. Another difference is that unlike BitLocker that releases data encryption keys at bootup, PDE releases them once a user signs in using Windows Hello for Business. Until then, users cannot access the protected file content.

There are 3 prerequisites for PDE:

1. The computer must be Azure AD joined
2. It must be running the Enterprise or Education edition of Windows 11, version 22H2 or later
3. Windows Hello for Business Overview

Windows Hello provides fully integrated biometric authentication based on either facial recognition or fingerprint matching. Many laptops today have fingerprint readers or integrated compatible cameras to support it.

You should consider PDE as just another encryption layer for Windows on top of BitLocker that administrators can use to safeguard sensitive data. Don’t be confused by its name because standard users cannot initiate PDE, nor can they protect personal files with it. When you stop to think about it, it makes sense as you wouldn’t want malicious insiders to use it to hide data they shouldn’t have on their corporate devices. PDE can only be implemented by administrators who also selectively choose which filles to encrypt. PDE is ideal for business applications that work with sensitive files and should be heavily considered by those organizations that must adhere to compliance requirements.

You can enable PDE through Intune. By default, PDE on Windows 11 Devices in the Intune settings catalog is disabled. There are two ways to enable PDE in the Microsoft Intune Admin Center. The easiest way is to navigate to Devices > Configuration profiles and choose the Settings catalog as the profile. Using the Settings picker, search for personal data encryption and select the PDE category. Then check enable “Personal Data Encryption” as shown below.

Assign the policy to the designated groups or users and save it. You can also use OMA-URI settings to create the policy using:

./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption

as the OMA-URI path.  Then choose integer as the data type with an assigned value as 1. The final configuration should look like the screenshot below.

While support for PDE is limited currently, more applications will utilize it in the future.  

If you have ever worked with Window Group Policy, you may have used WMI filtering to target the application of your GPOs to a specific set of computers or users based on their characteristics. You could for instance create a WMI filter to apply a policy only to computers running a specific version of Windows or systems with a set amount of RAM or IP subnet.

Microsoft Intune doesn’t utilize WMI filtering but it does use Azure Dynamic Groups which has a similar outcome. Dynamic groups automatically manage group membership based on user or device attributes in Azure AD. The membership of a dynamic will automatically update when the designated attributes of a device or user change. Automated group management relieves administrators from the task of manually adding or removing users or devices from groups as their attributes change. Imagine if your company had a lot of employee turnover or recently implemented a laptop refresh? Dynamic groups can then be used to assign policies to a set of users or devices.

Let’s start with a basic example. Let’s say you manage a fleet of corporate laptops running either Windows 10 or Windows 11 and you want to create policies that will specifically target each operating system. To create a Windows 11 dynamic group, use the Microsoft Intune admin center and go to Groups and click on New Group. Select “Security” as the Group type, give a group name and optional description and select Dynamic Device as the Membership type as shown in the screenshot below. Then click Add dynamic query.

Here you will add the expression(s) that will govern the group’s membership. As shown in the screenshot below, I selected “deviceOSType” as the Property, “Starts With” as the Operator and typed 10.0.2 as the value. Notice that the input values automatically appeared in the Rule syntax underneath.

Before clicking Save to create the group, you can first validate the rule(s) to ensure that they will apply the desired result. Copy the Rule syntax and click on “Validate Rules.” Paste the text into the Rules syntax box and select a device to run the validation with.

Once validated and saved, you can apply configuration policies to the new dynamic group. Let’s do another example where I want to create a dynamic group for three models of Dell laptops. In the example below I chose “deviceModel” from the Property drop down menu as well as the “Contains” Operator and then made an expression for each Dell model as shown below.

Note that you cannot add more than 5 expressions using the rule builder. If you need to work with more than 5 expressions, you need to add them directly into the rule syntax box. Here is an example below in which the rule builder is no longer available to edit the rule.

You can create dynamic groups for users as well. Simply create a new group and select “Dynamic User” as the Membership type and click “Add dynamic query” as shown below.

Here you will see a separate set of properties available for users. In the example below I chose “department” and “city” as the two Property attributes and assigned them values so that only salespeople in the Atlanta office will be added to the group. Should someone be transferred to a different office, that account will be automatically removed from the group.

As you can see, dynamic groups can simply group management in large dynamic organizations. They are a great way to ensure that policies, access rights and licenses are delivered according to real-time user and device attributes.

From websites to email and SaaS applications, the web browser is now the go-to app for your users. Optimizing the user digital experience often starts with optimizing their browser environment. Whether you implement Group Policy or Intune, you need to create a policy for your organization’s preferred browser, and we are going to do just that. I have chosen Edge because it is generally easier to secure with these two management tools. There are so many settings in Edge that GP and Intune can manage. We are just going to outline some of the basics that serve as a good start.

Enforce Bing and Google SafeSearch

Most organizations want to filter out explicit or inappropriate content from search results. If you don’t have an enterprise web filter or just want to create a backup policy in case your filter goes down, you can enforce Bing SafeSearch and Google SafeSearch. For Intune, go to Devices > Configuration profiles > Create profile. Select Windows 10 and later as the platform and Templates > Administrative Templates as the Profile type. Then go to User Configuration > Microsoft Edge and find the settings “Enforce Bing SafeSearch” and “Enforce Google SafeSearch.” In the example below I chose moderate search restrictions which will filter adult images and videos but not text.

You can do the same using Group Policy by following the same Administrative Template path as shown in the screenshot below.

Restrict Access to Developer Tools

In our previous example, you had to sift through multiple pages of settings until you could access the Enforce SafeSearch settings. For instance, the first page of settings for Microsoft Edge only contains two settings as shown here.

This time we will restrict user access to the developer tools in the Edge browser. To make it easier to find the desired setting, let’s use the Settings catalog for the profile type rather than the Administrative templates. Using the Settings Catalog, do a search for the word “developer” and then click on Microsoft Edge in the results as shown below.

Then enable the “Control where developer tools can be used (User) and select “Don’t allow using the developer tools” in the drop-down menu as I have done in the example below.

In Group Policy, you can use the Filter to quickly find the exact setting you need. Simply filter the word developer as shown in the screenshot below.

Then navigate to User Configuration > Microsoft Edge and configure the “Control where developer tools can be used” setting as shown in the screenshot below.

Managing Installed Web Extensions

You want to have control over what browser extensions your users will have. Let’s start with which extensions will be allowed. Using Intune, use Administrative Templates once again as your profile type and navigate to Microsoft Edge > Extensions and enable “Allow specific extensions to be installed.” You will then have to input the ID for each web extension. I the example below I have added the ID for Microsoft Translator (gjknjjomckknofjidppipffbpoekiipm), followed by Adobe Acrobat (klcieihbeepdihlppjcammejcejholkl). Note that the extension IDs are different for each web browser.

We can do the same thing using Group Policy for the LastPass web extension ID (nngceckbapebfimnlniiiahkandclblb).

You would then follow this up by enabling the “Blocks external extensions from being installed” setting to prevent all other extensions from installing as shown in the screenshot below.

Configuring the Home Page

We will wrap up this discussion by assigning a mandatory home page for all users. You can find this setting in Group Policy by going to Administrative Templates > Microsoft Edge > Startup > and enabling the “Configure the home page URL” setting and inputting the desired home page.

You can do the same with Intune as shown in the screenshot below.

Of course, there are many other settings you can add to your Edge policy. Always test your setting configurations first before implementing them in a production environment.

Many K12 school districts are concerned about providing a secure environment for online testing. The integrity of online testing relies on the ability to prevent students from opening a new browser tab to google for answers or copy exam question text to an archive. Take a Test is a secure browser provided by Microsoft that can be set up to only provide access to a single URL or a list of URLs. Students cannot perform the following actions when taking an exam using Microsoft Take a Test:

• Access other applications
• Open another browser tab
• Print or use screen capture
• Change system settings
• Access Cortona
• Access content copied to the clipboard

Microsoft Take a Test is a secured instance of Intune, not an application. There are 2 modes for Microsoft Take a Test. The first is intended for a brief test or quiz that a teacher might wish to administer. By creating a secure assessment URL and sending it to students via email or OneNote, teachers may accomplish this task quickly and easily. The assessment link is constructed in three stages using Microsoft's secure link generator.

• Paste the link to the assessment URL
• Select the options you want to allow during the test
• Generate the link by selecting the button Create link

Below is a screenshot of the secure generator page.

When the students click on the link, Edge will open a secure test taking session for the student to take the exam. Keep in mind that the student must be logged on to a Windows machine already. This deployment method would be a challenge for a large-scale exam such as a high school proficiency or college entrance exam. This is where the Take a Test in Kiosk Mode is better suited. This mode can be deployed using either regular Intune or Intune Education edition.

Intune Education edition is specifically designed to meet the needs of schools and provides a simpler interface than regular Intune. Intune Education edition is the easiest way to deploy Take a Test in kiosk mode as the settings are available in the menu interface. To configure devices for Take a Test, go to Groups and select a group to configure Take a Test for. Then go to Windows device settings > Take a Test profiles and select “Assign a new Take a Test profile. Here you will specify a Profile Name, Account Name, Assessment URL, and an option Description. Finish it by selecting Create and assign profile as shown in the screenshot below.

Once deployed, test takers can log on to a Windows machine using the test taker profile. They will only be able to access the test in a single browser session.

You can also deploy this mode using regular Intune as well although it is a little messier because you must provide the following OMA-URI settings as shown below.

OMA-URI:

./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/InteractiveLogon_DoNotDisplayLastSignedIn
Data Type: Integer
Value: 1

OMA-URI: 

./Vendor/MSFT/Policy/Config/WindowsLogon/HideFastUserSwitching

Data type: Integer

Value: 1

OMA-URI: ./Vendor/MSFT/SharedPC/AccountModel

Data type: Integer

Value: 1

OMA-URI: ./Vendor/MSFT/SharedPC/EnableAccountManager

Data type: Boolean

Value: True

OMA-URI: ./Vendor/MSFT/SharedPC/KioskModeAUMID

Data type: String

Value: Microsoft.Windows.SecureAssessmentBrowser_cw5n1h2txyewy!App

OMA-URI: ./Vendor/MSFT/SharedPC/KioskModeUserTileDisplayText

Data type: String

Value: Take a Test (or a string of your choice to display in the sing-in screen)

OMA-URI: ./Vendor/MSFT/SecureAssessment/LaunchURI

Data type: String

Value: 

The screenshot below shows all OMA-URIs fully inputted.

Finish the creation wizard out by assigning the configuration profile to a group and you are done. Students will again only have access to the active test session in a locked down desktop environment.

In my two previous blogs I outlined the improved features and capabilities of the latest version of LAPS that was introduced made available with the Windows Update released on April 11, 2023. The new version called Windows LAPS (that I refer to as LAPS2), addressed some of the limitations of the original version called Legacy LAPS (or LAPS1). Those who have relied on LAPS1 will certainly want to upgrade to the newest version but what happens when you bring LAPS2 into a LAPS1 environment? The short answer is that you cannot run both versions of LAPS on the same machine simultaneously. Any settings that are singular to one LAPS version are not accessible in the other one and vice versa.

When you bring LAPS2 into an environment that has preexisting instances of LAPS1 you have two options. Either delete all instances of LAPS1 before implementing LAPS2 or use legacy Microsoft LAPS emulation mode to accommodate both to some degree.

Legacy Microsoft LAPS Emulation Mode Limitations

The original LAPS was implemented by installing the Microsoft LAPS Group Policy Client Side Extension. It is that extension that retrieves the LAPS password information from AD and stores it in the computer’s local security database. You can detect whether a computer has the installed extension by looking for the following registry key:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}

Once you deploy LAPS2 to a machine already running LAPS1, that computer is running in emulation mode. Legacy Microsoft LAPS emulation mode prevents both LAPS from running simultaneously as this would create a security risk. That means that while the computer has LAPS2 installed, it is still restricted to some of the limitations of LAPS1. This means that:

1. You can only store passwords to local AD as only LAPS2 supports Azure AD and local AD.

2. Passwords will be stored in clear-text form. LAPS1 does not support password encryption so while the newest version of LAPS does, you cannot take advantage of it.

3. The Windows Server Active Directory Users and Computer management console doesn't support reading or writing legacy Microsoft LAPS schema attributes.

4. You will not be able to use some of the newer LAPS2 scripts. For instance, cannot you use the

Set-LapsADPasswordExpirationTime cmdlet to modify the existing legacy LAPS password expiration attribute.

5. All Windows LAPS policy knobs that aren't supported by legacy Microsoft LAPS will default to their disabled or default settings.

Note that if you try to install LAPS1 on a machine that already has LAPS2, LAPS1 will be ignored. In other words, whichever version of LAPS is installed first takes precedence over the other.

You can tell if a computer is in emulation mode by going to Event Viewer and navigating to Application and Service Logs > Microsoft > Windows > LAPS > Operational and look for the 10023 event which will show Legacy LAPS as the policy source.

Switching from Emulation Mode

Once you have implemented LAPS2, you will want to eventually move on from emulation mode. You can disable Microsoft LAPS emulation mode by creating a REG_DWORD registry value named BackupDirectory under the:

HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\Config key

and set it to the value of zero. This will prevent LAPS2 from entering legacy Microsoft LAPS emulation mode regardless of whether the Windows LAPS CSE is installed or not.

Remember that the new Windows LAPS does not require you to install any type of CSE. Once a computer receives the April 2023 update and is joined to either Azure or Azure AD, it is LAPS2 capable. After that it just needs the LAPS policy to deliver the configured settings.

I am extending my focus on the new Windows LAPS or as I call it, LAPS2. LAPS2 is Microsoft’s newest release of its Local Administrator Solution which fixes some of the shortcomings of its initial release years ago which is now referred to as Legacy LAPS or LAPS1. In Part 1 of this series, we looked at how to implement LAPS2 and configure the new Group Policy settings for it. Today I am going to finish our discussion on implementing LAPS2 in a traditional AD environment.

The New PowerShell Scripts

The new LAPS introduces a new set of PowerShell scripts. To get the scripts you will need to add the new PowerShell module using the command: Get-Command -Module LAPS as shown below in the screenshot below.

Here are the scripts that you will find the most relevant:

Now let’s put two of these scripts into action. LAPS2 introduces new AD attributes but first you need to update the schema using the Update-LapsADSchema command in PowerShell as shown here.

Note that all domain controllers must have the KB5025229 update installed for the command to finish. If the command fails to complete, you can run the Update -LapsADSchema -Verbose command. You can then read the output to either confirm the completion of schema update or find out where the process is erroring out. The screenshot shows a portion of the output which in this case was completed in its entirety.

Next you need to grant permissions to the machines that will be updating their passwords. This is done by setting inheritable permission to the Organizational Unit(s) where the target machines reside using the Set-LapsADComputerSelfPermission command. In the example below I assigned the permission to the Servers OU.

If you don’t see the Distinguished Name in the output, then the command did not complete.

Once the PowerShell commands have been run, deploy your LAPS GPO and you should be good to go. You can confirm the GPO settings were implemented by going to Event Viewer and confirming it in your LAPS file. You can navigate there by going to:

 Application and Service Logs > Microsoft > Windows > LAPS > Operational.

The screenshot below shows that the LAPS policy has been successfully configured.

Now that the LAPS policy is implemented, its time to retrieve the passwords to login to the machines. There are two ways to do this. You can use the following command in PowerShell:

Get-LapADPassword -Identity Server2022 -AsPlainText as shown below.

You can also use Active Directory. Remember we updated the schema which created new AD attributes. Find the designated computer in Active Directory Users & Computers and view its properties. Then click on the LAPS tab to view the LAPS settings as shown below.

Note that you can also modify the expiration date for the LAPS generated password using this tab as shown here.

If you are having trouble getting LAPS to work properly here are two possible gotchas:

• Your LAPS password policy must be in line with your domain password policy. In other words, you cannot configure an 8-character password for LAPS if your domain requires a 10 character and you must enforce the same complexity requirements or greater.
• Be sure to reboot the computers that you are assigning the LAPS policy to.

Emulation Mode

If a machine has already been using the original LAPS (LAPS1) then the new features of LAPS2 will not be available to it. Running both versions within your environment is referred to as LAPS Emulation Mode.  If a LAPS2 policy is present on the machine, it will always take precedence, regardless of how it was applied. In other words, once a LAPS version is applied to a machine, the other one will not work. In our next installment I will discuss how to uninstall LAPS1 from your environment and escape this complexity.

Local Administrator Password Solution (LAPS) has been around for a while now. LAPS was released by Microsoft as a way for companies to avoid the practice of using a common password for all local administrator accounts. If a local administrator credential is compromised, a threat actor can then move laterally across your enterprise accessing one system after another using that single account.

LAPS acts as a type of password manager that issues a different password for a local administrator account on each designated device. That means if bad guys get a local password for one machine, they can’t get into another, so the breach is contained. Like a password manager, you don’t have to know the unique password for every local admin account because LAPS gives you a way to securely retrieve the password.

It would be nice if we didn’t need local administrator accounts at all, but unfortunately you can’t do everything through Group Policy, SCCM or an MDM. There is always going to be a task that calls for a support admin to log on to the machine to manually tweak something as an Admin... and that is where LAPS comes in. The original LAPS was a bolt on solution. You had to download the MSI from Microsoft and install it. The original release had a few shortcomings. The passwords could only be stored in Active Directory so those with Azure were out of luck. It also stored the password in plain text which leaves them potentially exposed.

The New LAPS

Microsoft just released the new version of LAPS in April 2023. It is designed to replace the original version which means we need a way to distinguish them both. Some refer to the original LAPS as “Legacy LAPS” but I prefer LAPS1. I will refer to the newest release as LAPS2 although Microsoft had named it Windows LAPS. One big differentiator is the fact that it also supports Azure Active Directory although it is currently only available in private preview. Since it isn’t universally available yet, we will focus on the new capabilities it brings to Windows Server Active Directory.

How to Get LAPS2

One difference right out of the gate is the fact that LAPS2 is natively integrated into Windows with KB5025229, OS Build 17763.4252 that was released on April 11, 2023. There’s nothing to manually download or install. Once the update is completed you need to retrieve the LAPS ADMX template file which will be located in Windows > PolicyDefinitions as shown in the screenshot below. Then just copy and paste the file in your central store. You will also need to copy the ADML file from your language folder, in my case, en-us.

I want to take a second to comment on a common misconception out there that Microsoft has abandoned on-prem AD and is focusing solely on the cloud. The release of LAPS2 demonstrates their continued commitment to investing in AD technology. There are thousands of enterprises out there that continue to use AD and LAPS2 helps to fill a critical security gap.

Implementing LAPS2 with Group Policy

KB5025299 adds a new Group Policy Object and AD schema attributes. If you are familiar with the LAPS1 then you were accustomed to navigating to Computer Configuration > Administrative Templates > LAPS where you had four settings to configure.

Well forget that path because LAPS2 settings are accessed by going to Computer Configuration > Administrative Templates > System > LAPS where we have more settings to choose from as shown below. To enable LAPS2 you must enable “Configure password backup policy.

It’s in this setting that you will choose your backup directory. In this case I chose Active Directory below.

The next step should be to specify the name of the local admin account that will be assigned the passwords as shown in the example below.

One new feature of LAPS2 is a configurable password history. This comes in handy if you need to restore a machine to a previous state in which the password was rotated. Group Policy lets you enable this feature and specify the size of your desired history (the maximum is 12) which I did below.

As mentioned, LAPS2 offers encryption to secure the passwords. This requires that you turn on the “Enable password encryption” setting. Another new feature is the ability to manage passwords for the Directory Service Restore Mode (DSRM) accounts. The “Enable password backup for DSRM accounts” setting has no effect unless the managed device is a domain controller and you have password encryption enabled. You can also configure “Post-authentication settings” to ensure that a password isn’t changed while a user is logged on by enforcing a delay or grace period after any successful login of a LAPS-managed account. When enabled, the policy allows you to state how long a grace period you want and select the designated action you want. In the example below I chose “Reset the password and logoff the managed account.”

In Part 2 of this discussion, we will look at the new PowerShell scripts that LAPS2 offers, the new LAPS property page in AD Users & Computers as well as how to operate LAPS and LAPS2 together.

Some users will always try to get around the Windows setting restrictions you implement using Intune or Group Policy. A few will even attempt to reset their device. Denying standard users local admin rights is one way to prevent them from doing so using Recovery settings. That doesn’t prevent them from resetting their device using the Advanced Startup menu, however. There are several ways to access the Advanced Startup menu such as pressing the F8 key as the computer is booting up. From there you navigate to Troubleshoot > Reset this PC and make select the desired options such as “Keep my files” or choosing to remove everything. Besides the reset option, the Advanced Startup Menu gives users access to System Restore, Startup Repair, Command Prompt, and a few other things.

Fortunately, Intune provides a way to keep standard users out of this area. In Intune go to Devices > Configuration profiles > Create profile and select Windows 10 and later as the platform and Settings catalog as the profile type. Name the profile and go to Configuration Settings. Using the Settings picker do a search for “recovery” and choose the Security category and select both available options as shown in the screenshot below.

• Recovery Environment Authentication
• Recovery Environment Authentication (User)

Then assign the profile to your desired group(s) and wait for the profile to be delivered. Now when a user accesses the Advanced Startup Menu to do something such as resetting their device, they will be prompted to select a local admin account as shown in the picture below. In this case I am choosing the Tech Admin account.

The user is then prompted for the credentials of that account as shown here.

Unless the correct credentials are typed in, further access to the advanced startup options is not available.

We know the vulnerabilities of passwords today. User accounts are constantly under siege by credential stuffing attacks and malicious code and tools like key loggers that aim to capture passwords as users type them in. That’s why it is essential to support password authentication with some type of multifactor authentication such as a text messaging, authenticator apps or FIDO keys.

For Windows 10 and Windows 11, there are alternative sign-in methods available. For instance, biometric logons might be a good choice for those users that have laptops with built-in fingerprint sensors. Picture passwords may appeal to some organizations as an alternative. The Windows picture password sign-in requires a user to duplicate several gestures on a selected picture. Then again, those organizations that want to enforce standard desktop for all users may not want this option to be available. For users that always log onto the same computer, a PIN may be lucrative as a PIN is local to a specific device so a compromised pin is only good for its assigned device.

The point of this blog is just to show you how to enable/disable these alternatives using Group Policy or Intune. Let’s start with picture passwords. If you want to disable this option using Group Policy, create a GPO and go to Computer Configuration > Administrative Templates > System > Logon and enable “Turn off picture password sign-in” as shown below. The PIN setting is in the same location. In the screenshot below, I have disabled both options.

You use the same Administrative Template path in for Intune as well. Create a configuration profile and select Windows 10 and later as the platform and Templates > Administrative templates as the profile. Then navigate to Computer Configuration > Administrative Templates > System > and enable Turn off picture password sign-in as shown in the screenshot below. Once again, the PIN setting is there as well.

For fingerprint scanning or other biometric authentication options, create a GPO and go to Computer Configuration > Windows Components > Biometrics and select “Allow the use of biometrics” and “Allow users to log on using biometrics.” In the screenshot below I have enabled both of these.

To manage biometric settings using Intune, create a configuration profile and select Windows 10 and later as the platform and Templates > Identity protection as shown below.

After naming the profile, go an enable “Configure Windows Hello for Business. This will then provide access to all of its category settings. Then select, “Allow biometric authentication” with the result looking like the screenshot below.

Anyone that works with Microsoft Intune has experienced this. You read about a newly released Intune preview feature that sounds enticing. You then logon to your Intune portal only to find its not there. What’s the deal?

Microsoft regularly releases new updates to the Intune platform at least once a month. Each service release includes new features, capabilities and bug fixes. Like regular Windows updates, these service releases are deployed using a phased approach. Not all tenants receive these service releases simultaneously, however. For instance, government related tenants are updated last. Some geographcial parts of the world receive them before others as well. This methodical approach is done to identify issues before being released to all Intune customers. If your Intune portal lacks a new feature you just read about, chances are it’s because you’re not running the latest Intune service release version yet.

The Tenant Status Page

There’s an easy way to find which service release version your Intune portal is currently running. Navigate to Tenant Administration and select Tenant Status. Here you will see the Service release version as shown in the screenshot below.

Here you will also find other information such as your Tenant name, Tenant Location, the number of licensed users present and the number of Intune enrolled devices. If you find that your Service release version doesn’t match up with the latest one you read about, just be patient and check back in a week.