Mastering Endpoint Management using Microsoft Intune Suite

Copyright © 2025 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Early Access Publication: Mastering Endpoint Management using Microsoft Intune Suite

Early Access Production Reference: B34179

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK

ISBN: 978-1-80602-195-6

www.packt.com

Mastering Endpoint Management using Microsoft Intune Suite: Learning Everything About Intune Suite

Welcome to Packt Early Access. We’re giving you an exclusive preview of this book before it goes on sale. It can take many months to write a book, but our authors have cutting-edge information to share with you today. Early Access gives you an insight into the latest developments by making chapter drafts available. The chapters may be a little rough around the edges right now, but our authors will update them over time.You can dip in and out of this book or follow along from start to finish; Early Access is designed to be flexible. We hope you enjoy getting to know more about the process of writing a Packt book.

Chapter 1: Mastering Cloud PKI: Secure Your Digital Identity

Chapter 2: Elevating Endpoint Privilege Management: Control and Security

Chapter 3: Enterprise App Management: Streamlining Application Deployment

Chapter 4: Advanced Analytics: Unlocking Insights for Better Decisions

Chapter 5: Remote Help: Empowering Support from Anywhere

Chapter 6: Microsoft Tunnel for Mobile Application Management: Seamless Connectivity

Chapter 7: Essential Intune Resources: Your Guide to Mastery

1 Mastering Cloud PKI: Secure Your Digital Identity

Join our book community on Discord

https://packt.link/UWVMzThis book is our guide to unlocking the full potential of modern endpoint management with Microsoft Intune Suite. Whether you're an IT professional or a tech enthusiast, you’ll find practical insights and real-world value in each chapter. As organizations continue to embrace secure, cloud-first strategies, Intune Suite stands at the forefront of enabling seamless, scalable device and app management.Let’s begin our journey with CloudPKI, a powerful component that simplifies certificate management in the cloud.In this chapter we will understand the background, flow and setup of CloudPKI and get an overview of its practical implementation. The chapter begins by introducing the concept of digital certificates, detailing the authentication and authorization processes users undergo to access applications. The discussion then shifts to the advantages of certificate-based authentication over traditional username and password methods. A comparative analysis of SCEP and PKCS follows, outlining the strengths and limitations of each approach. The chapter then explores the conventional method of SCEP certificate delivery using on-premises NDES via Intune, providing a step-by-step breakdown of the process. This is contrasted with the modern Cloud PKI approach, emphasizing its benefits in terms of simplicity and manageability. Subsequently, the chapter presents a detailed walkthrough of the SCEP certificate delivery flow using Cloud PKI, supported by logs and block diagrams at each stage. It also covers the setup process for Cloud PKI, including the various deployment models and available reporting options. Finally, the chapter examines the post-deployment phase of SCEP certificate issuance via Cloud PKI, explaining how the issued certificate can be utilized for certificate-based authentication and outlining the associated connection flow.By the end of this chapter, you will possess the knowledge and practical skills necessary to deploy Cloud PKI solutions, effectively troubleshoot existing implementations, and develop a comprehensive understanding of the processes involved in SCEP certificate delivery using Cloud PKI. Additionally, they will gain insight into the configuration required to leverage client certificates for certificate-based authentication.The following main topics will be covered in this chapter:

Background of certificates

Brief of on-prem NDES

The Modern Approach for SCEP cert delivery: Using CloudPKI

Background flow during SCEP certificate delivery using CloudPKI

Viewing the SCEP certificate at the device end

CPKI Architecture and Setup

Reporting

Bonus Insight: SCEP Certificate Delivery via On-Prem NDES and Intune

The Aftermath of certificate delivery

Tips and Our 2 Cents

Let’s get started!

Background of certificates

In the digital world, certificates are electronic credentials used to verify the identity of devices, users, or services. Client certificates authenticate individual users or devices, while trusted root certificates serve as the foundation of trust, validating the authenticity of all certificates issued by a trusted authority.For any user to access any application, they must go through 2 phases: Authentication and Authorization as explained below:

Authentication phase: In this phase, the system verifies the user's identity to ensure they are who they claim to be. This process, known as authentication, typically involves credentials such as a username and password. It is commonly used when accessing applications, connecting to Wi-Fi networks, or establishing VPN sessions, serving as the first line of defense against unauthorized access.

Authorization Phase: In this phase, the user is subjected to some conditions and depending on the output, the service determines whether the user should be given access or not. For example: Usage of Conditional access (CA) policy in EntraId. Even after entering the correct credentials CA policy runs a check and only allows access to selected apps if the user is authorized to do the same.

Using certificates for authentication instead of conventional username/passwords has the following advantages:

Certificates facilitate seamless and automated authentication

Removes the overhead for the user to enter the username/password manually

More secured than passwords which are prone to leakage.

Relevant Certificate Types

Now let’s discusses PKI hierarchy and the commonly used certificates by referencing the following diagram:

Figure 1.1: Understanding types of certificates

As illustrated in the diagram, the certificate hierarchy comprises Trusted Root Certificates, Intermediate Certificates, and Client/Server Certificates. A brief overview of each is provided below to enhance understanding of their respective roles and significance.

Trusted Root Certificates: The root Certificate Authority (CA) is at the top of the certificate hierarchy. In a secure organization, there is typically a multi-tiered CA hierarchy, with the root CA kept offline to ensure its protection. A trusted root certificate is a certificate that the root CA issues to itself, meaning the issuer and the subject of the certificate are the same. The root CA and its certificates are essential components of all Public Key Infrastructure (PKI) setups. For Example: We have trusted root certificates installed in our devices that we get from the OEM as a part of standard image. These certificates are from public PKIs like DigiCert, Entrust, Baltimore, Go Daddy etc. as seen in the image below

Figure 1.2: Trusted Root certificates in a Windows device

Intermediate Certificates: Intermediate or issuing CAs are present in a two-level PKI hierarchy. They occupy the second level, with the root CA at the top. Intermediate certificates are issued by the root CA to the issuing CA, meaning the issuer of the certificate is the root CA, and the subject is the issuing CA. These intermediate certificates are crucial for building the certificate chain. For Example: We also have intermediate certificates installed in our devices that we get from the OEM as a part of standard image. These certificates are from public PKIs as seen below:

Figure 1.3: Intermediate certificates in a Windows device

Client and Server Certificates: Client and server certificates are at the base of the certificate chain and are issued by the intermediate or issuing CA. Client certificates are used for user authentication, while server certificates are used by servers for purposes such as SSL and website binding. For Example: Client certificates are usually used in organizations to automatically connect to office network.

Now that we have understood the common types of certificates, in the next section we will understand 2 key categories of client certificate that Intune can deploy, namely SCEP and PKCS.

Client Certificates: PKCS and SCEP

Via Intune we can push 2 kinds of client certificate to devices i.e. PKCS and SCEP.Both have their own advantages and disadvantages but are more or less used to achieve the same use case- i.e. seamless authenticationIn both cases, the end goal is- Delivering a certificate from an on-premises CA in the intranet to a device present anywhere in the world over the internet. The device can then leverage this cert for any purpose. Let’s understand the basics of both SCEP and PKCS below:

SCEP:

Stands for Simple Certificate Enrollment Protocol. It was originally developed by CISCO

The protocol operates on a request-response model and uses HTTP methods such as GET and POST for communication.

SCEP has the private key, but the private key is not marked as exportable. This means that the private key never leaves the device which makes SCEP more secure than PKCS

A SCEP cert can be issued to a user/device or an userless device (a device without user affinity/association).

PKCS:

Stands for Public Key Cryptography Standard (PKCS 12<=> PFX)

Initially developed by Microsoft, it is now an open standard.

The private key is marked exportable

Understanding the similarities and differences between SCEP and PKCS is essential to identifying their appropriate use cases. The following table presents a concise comparison of the two protocols to support informed decision-making.

PKCS | SCEP (using on-prem NDES)
Can be deployed via Intune | Can be deployed via Intune
Used for seamless auth to VPN, Wi-Fi | Used for seamless auth VPN, Wi-Fi
Can be issued to a user (who enrolled the device) or any device attribute | A SCEP cert can be issued to a user (who enrolled the device) or any device attribute
Less secured as Private key is marked as exportable | More secured- private key never leaves the device
Less overhead as only the Intune Connector needs to be installed | More overhead as we need a new server (NDES), IIS, App proxy and Intune connector
Less complex to setup due to smaller footprint | More complex to setup due to larger footprint
Device talks only to the Intune service which acts as a mediator | Device talks to the NDES via App Proxy
Cannot be issued using CloudPKI | Can be issued using Cloud PKI
Can be load balanced but it’s not very seamless | Can be load balanced more seamlessly

Table 1.1: Comparison between PKCS and SCEP certificate deployment via Intune

Which one to use?!

This would be the most FAQ that I get as far as setting up the cert deployment via Intune is concerned. As seen above in the comparison, both have their advantages and disadvantages.On one hand PKCS is easier to deploy and has less components involved. However, SCEP is more secure but has an added overhead of more components as discussed above. Both the certs can be used to achieve seamless auth to Wi-Fi and VPN (except PKCS can be used in case of an userless device).My recommendation would be- To use SCEP if we can afford the added infra overhead given it is more secured and can be deployed to userless devices unlike PKCS. If not, then PKCS would suffice in most of the use cases. However, it’s always a safe bet to discuss this with the networking folks and the CA admin to see what kind of certificate they are looking for, which the RADIUS server would authenticate. We must remember that Intune is a delivery mechanism responsible for (in this case) delivering a certificate. Once the cert is down to the device, it’s pretty much up to the device to present it in order to prove its authenticity.Up to this point, we have developed a foundational understanding of digital certificates—their types, benefits, and a comparative analysis of key protocols. In the following section, we will shift focus to the SCEP certificate delivery process via Intune. We begin by examining the traditional deployment method, which involves using on-premises NDES as the certificate authority integration point.

Understanding SCEP cert delivery using on-prem NDES

CloudPKI is the modern way of deploying a SCEP cert via Intune however before we understand it in detail and identify its advantages, it’s very important to get a basic understanding of how a SCEP certificate was delivered traditionally using on-prem NDES via Intune- when there was no option of Cloud PKI.

Brief of on-prem NDES

This is a conventional way of distributing SCEP certificates to devices. The devices can reach out to the NDES server which in turn goes to the Issuing CA and grabs the certificate on user’s behalf. The NDES server is binded with the CA hence both need to be in the same on-prem domain. As devices reach out to the NDES server over the internet, the NDES needs to be publicly available.To achieve this, the on-prem NDES is front ended by an App proxy which routes the traffic from internet to the NDES.

Note

To understand the background flow and delivery of SCEP certificate using on-prem NDES, kindly refer to the section Bonus Insight: SCEP Certificate Delivery via On-Prem NDES and Intune later in this chapter.

In the next section of this chapter, we will understand the detailed SCEP certificate flow using CloudPKI and understand how it makes the troubleshooting easier by removing the dependency on many components.

The Modern Approach for SCEP cert delivery: Using CloudPKI

Before we get started, here’s some background of Cloud PKI…Microsoft announced Cloud PKI as an upcoming offering in August 2023. In March 2024, Cloud PKI became Generally Available for usage letting us manage the full lifecycle of issued certificates for Intune managed device. Microsoft Cloud PKI is a fully cloud-native solution designed to streamline and automate the entire certificate lifecycle for devices managed through Microsoft Intune. It delivers a dedicated public key infrastructure tailored to your organization’s needs—eliminating the complexity of deploying and maintaining on-premises servers, connectors, or specialized hardware. This service seamlessly manages certificate issuance, renewal, and revocation across all platforms supported by Intune, ensuring secure and scalable identity management without the traditional overhead.Traditionally, admins had an option of doing this via on-prem NDES server which was cumbersome to setup and troubleshoot.Using Microsoft Cloud PKI organizations can simplify their certificate management with minimal effort. The overhead of managing and maintaining an on-prem CA is removed/reduced using the SaaS based certificate registration authority which is hosted in Azure on behalf of the customer. As the service is hosted in Azure, its Highly Available and we don’t have to worry about its load balancing.

Comparison: On-prem NDES VS CloudPKI

Let's conduct a detailed comparison between the delivery of SCEP certificates via Cloud PKI and the traditional method of deploying SCEP certificates using on-premises NDES through Intune.

Criteria | On-Prem NDES | Microsoft Cloud PKI
Manageability (Components to be managed) | Management is difficult– NDES server, Issuing/Root CA, App Proxy, Intune Connector | Management is easy– Nothing is needed to be managed on-prem
Deployment | Deployment is complex | Deployment is straight forward
Load Balancing/Redundancy | We need to spin up multiple NDES instances on-prem | As its SaaS on Azure, its Highly Available hence LB is not needed
Supported Devices and Certificates | Can be used to supply certs to all kinds of devices. Also, we can issue almost all kinds of certs | (As of now) can supply certs to Intune Managed devices only. Also, only Client authentication certs can be issued. SSL certs/SMIME cannot be issued as of now.
Control (over attributes) | We have more granular control/customization available | Less granular control/selection available
Cost | No additional licensing cost except cost of managing the NDES server and CA | Extra licensing cost – 2$/user/month
Troubleshooting | As many components are on-prem, customer can check and troubleshoot them at his end. | Not much of troubleshooting can be/(has to be) done at customer’s end due to components in SaaS

Table 1.2: Comparison between on-prem NDES and CloudPKIBased on the factors outlined in the table—such as setup costs (including component requirements), the desired level of control over certificate attributes, and the available resources for implementation, we can determine whether an on-premises NDE or a Cloud PKI solution is more suitable.So far, we have explored the foundational concepts of Cloud PKI and conducted a comparative analysis with on-premises NDES across various parameters. In the next section, we will take a detailed look at the SCEP certificate delivery workflow using Cloud PKI, correlating each step with relevant logs to provide deeper operational insight.

In-Depth Flow of SCEP Certificate Delivery with Cloud PKI and Logs Insight (L200):

Now, let's refer to the diagram below to understand the detailed background flow during SCEP certificate delivery via Cloud PKI and correlate each step with the corresponding logs.

Figure 1.4: (Part 1) Flow behind SCEP cert delivery using CloudPKI

Here are the components in the diagram:

We have the Intune admin who is making the SCEP profile and doing its assignment

We have the end devices which are enrolled to Intune and have internet connectivity.

And then we have the Intune service and CloudPKI service which is a SaaS on Entra.

Based on the diagram above, the following sections outline the key stages involved in the SCEP certificate delivery process using Cloud PKI.

Step 1: Admin creates and assigns the SCEP profile

In the initial step, the admin creates and assigns the SCEP profile. This is the very first step in the flow which needs to be carried out by the admin.Once the SCEP profile has been assigned, Intune reaches out to Entra and identifies the effective applicable users. It then fetches the CN of the members.It also evaluates the Group association, making sure that the SCEP profile and the Trusted Profile are both deployed to the exact same group (and not nested groups).

Step 2: SCEP Challenge Generation

In the next step, Intune service reaches out to the SCEP service (hosted in Cloud PKI) requesting for a challenge password.The challenge password is an unique challenge string (like an OTP) which is generated per user per SCEP profile configured in Intune.The challenge, the Thumbprint of the issuing CA, and the time stamp is sent by the SCEP service. This is equivalent to manually generating a challenge from the NDES server by browsing to the “mscep_admin” url in NDES:

Figure 1.5: Figure replicating SCEP challenge generation using on-prem NDES

Before we proceed further, let’s take a brief detour to understand how the SCEP protocol functions and what the challenge password is—explained below using an analogy.

How does SCEP work? | Getting a 1000 feet overview

The simplest way to understand how SCEP works is through the following analogy:

Consider making a purchase on an e-commerce website using a card. We visit the website, place an order, and enter our card details for payment. Subsequently, we receive a one-time password (OTP) from the bank via text or call, which serves as a challenge password. This OTP is a secret provided by a trusted source.

To complete the payment, we must enter the received OTP on the transaction page of the website. Several checks are performed to ensure the OTP is valid, including matching the OTP sent by the bank with the one we entered on the website. Additionally, the OTP has a time-to-live (TTL), typically 10 minutes, meaning the transaction will still fail even if the correct OTP is entered after this period.

Applying this analogy to SCEP, the NDES server generates a challenge password and sends it to the device via the Intune service along with the SCEP payload. The device then contacts the NDES server/SCEP service and presents the same challenge. The SCEP service validates the challenge password and checks other relevant attributes. Once verified, the request is forwarded to the CA.

Step 3: Delivery of the SCEP payload to the device over the internet via Intune

Now the SCEP policy payload will be delivered to the device by Intune over the internet. This process can be monitored in real-time by running a SyncML trace on the device, which will display the incoming SCEP payload as seen below:

Figure 1.6: SyncML trace from device targeted with CloudPKI based SCEP profile

As per the above image, we can see that the other attributes as per the SCEP payload like the SAN, Key usage, Key size, EKU, Validity and challenge password is also deployed to the device as a part of this MDM session using the SyncML tool.

Step 4: Device generates and sends the GetCACert and GetCACaps request

After receiving the SCEP payload in the previous step the device is now going to make use of the same. As a part of SCEP protocol, the device now needs to do a GetCACert and GetCACaps request. This request will be sent to the NDES server via the App proxy URL which was delivered to the device in the SCEP payload in the previous step.

The response to the GetCACert are the 2 RA certificates which are binary-encoded. These are the CA certificates which will be later used by the device.

SCEP uses the CA certificate in order to secure the message exchange for the CSR. The response for a GetCACaps message is a list of CA capabilities, in plain text which is usually as below.

Table 1.3: List of possible response to ‘GetCACaps’ operations showing CA’s capabilities

We have determined that in step 4, the device sends GetCACert and GetCACaps requests to the NDES server to obtain the RA certificates and the CA's capabilities. This step is crucial because the device requires the NDES server's RA certificate later and needs to verify that the CA can issue the type of certificate the device ultimately needs. Therefore, this check is performed at this stage.

Step 5: Device receives the response

The device now receives the response for GetCACaps. To manually replicate this, you can navigate to the below URL in a browser, which will display the CA's capabilities as shown below. This is how the GetCACaps response appears.

URL: https://{{CloudPKIFQDN}}/TrafficGateway/PassThroughRoutingService/CloudPki/CloudPkiService/Scep/8dbf03ab-f625-4076-b74b-bbd9543986ba/8595687a-3c16-47b0-a300-13b570c90813?operation=GetCACAPs

Where {{CloudPKIFQDN}}: The MSU where our CloudPKI instance is hosted. Like in the below example the MSU is fef.msuc02.manage.microsoft.com

Figure 1.7: Replicating GetCACaps response in web browser

The device also receives the response for GetCACert. To manually replicate this, you can navigate to the below URL in a browser, which will display the RA certificates as seen below which will be downloaded by the browser.

URL: https://{{CloudPKIFQDN}}/TrafficGateway/PassThroughRoutingService/CloudPki/CloudPkiService/Scep/8dbf03ab-f625-4076-b74b-bbd9543986ba/8595687a-3c16-47b0-a300-13b570c90813?operation=GetCACert

Figure 1.8: Replicating GetCACert capabilities in a browser

For Android and iOS devices, this step is also logged in the Company Portal logs, as illustrated below:

Figure 1.9: Sample Company Portal logs from Android showing GetCACert and GetCACaps operation

Until now we have understood the first 5 steps in detail during the SCEP certificate delivery. Now let’s reference a new diagram as seen below to establish the flow during the SCEP certificate delivery process:

Figure 1.10: (Part 2) Flow behind SCEP cert delivery using CloudPKI

Based on the diagram above, the following steps outline the flow involved.

Step 6: Device generates the CSR and sends it

The device now has all the necessary components and proceeds to generate the Certificate Signing Request (CSR). This CSR includes the challenge password, which the device must present to the NDES server to verify its legitimacy. Additionally, the CSR contains other essential information required by the CA for certificate issuance, such as the certificate's validity period, key usage, and other relevant attributes.In Windows device this can be tracked in Eventviewer with EventId 306 and 36 as seen below

Figure 1.11: Eventviewer logs from Windows device showing Eventid 306

The below log shows the successful generation of CSR by the device:

Figure 1.12: Eventviewer logs from Windows device showing successful CSR generation

Step 7: The request is sent to SCEP service for validation

The request for CSR validation is now sent to the SCEP service. This process is logged on the service side, where we can confirm that the CSR has been received. The SCEP service will then perform its validation, which includes:

Verifying whether the timestamp of the challenge has expired or is still valid (validity is 60 minutes).

Ensuring the challenge password is correct by matching it with the list of passwords generated by the NDES server.

Checking that the attributes for which the challenge was originally generated match those in the CSR.

Unfortunately, this validation process occurs on the service side, and end customers cannot access the logs for this step, as they are stored in Microsoft's database and can only be reviewed by Microsoft's engineers using Kusto.

Step 8: Post verification the request is sent to Issuing CA

Once verified, the request is now sent to the CA for further processing. In on-prem world we could track this step by checking the Eventviewer logs of the CA server.

Step 9: The certificate is issued as per the request

CA now issues the certificate as per the request.

In the request we currently don’t have the option of specifying a specific Certificate Template via which the cert should be issued.

CA protects the certificate package by using the device’s public key (it received in the CSR).

Step 10: The certificate is delivered to the device via MDM channel

The certificate is now delivered to the device via Intune.

Upon receipt, the device installs the certificate, and this action is logged across all operating systems.

This client certificate will subsequently be used by the device for authentication purposes.

Figure 1.13: Eventviewer logs from Windows device showing delivery of certificate

Once the certificate is installed, it can be viewed in the device’s certificate store (under Current User > Personal) as seen below. We can see the certificate’s chain as well as all its other parameters:

Figure 1.14: Certificate store in the device showing the presence of certificate

The successful installation of the certificate is also logged in the Eventviewer with EventId 39 as seen below.

Figure 1.15: Eventviewer logs in the device showing the installation of certificate

In this section, we explored the detailed workflow of SCEP certificate delivery using Cloud PKI. This process remains consistent across all major platforms, including Windows, Android, iOS, and macOS. There was a special focus on the certificate delivery flow in this chapter because gaining a clear understanding of this flow is essential for building a strong conceptual foundation, which in turn is critical for effective troubleshooting and issue resolution.In the next section, we will explore the crux of SCEP certificate delivery via Cloud PKI, illustrated through a block diagram to provide visual clarity and contextual understanding.

Block diagram representation of the flow

Based on the explanation in the previous section, now let's examine a block diagram representation of the SCEP certificate flow using Cloud PKI.

Figure 1.16: Block diagram showing the overview of steps involved during SCEP cert delivery

At a high level, the SCEP certificate delivery process via Intune using Cloud PKI can be segmented into eight primary steps, as illustrated in the block diagram above. Each step is accompanied by corresponding logs, which serve as valuable tools for troubleshooting and issue resolution.We will now explore how to locate a SCEP certificate on a device, noting that its location varies depending on the client's operating system.

Viewing the SCEP certificate at the device end

Once installed, the SCEP certificate issued by Cloud PKI is visible on the device. The location of the certificate varies depending on the operating system. The table below provides a detailed explanation.

Operating System | Location
Windows | MMC > Current User > Personal Store > Certificates
iOS | Settings > Device Management > Management Profile > More Details > ‘Under ‘Certificates’ header, ‘SHA-1’ signifies the Thumbprint
macOS | Keychains > System > My Certificates, ‘SHA-1’ signifies the Thumbprint
Android | 3rd party app (‘My Certificates’ application or equivalent) >User Credentials

Table 1.4: Respective locations of SCEP certificate based on Operating SystemWhen reviewing the SCEP certificate at the above specified location, it is important to examine key attributes such as the Subject Name, Subject Alternative Name (SAN), Validity Period, Key Usage, and Thumbprint, as these provide critical insights for validation.Now in the next section, let’s get an overview of the various CloudPKI models available for us during setup.If the certificates are not visible on the device, it indicates a need for troubleshooting. The first step is to verify whether a certificate was actually issued for the user or device via the Intune portal, as explained in the reporting section of this chapter later.If the portal shows the certificate as issued but it still doesn’t appear on the device, possible reasons could include the certificate being revoked from the portal or having expired, as illustrated in the image below:

Figure 1.17: View of revoked certificates issued by CloudPKI

If the certificate was not issued, the next step is to troubleshoot the device by revisiting the complete flow discussed in the previous section. This will help identify the exact point where the process breaks down, preventing certificate issuance.

CloudPKI Setup

We will not go into the very details on how to setup the CloudPKI because it’s straight forward and it has been documented very widely in many blogs and Microsoft’s documentation. However, to summarize:

Figure 1.18: Diagram illustrating the CloudPKI setup options

We have two deployment options as seen in the figure:

Microsoft Managed Cloud PKI Root CA: We deploy Microsoft Cloud PKI by using root and issuing CAs in the cloud.

Bring your own certification authority (BYOCA): We deploy Microsoft Cloud PKI by using your own private CA.

The basic difference between them is:

In the case of Microsoft Cloud PKI root CA, there is no connection of CloudPKI with the on-premises. The root and the issuing CAs are both hosted in the cloud.

However, in BYOCA deployment the Issuing CA is in the Cloud and it is anchored to a root CA which is present on-premise.

Here’s a decision Table on Microsoft Managed Cloud PKI vs. Bring Your Own CA to solidify your understanding:

Criteria | Microsoft Managed CPKI | BYOCA
Deployment Complexity | Minimal – fully cloud-based, no on-prem infrastructure needed | Requires on-premise CA server
Maintenance Overhead | Low- Managed by Microsoft | Moderate- organizations are responsible for managing the on-prem CA
Use Case Suitability | Ideal for modern, cloud-first environments who don’t want to create a CA for client certs delivery and are starting fresh. | Ideal for environment with existing on-prem CA which can be plugged into cloud.

Table 1.5: Decision Table: MMCPKI vs BYOCASetting up the Microsoft Managed Cloud PKI Root CA is very straight forward. However, for BYOCA there are some additional steps.

Setting up of BYOCA

In case of BYOCA we have to download a CSR from our Issuing CA in the cloud and since it is going to be anchored with the root in the on-premises, we need to get the CSR signed by the root (on-premises) and then upload the singed CSR back to the CloudPKI as seen below

Figure 1.19: Diagram illustrating the process of signing a .csr during CloudPKI setup

As seen below, we have the option of downloading and uploading the .csr into the CloudCA

Figure 1.20: Figure illustrating the .csr signing process during CloudPKI setup

There are 2 ways of getting the csr signed by the on-prem Root CA.

We can use the Certification Authority Web enrolment URL as seen below

Figure 1.21: Figure showing the process of signing .csr by on-prem CA

We can Use the certreq.exe command-line too

certreq -submit -attrib "CertificateTemplate:<template_name>" -config "<CA_server_name>\<CA_name>" <request_file> <response_file>

Kindly check Microsoft's documentation which guides through the steps on creating the CloudPKI CAs. Once it has been created, we will get a SCEP URI as seen below. The devices need to reach out to that SCEP URI in order to request for a cert.

Figure 1.22: Figure showing the configurations of a working CloudPKI setup

This SCEP URI needs to be used in the SCEP Profile as seen below:

Figure 1.23: Figure illustrating SCEP profile in Intune using CloudPKI URLs

In this section, we reviewed the setup and installation process for Cloud PKI, which is notably straightforward—typically taking less than 10 minutes to complete. In contrast, configuring on-premises NDES for certificate delivery is significantly more time-consuming, often requiring 2–3 hours due to the need to install and validate multiple components individually.In the following section, we will explore the reporting capabilities associated with certificates issued via Cloud PKI. Robust and reliable reporting is essential to validate that Cloud PKI is operating effectively and delivering the expected outcomes.

Reporting

Monitoring the certificates deployed to Intune-managed devices by the Microsoft Cloud PKI service is straightforward. Each Microsoft Cloud PKI issuing CA has a dashboard that displays the number of deployed certificates, including:

Active certificates/Expired certificates/Revoked certificates/Total number of issued certificates

As seen in the screenshot below, we can get details of the certificates which were issued along with their status by going to Tenant Admin > Cloud PKI > CA. The portal itself provides the ability to revoke a certificate if needed.

Figure 1.24: Figure from Intune portal showing CloudPKI certificate reporting

We can also go into the Monitor > Certificates section in the portal which gives us similar reporting options as seen below:

Figure 1.25: Figure from Intune portal showing CloudPKI certificate reporting

The Intune console provides rapid and comprehensive reporting for certificates issued via Cloud PKI. These reports include key attributes such as device name/ ID, username, certificate thumbprint, serial number Subject Alternative Name (SAN) etc. Additionally, the reports can be exported for future reference and audit purposes. This is important because it enables us to keep a track of all the certificates that have been issued to users/devices in our environment.So far, we've explored the certificate delivery process using Cloud PKI in detail. To provide a more complete understanding, it's important to briefly revisit how certificate deployment was traditionally handled through on-premises NDES. A high-level overview of this legacy approach is provided in the next section.

Bonus Insight: SCEP Certificate Delivery via On-Prem NDES and Intune

Let’s get a thousand feet overview of a SCEP certificate delivery via on-prem NDES and Intune using the below diagram. We will not be talking about the logs here as this section is just to understand the basics.

Note

As we'll see below, the core logic behind SCEP certificate delivery remains consistent between on-premises NDES and Cloud PKI. The key distinction lies in the infrastructure: with on-prem NDES, multiple components—such as the NDES server, Application proxy, and Connectors—must be deployed/ maintained within our on-premises environment. This added complexity increases the administrative burden during both setup and ongoing management.

The diagram below explains the steps involved in deployment of a SCEP cert via Intune using on-prem NDES. This section is provided for reference and aligns with the Cloud PKI flow discussed earlier in the chapter. As such, we won’t delve into the detailed workings or log analysis of on-premises NDES, since that falls outside the scope of this book.Below are the initial 4 steps that occur at the Intune service end and the device end to facilitate the certificate delivery.

Figure 1.26: (Part 1): Flow of SCEP cert delivery using on-prem NDES and Intune

Below is the explanation of the steps 1-4 from the diagram below:

Admin creates and assigns the SCEP profile.

SCEP Challenge Generation

Challenge response

SCEP payload + Challenge delivered to the device

Now let’s reference the below diagram to understand the next 4 steps:

Figure 1.27: (Part 2): Flow of SCEP cert delivery using on-prem NDES

Below is an explanation of the steps 5-8:

Device generates and sends the GetCACert and GetCACaps request

The GetCACaps and GetCACert request is received by NDES and it responds

Device receives the response to the ‘GET’ request.

Device creates a CSR (Certificate Enrollment request)

Now we will reference a new diagram as seen below to understand the next 5 steps involved:

Figure 1.28: (Part 3): Flow of SCEP cert delivery using on-prem NDES and Intune

Below is the explanation of the steps 9-13:

Device sending the CSR to the Proxy

The request is sent to the NDES server

The Plugin initializes and forwards the request to CRP

The CRP now validates the CSR from the device

CRP reaches out to the CA requesting for a client certificate

Now let’s reference the below diagram which illustrates the final 4 steps involved during the SCEP cert delivery:

Figure 1.29: (Part 4): Flow of SCEP cert delivery using on-prem NDES

Below is the explanation of the steps 14-17:

CA issues the certificate and sends it back.

Plugin uploads the certificate details back to the Intune service

The Certificate is deployed to the device.

Device receives the certificate.

Note:

The flow of CSR validation in on-premise NDES has changed significantly with the introduction of the new Unified Certificate Connector which was released by Microsoft in 2022. The Unified Certificate Connector replaced the older Intune Certificate Connector. The legacy connector was used to support SCEP and PKCS certificate deployment scenarios but required separate installations and configurations for different certificate types. The Unified Connector consolidated these capabilities into a single, streamlined solution, simplifying deployment and management.

Please refer to the below flow diagram which provides insights into the flow with Unified Certificate Connector.

As we can see, in Step 11 the NDES is reaching out to the Intune service for CSR validation and in Step 12 the Intune service is responding back to the NDES with the outcome of validation. (Success/Failure). This change was implemented to streamline the workflow and shift part of the processing load from on-premises NDES infrastructure to the cloud, thereby enhancing efficiency.As per the new flow with the introduction of Unified Certificate Connector, the SCEP challenge validation happens in the cloud as explained below:

Figure 1.30: (Part 3): Flow of SCEP cert delivery using on-prem NDES and Intune

With this section, we've covered the foundational concepts of SCEP certificate delivery using an on-premises NDES setup. While the core logic and flow closely mirror what we've seen with Cloud PKI earlier in this chapter, the on-premises approach involves multiple components—such as servers, connectors, and proxies—that add complexity to setup and troubleshooting. Cloud PKI simplifies this by offloading much of the infrastructure to the cloud. The purpose of this section is to provide a high-level understanding of the traditional SCEP flow, enabling a meaningful comparison with the modern Cloud PKI approach.Once the SCEP certificate from CloudPKI has been successfully delivered to the device, it must be utilized to establish certificate-based authentication—the primary objective of the certificate issuance process. In the next section, we will explore the post-deployment phase, focusing on how the certificate is used for authentication against a RADIUS server/NPS, along with the steps involved in enabling the same.

The Aftermath of certificate delivery using Cloud PKI

Well, we didn't deploy the SCEP certificate using Cloud PKI to the device just because it was fun right? The primary intention is to utilize the certificate for authentication purposes, typically for Wi-Fi authentication. Before delving into how the certificate can be used for authentication, let's understand the concept of chain building.In the diagram below, we can see the hierarchy of a certificate. At the very bottom, we have the client certificate (SCEP certificate). The client certificate is issued to the username or device name (which is configurable) and is issued by the Issuing CA/Intermediate CA.

Figure 1.31: Figure explaining certificate chain

Now, let's consider a scenario where we have a RADIUS server in our environment that performs authentication before allowing devices to connect to Wi-Fi. The device will present the aforementioned SCEP certificate to the RADIUS server. However, by default, this server does not recognize or trust this certificate. The server must be configured to recognize that the client certificate presented by the device originates from a trusted source.The server will trust the client certificate only if the chain of the user's SCEP certificate is present in the server's store. In this example, the chain of the user's SCEP certificate contains two certificates, as shown in the diagram: the root certificate (issued to and by the root) and the Intermediate Certificate (issued by the root and to the Issuing/Intermediate CA).This means that only if these two certificates (the certificate chain) are present in the RADIUS server's certificate store, the server will recognize and trust a client certificate that has originated from the same chain.

This logic applies not only to the RADIUS server but also to all types of endpoints. For example, consider our Windows devices. When navigating to an HTTPS website (i.e., one with an SSL certificate), the Windows device will only trust that certificate if its chain is already present in the device's certificate store. If the chain is not present, an error will occur, similar to what you might see when attempting to visit a website with an SSL certificate from an unknown source.

Figure 1.32: Figure showing message while accessing untrusted sites from browser

Therefore, when we purchase a laptop, the image includes a default list of trusted root certificates from common CA vendors such as DigiCert, Entrust, GoDaddy, Baltimore, and Microsoft. This ensures that when our device tries to access any resource with a client or SSL certificate from these providers, the device will trust them by default.Hence For any entity (such as a RADIUS server) to trust a certificate (SCEP certificate), it must possess the entire certificate chain (i.e., root and issuing certificates) of the certificate it needs to trust.We will now apply this concept below.Now let’s talk about how Cert Based Authentication (CBA) is going to happen. We will discuss 2 scenarios.

Scenario 1: CBA for Microsoft Managed CA

We'll begin by exploring the setup of a traditional certificate-based authentication in the section below. Once that's clear, we'll walk through the connection flow for Certificate-Based Authentication.

Understanding the Setup

As seen in the following diagram, on the left had side we have the device which is enrolled to Intune and on the right side we have the Wi-Fi access point/Radius server.

Figure 1.33: Figure showing the setup for cert-based authentication for Microsoft Managed CA

Below are some key points to keep in mind from the diagram

The device has the SCEP cert from Cloud PKI and this is Microsoft Managed CA scenario (where both the root and the issuing CA are hosted on the cloud)

The SCEP which is issued to the user and present in the device is issued by the 'CloudPKI-Issuing CA’

We also understand that for the device to trust the SCEP certificate, it must possess the entire certificate chain. This chain comprises two certificates: one issued by the root to the issuing CA, and the other being a self-signed certificate issued by the root to itself.

Thus far, we have established that the device holds three certificates: one root, one intermediate, and one SCEP (user certificate).Just as a website running https has an SSL certificate bound to it, a Wi-Fi access point/RADIUS server also has a certificate that secures the connection. Similar to a secure website, the Wi-Fi access point/RADIUS server has an SSL certificate issued by the CA and assigned to the hostname of the RADIUS server.But who is going to issue this certificate? It is issued by our on-premises CA.

Currently, Cloud PKI does not have the capability to issue certificates to non-Intune managed devices. Since a Wi-Fi endpoint cannot be enrolled in Intune, the certificate must come from our on-premises CA.

Additionally, the Wi-Fi access point will not inherently trust this SSL certificate. Therefore, the Wi-Fi access point needs to have the certificate chain (i.e., the issuing and root certificates of the on-premises CA) that issued the SSL certificate.

Thus far, we have established that the Wi-Fi access point/RADIUS server has two certificates: The SSL certificate (issued by the on-premises CA) and the root certificate/chain for the on-premises CA. Now let’s understand below how the connection happens for this scenario.

Understanding the connection flow

Now let’s understand how the connection flow happens during a CBA by utilizing a certificate from CloudPKI by referencing the below image:

Figure 1.34: Figure showing the connection for cert-based auth for Microsoft Managed CA

As illustrated in the diagram above, the following steps outline the process a device follows when attempting to connect to a Wi-Fi access point using a SCEP certificate issued via Cloud PKI.

When the device wants to connect to the Wi-Fi endpoint, it sends a connection request to the broadcasted Wi-Fi SSID, akin to sending a greeting message. Although a three-way handshake occurs, we will not delve into its details of it here.

The Wi-Fi endpoint/Radius responds to the device's connection request by sending the SSL certificate issued by the on-premises root CA. This certificate will be used to encrypt the communication between the Wi-Fi endpoint/Radius and the device moving forward.

However, the device will not inherently trust this SSL certificate, as it was issued by an on-premises CA that the device does not recognize.For the communication between the device and the Wi-Fi endpoint/Radius to proceed, the device must trust the SSL certificate of the Radius server. This trust can only be established if the device already possesses the certificate chain of the Wi-Fi's SSL certificate.Thus, the device beforehand needs to have the root certificate of the on-prem CA (issued by the on-prem root/to the on-prem root)How will the device get the root certificate of the on-prem root CA?- We need to ensure it is deployed via Intune by creating a trusted root certificate profile.Conclusion from this step: The device now needs to have 4 certificates with it!:

The SCEP user cert (issued by the Cloud PKI) +

Root cert of the Cloud PKI chain +

Intermediate cert of the CloudPKI chain +

Root certificate of the on-prem CA (which issued the SSL for Wi-Fi endpoint/Radius)

In the next step of the communication, the device will present the user SCEP certificate (obtained from Cloud PKI) to the Wi-Fi access point/RADIUS server for authentication.

However, the Wi-Fi endpoint will not inherently trust this user SCEP certificate, as it originates from the Cloud PKI CA, which the Wi-Fi endpoint is unfamiliar with.Therefore, for the Wi-Fi endpoint/Radius server to recognize and trust the user SCEP certificate generated by Cloud PKI, it must possess the certificate chain of the SCEP certificate which is the Root cert of the CloudCA (i.e. issued by the root/to the root) and the Intermediate cert of the Cloud CA (i.e. issued by the root/to the issuing) as seen in the diagram below.Conclusion from this step: The Wi-Fi endpoint/Radius now needs to have 4 certificates with it !

The SSL cert (issued by the on-prem CA) +

Root cert of the on-prem CA +

Root cert of the Cloud CA +

Intermediate Cert of the cloud CA

Challenge here: How do you get the CloudPKI chain certs to the Wi-Fi endpoint/Radius server?

Well, the Wi-Fi endpoint/Radius is not enrolled to Intune so we cannot leverage Intune here to deploy it. We can deploy it via GPO or it needs to be installed manually/sideloaded.

To summarize, the following certificates need to be present on both parties for certificate-based authentication to work in this scenario:

Device | Wi-Fi endpoint/Radius
SCEP cert issued by Cloud PKI | SSL cert issued by on-prem CA
Root cert of the Cloud PKI | Root cert of the on prem
Issuing Cert of the Cloud PKI | Root cert of the Cloud PKI
Root cert of the on-prem CA | Issuing Cert of the Cloud PKI

Table 1.6: List of certificates needed to facilitate cert based auth in Microsoft Managed CA scenarioIf the aforementioned certificates are deployed and installed on both parties (i.e., the end device and the Wi-Fi endpoint) in advance, we can seamlessly achieve the required certificate-based authentication using the SCEP certificate originating from Cloud PKI.

Scenario 2: CBA for BYOCA

Let's keep all the concepts from the previous section in mind and examine their applicability in Cloud PKI scenarios where we have a BYOCA setup, meaning the Issuing CA is in the cloud and anchored to the on-premises root CA.

Understanding the Setup

In the diagram below, we have the same setup with the device on the left side and the Wi-Fi endpoint on the right. Similar to the previous scenario, the device has a SCEP certificate issued to a user by the Cloud PKI Issuing CA.

Figure 1.35: Figure showing the connection for cert-based auth for BYOCA

We have the below key points to keep in mind:

For the device to trust the SCEP certificate, it needs the certificate chain of the Cloud PKI CA. Therefore, the device must have the Issuing CA certificate (issued to Cloud PKI by the on-premises root) and the self-signed root certificate of the on-premises root CA.

On the right side, the prerequisite for the Wi-Fi endpoint/RADIUS server involves an SSL certificate issued to the Wi-Fi endpoint/RADIUS by the on-premises CA. For the Wi-Fi endpoint to trust this certificate, it must have the certificate chain of the SSL certificate, which includes the certificate issued by the root CA to itself (the same self-signed certificate that the device also needs, as mentioned above).

The key point I want to emphasize is that the chain of the SCEP certificate obtained by the device and the chain of the SSL certificate held by the Wi-Fi endpoint/RADIUS server both originate from the same on-premises root server. This means that when the device attempts to connect to the Wi-Fi and is presented with the SSL certificate, it inherently trusts it because it already possesses the root certificate. Similarly, when the Wi-Fi endpoint/RADIUS server examines the SCEP certificate, it trusts it as well, since it also has the same root certificate.Important Conclusion: Therefore, the conclusion is that in the case of BYOCA with Cloud PKI, there is no need to deliver or install any additional root certificates on either party for chain building, as both already have the same root certificate. In comparison, for Microsoft Managed CA scenarios, there is an overhead of manually installing an additional certificate on the Wi-Fi endpoint/RADIUS server.

Tips:

Up to six Certificate Authorities (CAs) can be created within an Intune tenant.

Intune hosts the Certificate Revocation List (CRL) distribution point (CDP) for each CA. The CRL validity period is seven days, with publishing and refresh occurring every 3.5 days. The CRL is updated with each certificate revocation.

Intune supports RSA for signing and encryption algorithms, with key sizes of 2048, 3072, and 4096.

Intune supports SHA-256, SHA-384, and SHA-512 for hash algorithms.

Mixing SCEP URIs from Cloud PKI with SCEP URLs for on-premises NDES within the same SCEP profile is not supported.

Extended Key Usage (EKU) determines the intended purpose of the certificate. EKU must be selected when creating the Root CA, Issuing CA, and SCEP profile. Planning ahead is essential, as the EKU list cannot be modified after CA creation in the portal.

For security reasons, 'Any Purpose EKU' is not permitted in Cloud PKI.

The CA’s created in CloudPKI are internal to the tenant and are not Public Cas

Cloud PKI root and issuing CAs, and BYOCA issuing CAs anchored to a private CA, can exist in the same tenant because Cloud PKI can support both deployment models concurrently.

Our 2 cents

Cloud PKI is a valuable addition to the Intune suite by Microsoft, offering several advantages over maintaining an on-premises NDES/PKI infrastructure. While there are minor capability gaps, many features and capabilities are currently under development and will be released soon.I believe customers should seriously consider this solution as it represents a significant step towards becoming cloud-native and reducing the on-premises footprint. For those who wish to maintain both environments during the transition, they can utilize Cloud PKI with the BYOCA (Bring Your Own Certificate Authority) solution, where the root CA remains on-premises, and the issuing CA is hosted in the cloud. This approach allows them to benefit from the best of both worlds.For some, the $2 pricing might seem a bit steep. However, it is important to note that this is not the final pricing, and the Microsoft Business Desk or your Account team can assist in securing substantial discounts. Additionally, if you opt for the entire suite, which includes over eight product capabilities, the overall cost is significantly reduced.Lastly, I have noticed several blogs online suggesting that Cloud PKI licensing is merely a way for Microsoft to generate additional revenue, which is perceived as unfair. However, it is important to recognize that Cloud PKI is an offering designed to make PKI management easier, faster, more reliable, and to reduce on-premises dependency, which naturally comes with a licensing cost. Customers have the option to either adopt the Cloud offering or continue using the on-premises NDES solution, which is free. Therefore, this should not be viewed as a coercive measure, but rather as a strategic direction from Microsoft towards a fully cloud-based future.Also having an offering from Microsoft like Cloud Radius, in conjunction with Cloud PKI, would be highly beneficial. This would further reduce on-premises dependencies for customers, as they could use certificates issued by Cloud PKI with a cloud-based Radius solution, thereby eliminating the need to set up on-premises Radius servers for authentication. Microsoft is aware of this customer ask, and based on public demand, it is hoped that a cloud version of Radius might be introduced in the future.

Summary

This chapter provided a comprehensive overview of client certificates, including their purpose, types, and advantages. It began by examining the traditional certificate deployment approach using on-premises NDES and contrasted it with the modern, streamlined methodology enabled by Cloud PKI. A detailed comparison between the two highlighted key differences across various operational parameters.The chapter then delved into the end-to-end certificate delivery process, offering a step-by-step breakdown supported by illustrative diagrams and log references at each stage. It also covered the setup procedures for Cloud PKI, outlining the available deployment models and reporting capabilities.In the latter part of the chapter, we explored how to leverage the issued SCEP certificate for certificate-based authentication with a RADIUS/NPS server, detailing the connection flow and configuration steps involved. The chapter concluded with practical tips and our '2 Cents' to reinforce understanding and support successful implementation.In the upcoming chapter, we'll explore how to secure Windows devices in alignment with Microsoft's Zero Trust principles by leveraging Endpoint Privilege Management (EPM).

2 Elevating Endpoint Privilege Management: Control and Security

Join our book community on Discord

https://packt.link/UWVMzIn this chapter, we will understand the necessity of EPM and its alignment with Microsoft's Zero Trust principle. After grasping the basics, we will conduct a brief comparison of EPM with competing third-party products. Subsequently, the chapter provides a detailed overview of the delivery and installation process of the EPM agent on devices, including the background processing during EPM policy delivery, accompanied by logs and registry entries at each step to aid in troubleshooting EPM-related issues. Finally, the chapter will discuss the deployment strategy to be followed when rolling out this feature, concluding with our "2 Cents" insights on the practical usability of this feature.The following main topics will be covered:

Background and Goal of EPM

Key features and advantages over compete

Requirements of EPM and supported scenarios

Agent Installation and communication flow

Background flow for EPM policy delivery

Foreground flow for EPM policy implementation

Understanding the Directory, service logs and Registry

Troubleshooting the Flow

Gathering Reporting and Insights

Using EPM tools

Deployment Strategy

Other Important Determinations

When to Use Endpoint Privilege Management (EPM)—and When Not To

Our 2 Cents

Let’s get started!

Understanding the background and significance of privilege management

In the opening section of this chapter, we will explore the importance of implementing privilege management and examine the potential risks and vulnerabilities that can arise in its absence within an organization.

Need for Privilege Management

In IT administration, security professionals often advocate against granting end user’s administrative access to their devices. This stance is rooted in the belief that admin access can expose both the devices and the enterprise to significant vulnerabilities. With admin privileges, end users can inadvertently install malicious files, leading to system-level changes that compromise security.To mitigate these risks, security administrators prefer to limit end users to standard user accounts. This restriction minimizes their privileges, preventing them from installing unauthorized applications and making critical system changes.

Risks Associated with Admin Access

Below are the major risks associated with granting admins privileges to end users:

Installation and execution of unauthorized processes/applications

Installation of malware

Disabling of security and system settings

Modification of file system permissions and desktop configurations

However, end users often argue that the lack of admin access hampers their productivity. They seek the flexibility to install work-related applications as needed, without the delays associated with administrative provisioning.

Limitations of Standard User Access

Below are the major limitations of not providing admin access to end users:

Inability to install necessary applications promptly

Increased IT admin overhead- who have to come and do the installation on end user’s device as per need.

This situation presents a dilemma: Should end users be restricted to standard accounts, thereby ensuring robust security but potentially reducing productivity? Or should they be granted admin access, risking non-compliance with Microsoft's Zero Trust guidelines and exposing the organization to potential attacks from malicious software?It is not merely a binary choice, and the solution is a careful balance between maintaining security and enabling productivity by using Endpoint Privilege Management (EPM).

Goal of EPM

The goal of Endpoint Privilege Management (EPM) is to strike the right balance between security and productivity, while adhering to Microsoft's least privilege model (Zero Trust model). EPM ensures that end users do not have administrative access to their machines, thereby mitigating associated risks. Simultaneously, it prevents end users from being restricted to standard user privileges at all times, allowing them the ability to install or elevate applications as needed for their business requirements. This approach ensures that productivity is not compromised while maintaining a secure environment. EPM effectively finds a middle ground in this scenario.EPM is a combination of below 2 stacks:

Figure 2.1: EPM stack visualization

EPM = Privilege Management + Application Control

= (managing the user’s admin privilege for a specific app session)

+

(controlling which app will run in the device in admin context)

Advantages of EPM

EPM plays a crucial role in mitigating attack vectors on devices. By implementing EPM for standard users, we gain several advantages:

Restricted Installation of Malicious Software: The installation of spyware, trojans, and malware is significantly limited.

Limited System Configuration Changes: End users, being standard users, are prevented from making system-wide configuration changes.

These measures ensure a secure environment while maintaining the necessary balance between security and user productivity.

Key Features and comparison with competitors

In this section, we will explore the key features of EPM and examine how it stands out compared to other competing products in the market

Key Features of EPM

Below are the key features of using EPM:

Achieve least privilege in the device: Using EPM for Standard users adheres to Microsoft's standard of least privilege. Using EPM we provide just enough access to the end users for a specific application session thereby limiting attack surfaces.

Seamless application control: Using EPM we can deliver trust-based application whitelisting, with a flexible policy engine to set broad rules, choose automatic approval for advanced users - protected by full audit trails - or utilize challenge-response codes.

Auditing and Reporting: Using EPM we can provide a single, unimpeachable audit trail of all user activity, speed forensics and simplify compliance with complete reporting for multiple stakeholders.

Advantages of EPM over competitors

Below are the key advantages of using EPM over a 3rd party compete solution:

Integrated First-Party Solution with Microsoft Intune: EPM seamlessly integrates with the Intune console, allowing administrators to manage settings without needing to switch to another console.

No Third-Party Agent Required: The EPM agent, developed and owned by Microsoft, is automatically installed on devices. This eliminates any dependency on third-party agents.

No Incompatibility Issues with OS: The EPM agent is designed to be fully compatible with current and future OS versions, ensuring consistent performance and reliability.

EPM in Security landscape

In this section we are going to explore how EPM fits into the security landscape and the corresponding technologies that can be used alongside it. As per our organization’s demands we need to identify which technology to use and when. These technologies are mutually exclusive but can be used together or independently, depending on our use case as explained below:

Technology
Function
Concept

Endpoint Privilege Management (EPM)
Elevates a standard user to an admin for a specific application session.

Follows Microsoft's Zero Trust model, reducing attack vectors by ensuring end users are not local admins.

Maintains productivity by allowing elevation to admin status for specific application sessions.

Does not restrict applications from launching or running on the device.

EPM essentially provides Just-In-Time (JIT) access for users during an application session.

AppLocker and Windows Defender Application Control (WDAC)
Determines which applications can run on a device by creating rules (XMLs) to whitelist or blacklist applications.

Limits which applications can run to reduce attacks on devices.

Unauthorized applications are prevented from launching or running on the OS.

Does not govern application installation or relate to user access levels.

Local Administrator Password Solution (LAPS)
Manages and maintains the passwords of local accounts on devices.

Enforces minimum password criteria for local admin accounts, manages these passwords centrally by backing them up to Azure, and allows for centralized password changes when needed.

Ensures local admin account passwords are secure and centrally managed.

Table 2.1: Brief of commonly used security technology in Windows landscape

Requirements, Supported Scenarios and Pricing

Now let’s understand the pre-requisites of using EPM and the scenario it supports.

Support Scenarios

EPM supports the following scenarios:

Microsoft Entra Joined or Microsoft Entra Hybrid Joined: Devices that are either joined to Microsoft Entra or have a hybrid configuration.

Microsoft Intune Enrollment or Microsoft Configuration Manager Co-managed Devices: Devices enrolled in Microsoft Intune or co-managed with Microsoft Configuration Manager, with no specific workload requirements.

Clear Line of Sight on TCP Port 443: Devices must have an unobstructed connection (without SSL inspection) on TCP port 443 to the following endpoints:

*.dm.microsoft.com

*.events.data.microsoft.com

Supported versions

EPM supports the following versions:

Windows 11

Version 24H2

Version 23H2 with KB5031455

Version 22H2 with KB5029351

Version 21H2 with KB5034121

Windows 10

Version 22H2 with KB5030211

Version 21H2 with KB5030211

Windows 365 (CloudPC) is supported using a supported operating system version

Workplace-join devices are not supported by Endpoint Privilege Management

Azure Virtual Desktop is not supported by Endpoint Privilege Management

License and Pricing

EPM requires an additional license beyond the Microsoft Intune Plan 1 license. We have two options:

Stand-alone License: Add-on license of EPM is priced at $3.00/user/month

Microsoft Intune Suite: Intune Suite license is priced at $10.00/user/month. This provides access to all the Intune suite products.

These prices are the retail prices quoted in the official Microsoft documentation. However, they are not final. For bulk licenses, it is recommended to contact the Microsoft Business Desk/Sales team to get the best deals and applicable discounts.Now that we have covered the requirements and prerequisites, let’s now turn our attention to the core focus—The Flow

Flow during EPM agent installation and Communication

We’ll begin by examining the behind-the-scenes flow that takes place during the installation of the EPM agent on a device and its communication with the service post installation.

Agent Installation flow

By default, the EPM agent is not present in the Windows operating system. It is installed when the EPM Elevation setting policy is deployed to the device. Let's understand the background process during the EPM agent installation using the below diagram:

Figure 2.2: Block diagram showing the flow of EPM agent installation

With the above block diagram as a reference, let’s walk through the background steps that lead to the installation of the EPM agent on the device.

The first step involves deploying the Device Health Monitoring (DHM) policy to the device from Intune. This can be tracked in real-time by examining the SyncML trace on the device.

This policy creates a scheduled task on the device, responsible for enrolling the device to MMPC. This process is similar to how a device gets enrolled to Intune using group policy, where a scheduled task is created to handle the enrollment.

The scheduled task runs deviceenroller.exe, which enables the device to reach out to the MMPC endpoints and enroll itself with the MMPC channel.

The below screenshot shows a successful MMP_C enrollment of a device which is logged in event viewer with ID 4023

Figure 2.3: Eventviewer log from device showing successful enrollment to MMP-C

Once the device is enrolled, the EPM agent is pushed to the device. The installation process involves the device reaching out to a specific URL to download EPMAgent.exe, and msiexec handles the installation. The EPM agent installation is executed by the same CSP that triggers the IME installation when the device is enrolled into Intune, i.e., /Device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI. Msiexec starts installing the MSI file from the system's Local AppData folder.

Let’s take a look at the screenshot below, which displays the SyncML trace indicating this operation:

Figure 2.4: SyncML trace from the device showing the delivery of EPM agent

Once the EPM Agent has been installed we can see its version in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EPMAgent as seen below-

Figure 2.5: Registry location in the device showing the EPM agent version

After the agent is installed, a service is created to manage the processing. The below screenshot shows the service created with the display name Microsoft EPM Agent Service and the location of its executable.

Figure 2.6: EPM service details from a device

As we have understood the agent installation flow, in the next section, we’ll take a brief look at how the EPM agent, once installed, communicates with the Intune service to retrieve policies onto the device

Agent Communication flow

Before diving into how the EPM agent functions and retrieves applicable policies, let’s take a brief detour to understand the fundamentals of OMADM and MMPC—concepts that will be valuable for grasping the EPM agent’s workflow.Microsoft Management Platform Cloud (MMP-C) and OMADM (Open Mobile Alliance Device Management) are both frameworks used for device management, but they differ significantly in their approach and capabilities.

Microsoft Management Platform Cloud (MMP-C)

MMP-C is a modern cloud-based management platform designed to enhance device management and security within an organization. Key features include:

EPM, Device Inventory and MDQ: MMP-C integrates with EPM, Device Inventory, and Multi-Device Query, all utilizing the MMP-C channel for policy delivery. In the future, additional workloads may transition to MMP-C due to its numerous advantages.

Declared Configuration Service: MMPC uses the Declared Configuration Service (dcsvc) for policy synchronization, which is faster, more reliable, and more secure compared to traditional methods.

Linked Enrollment: Devices enrolled in MMPC have a dual enrollment setup, where the primary enrollment is through Intune, and the secondary enrollment is through MMPC.

Cloud-Based Infrastructure: Leveraging Microsoft's cloud infrastructure, MMPC provides scalable and reliable management services.

Open Mobile Alliance Device Management (OMADM)

OMADM is an older protocol used for device management, primarily designed for mobile devices. Key features include:

Structured Model: OMADM follows a structured model where devices sync on a schedule, fetch policies, and apply them.

Policy Management: It has been the backbone of policy management in Microsoft Intune for years, providing a standardized way to manage devices.

Mobile Device Focus: OMADM was originally built for mobile phones, and while it has been adapted for broader use, it retains some limitations in flexibility and speed compared to newer methods.

As illustrated below, the device now operates with two channels: the OMADM channel and the MMP-C channel. Both channels are utilized to deliver relevant policies to the device.

Figure 2.7: Block diagram showing the communication b/w device and Intune service

Now that we have understood the basics of OMADM and MMP-C let’s do a quick comparison between them below:

Features | MMP-C | OMADM
Technology and Speed | Utilizes the Declared Configuration Service, which is faster and more secure | Follows a scheduled sync model, which can be slower and less flexible.
Enrollment | Supports dual enrolment with linked configurations, enhancing management capabilities. | Traditional single enrolment focused on mobile devices
Integration | Integrates seamlessly with modern cloud services and Endpoint Privilege Management. | Primarily used for mobile device management with structured policy application.

Table 2.2: Comparison between OMADM and MMP-C channelAs established above, EPM leverages the Microsoft Management Platform Cloud (MMP-C) channel for policy delivery, thereby enhancing security and increasing speed. In the next section we will understand in detail how the EPM policies are deployed to the device using the MMP-C channel.

Background Flow for Policy Delivery

Let's reference the diagram below to understand the background flow involved in the delivery of an EPM elevation rule policy and the internal components at play.

Figure 2.8: Block diagram showing the flow of EPM policy delivery

Below are the steps involved during the delivery of EPM related policy to the device

As established in the previous section, given that the device is MMPC enrolled, it can now receive the EPM-related policy from Intune via the MMPC channel, as illustrated in the above diagram.

Naturally, there must be a client on the device responsible for receiving and processing the policy. Similar to the OMADM client, which processes regular MDM policies, the WinDC client on the device is responsible for receiving the EPM-related policy via the MMPC channel.

After the WinDC client receives the policy and writes it to the correct location (namespace) on the device, the EPM adapters come into play. These adapters were installed on the device when the EPM agent was installed, which occurred when the EPM setting policy was targeted to the device.

The adapter is responsible for further processing. It reads the policy values from the namespace and writes them to the local storage on the device, along with all relevant registries.

The EPM client then ingests this policy and enforces it whenever applicable marking the EPM policies active. When an end user attempts to elevate an application, the EPM client and the EPM service work together with the Management Libraries to implement the policy that was previously written to the device's local storage.

So far, we've explored how the EPM elevation rule policy is delivered to the device from the Intune service using MMP-C. In the next section, we'll delve into the processes involved in implementing the EPM rule policy on the device based on user’s actions.

Foreground Flow for policy implementation:

Now, let's understand the foreground flow—the steps the user takes that lead to the policy elevating a specific application by referencing the below diagram:

Figure 2.9: Block diagram showing the flow behind EPM initiation for an application session

The following steps align with the block diagram above and illustrate the underlying process

Application Detection: This is the initial step in the foreground process. Detection can occur when:

The end user right-clicks on a specific application and selects Run with elevated access, or

The filter driver in the operating system automatically detects the application's binaries when the app is launched.

In essence, whether the user consciously tries to elevate the app by clicking Run with elevated access or the app is launched in an admin context by another process, the application's binaries will be detected.

Confirmation of Application Attributes: The filter driver verifies the application being launched, ensuring details such as the file name, location, and hash are correct. This information is double-checked and logged.

Rule Lookup and Implementation: Once the application is verified, the EPM service looks up the applicable rules for that application to determine whether it should be allowed to elevate or be denied. In both cases, the action is logged in the relevant logs (explained in detail in the next section), and a consent UI appears on the screen.

Condition 1: If elevation is not permitted, the end user receives a prompt (generated by the ConsentUI) indicating that the elevation of the application is not permitted by the administrator.

Condition 2: If elevation is permitted but subject to specific conditions, those conditions take effect. For example, the policy might require the end user to provide a business justification or complete multi-factor authentication (MFA).

If Condition 2 is met, after fulfilling the requirements specified by the ConsentUI (such as MFA or justification), the EPM service launches the application session using a virtual admin account, enabling the end user to enjoy admin privileges while interacting with the app during that specific session.

The application which is elevated by the user always runs with a virtual admin account which has the admin token and the necessary privileges.

Up to this point, in the book we've developed a comprehensive understanding of the background processes that lead to the installation of the EPM agent. We've also examined how the EPM elevation rule policy is delivered to the device and the flow involved in that process. Additionally, we explored the foreground flow triggered when an end user launches an application governed by the elevation policy.

Understanding the Directory, Service, Logs and Registry

In this section, we’ll delve into the key files and .dlls involved in EPM’s operation and take a closer look at the relevant logs and registry entries which is going to be very important while troubleshooting related issues.

Working Directory

The working directory for EPM is located at C:\Program Files\Microsoft EPM Agent. Within this directory, we will find many folders essential for the processing of EPM. These folders contain various files, including .dll, .exe, .inf, .sys, .dat, and .config files. Additionally, this directory houses the log files for EPM, which we will examine in detail in the next section.

Figure 2.10: File/Folder structure for EPM

Later in this chapter under various sections, we will explore how all these files within the EPM directory structure are utilized.

EPM Logs

Understanding EPM log files is crucial, as they play a key role in diagnosing issues, identifying root causes, and enabling faster resolution. When troubleshooting EPM, we need to work with the following logs, all of which are located on the device at C:\Program Files\Microsoft EPM Agent\Logs.

EPMService.log

EPM.Log

EPMConsentUI.log

EPMServiceStub.log

ElevationRules.dat

Now let’s understand all the above logs in detail and their significance.

EPMService.log

This log provides detailed information on the activities of the EPM service, which handles significant tasks. It orchestrates the elevation of applications on the device according to the received policy and is responsible for telemetry. The log includes:

The number of elevation rules found/targeted for the user’s SSID.

The filename and the location of the application which is being attempted to be elevated.

If the EPM consent UI was launched and if the app elevation was restricted and the user receives an error message in the Consent UI, this event is also logged.

Whether the user entered justification/MFA and all token-related activities.

Ultimately, it indicates whether the application session was launched in the admin context for the user. The below image is from EPMService.log illustrating the processing involved while the end user tries to elevate any application.

Figure 2.11: EPM Service logs from a working device

The logs will contain numerous file hashes, which may cause some confusion. The EPM service logs the file hash of any application being elevated by the end user.

Prior to this step, the EPM service launches EpmConsentUI.exe (located in C:\Program Files\Microsoft EPM Agent\EpmConsentUI) and EpmServiceStub.exe (located in C:\Program Files\Microsoft EPM Agent\EPMService), and their file hashes are also recorded in the log, along with any other EPM-related executables.It is important to clarify that these hashes are not of the end application being elevated by the user.The key point is that the hash value of everything launched by EPM, whether directly (the end user's application) or indirectly (EPM-related executables), is logged here as seen below.

Figure 2.12: EPM logs showing the file hash id of executables

Above in the logs we have seen a File hash id. Upon closer inspection, we will find that the File hash id belongs to EPMConsentUI.exe (and not the end application the user was trying to elevate, as seen below:

Figure 2.13: Capturing the file hash of EPMConsentUI

Similarly, we can fetch the file hash id of EPMClientStub.exe using PowerShell as seen below. This file hash id would also show in EPMService.log

Figure 2.14: Capturing the file hash of EPMClientStub

EPM.Log

This log shows how exactly the application was detected - if the user right clicked on the app and elevated it or if it was done automatically.

EPMConsentUI.log

The system logs each instance when the EPM Consent UI dialog is initiated on the device. Additionally, if an end user attempts to elevate an application that is restricted by the elevation rule policy and encounters the standard error message ("Your organization doesn't allow you to run this app as an administrator"), this event is also recorded in the log.

Figure 2.15: EPMConsentUI logs showing error when a restricted app is launched

ElevationRules.dat

We observe the creation of numerous .dat files in C:\Program Files\Microsoft EPM Agent\Policies\ElevationRules. Let’s take a look over these .dat files below:

Figure 2.16: Location of .dat files for EPM

These files contain the names and information of applications targeted by the EPM policy, as well as all the settings configured within the policy. This information aligns with what has been established by the administrator at the portal and what the device should have received and populated in the registry.The content of the .dat file looks like below. It contains everything configured in EPM related to the specific application. In the below example, the file is related to a rule for Notepad ++

Figure 2.17: Content of .dat files for EPM

MDMDiag Logs

We can examine the MDMDiag logs on the device by generating a diagnostic report. In these logs, we can find the GUID for MMPC enrollment, which should match the enrollment GUID previously identified for MMPC. Additionally, the logs will reference the EPMAgent.msi that gets downloaded.

Figure 2.18: MDM Diag logs highlight MMP-C related information

In this section, we explored the various EPM-related log files and their significance. These logs are essential for diagnosing issues—whether related to the delivery or implementation of EPM elevation rule or setting policies—and can help pinpoint root causes and streamline troubleshooting

Scheduled Task and Registry

Once a device is targeted by an EPM policy through Intune, a scheduled task is created on the device to handle its enrolment into the MMP-C channel. Let's take a closer look at this scheduled task in the following section.

Scheduled Task

Let’s first see a device wherein the EPM policy was not targeted. Hence in this case we see only 1 GUID entry under EnterpriseMgmt which has the schedule task used for enrolling the device to Intune as seen below:

Figure 2.19: Task scheduler in a device which is not targeted via EPM policies

Now let’s see the task scheduler of a device which was targeted via EPM policy below. In this case we see there is 1 more GUID under 'EnterpriseMgmt' The new GUID is for MMPC enrolment. This GUID contains the scheduled task which is responsible for enrolling the machine with MMPC. The device will get the EPM policy only after it has got enrolled with MMPC hence this is important.

Figure 2.20: Task scheduler in a device which is targeted via EPM policies

Location: Task Scheduler Library\Microsoft\Windows\EnterpriseMgmtAfter the scheduled task runs automatically, we can verify whether the device was successfully enrolled into the MMP-C channel by checking its Last Run Result and the logs discussed earlier in this chapter.In the next section of this book, we’ll delve into the key Registry values that are critical in the context of EPM.

Registry

There are four critical registry entries to consider during troubleshooting EPM as explained below:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\xx-yy-xx (New Enrollment GUID for MMPC)

After a device is enrolled in Microsoft Managed Desktop (MMPC), a new GUID (node) is created in the registry at the above location. Consequently, the device will have two GUIDs under the enrollment node:

The first GUID is the primary one, created when the device was initially enrolled in Intune.

The second GUID is created after the device is enrolled in MMPC. The first GUID contains a reference to the second GUID.

It is important to note that under the first GUID, there is a sub-node called Linked Enrollment containing a REG_SZ value. This value is populated with the second GUID of the MMPC enrollment as seen below:

Figure 2.21: Registry in the device showing Linked enrollment for MMP-C

Also as seen above there is a REG_DWORD that gets created with the value 1 named MMPCLockedExamining the second GUID (related to MMPC enrollment) reveals various relevant details, including the AADResourceID, which is the endpoint checkin.dm.microsoft.com as seen below:

Figure 2.22: EPM related registry in the device

This endpoint is necessary for MMPC enrollment (and EPM) and is documented in section Support Scenarios of this book.

This AADResourceID differs from the one associated with the first GUID, which pertains to general OMADM Intune enrollment.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\S-0-000\MSI\{xx-yy-xx}

The EPM agent will be downloaded and installed on the device. This agent is an MSI file that the device needs to download. The information about this MSI file, which is targeted via the EPM policy, is populated in the registry.As shown in the image below, a REG_SZ entry named CurrentDownloadUrl is created in the relevant registry node referenced above. This URL points to the location from which EPMAgent.msi is downloaded by the device. This URL is likely load-balanced or location-specific.

Figure 2.23: registry in the device illustrating how EPM agent got downloaded

By extracting this URL from the registry (e.g., https://epmagent.manage.microsoft.com/epmagentpeeus/epmagentmsi/6.2411.82.2000/EPMAgent.msi) and navigating to it in a browser, the browser will also download EPMAgent.msi, as seen below thereby validating this process.

Figure 2.24: Downloading the EPM agent manually from a browser

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DeclaredConfiguration\HostOS\Config\enrollments\xx-yy-xx\SID\state\KeyValue

Under the above registry hive within the user's SID, we can locate KeyValues. There will be a REG_SZ value containing the EPM policy settings that have been deployed to the device from Intune. As illustrated below, these settings can be opened in Notepad for verification.For example, the device shown below has an EPM rule policy targeted at Notepad++. We can see the application file name and the detection method used, which in this case is the file hash and its value set by the admin in the portal, along with other policy settings.

Figure 2.25: Registry in the device showing the EPM policy related settings

If multiple applications are targeted via the EPM rule policy, their values can be checked here.

This registry entry is crucial as it ensures that the device has received the correct policy payload as configured by the admin.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EPMAgent\RuleLookup\FileName\

A new node called EPMAgent is created in the registry in the above location. Within this node, there is a sub-node called RuleLookup that contains elevation rules for each application configured in the EPM policy in Intune.For example, I have created an EPM elevation rule policy targeting several applications, such as 7zip, Google Chrome, Notepad++, Procmon, and VLC Media Player. As shown in the image below, a node is created for each of these applications under RuleLookup > Filename node.

Figure 2.26: EPM related registry in the device

This registry location is crucial as it helps us identify which applications are targeted by the EPM policy from the device's perspective, ensuring that the device adheres to the specified rules.In this section, we covered the key registry locations relevant to EPM. Familiarity with these locations and their expected values is essential for effective troubleshooting—especially when used alongside the appropriate EPM logs.In the next section, we will examine the EPM service, which serves as the foundation for all EPM-related operations—including elevation control, policy enforcement, and reporting. These activities are comprehensively logged in the EPM logs discussed earlier in this chapter.

EPM Service

As briefly discussed earlier in the chapter, after the EPM agent is installed and running on the device, a service named Microsoft EPM Agent Service (MEMEPMSvc) is created and set to automatic startup. This service runs EpmService.exe, located in C:\Program Files\Microsoft EPM Agent\EPMService, in the System context as seen below.

Figure 2.27: EPM service details in the device

The service should be set as Automatic, and no manual changes are needed to be made to its configuration. Now that we have understood the working of EPM, in the next section let’s discuss how to troubleshoot EPM related issues

Troubleshooting the Flow

The block diagram below illustrates the troubleshooting approach we should follow when addressing any EPM-related issues. It is essential to adhere to a systematic, phased approach. This troubleshooting method aligns with the flow we have established above.

Figure 2.28: Block diagram illustrating the recommended troubleshooting approach for EPM issues

Let's now examine each component from the diagram above and outline a structured approach to troubleshooting EPM-related issues.

Step 1: Verify EPM Policy Creation

Ensure that the EPM policy is correctly created. This involves several checks within the console. For instance, if an end user is unable to elevate a specific application using EPM, begin by verifying the elevation rule policy and the elevation setting policy in the portal. Confirm that the logic for detecting the application in the EPM rule policy is accurate (e.g., validating the file hash or certificate used for the application). Additionally, check the assignment of the elevation rule and setting policy in the Intune portal, including licensing and make sure that the device is checking in with the Intune service and the policy deployment shows as success from the Intune portal. These checks are performed at the portal level and do not depend on the end user.

Step 2: Checking device side pre-requisites

If the policy is correctly created and deployed, but the issue persists, focus on the specific device. Ensure that the device meets the EPM prerequisites, such as the supported OS version and required patches. Also, here we need to make sure that the device is now Workplace joined (It is either EntraId joined or Hybrid Entra Joined and enrolled). This step involves verifying that the device complies with these requirements.

Step 3: Verify Device Enrolment to MMPC

After confirming the previous steps, check the device's enrolment to Microsoft Managed Desktop (MMPC). Verify if the scheduled task responsible for enrolling the device to MMPC is created. Examine the Enterprise Diagnostic Provider logs to determine the success of the MMPC enrolment and ensure the relevant registry entries are populated correctly. Additionally, identify the enrolment GUID of the device in the registry.

Step 4: Confirm EPM Agent Download and Installation

Check if the EPM agent is successfully downloaded and installed. Verify the presence of the EPM MSI in the registry. Confirm the creation of the EPM folder structure (C:\Program Files\Microsoft EPM Agent) in the file system and the creation of the EPM service. Successful completion of these steps ensures the correct processing and implementation of the EPM policy on the device.

Step 5: Verify EPM Policy Payload Reception

Ensure that the device has received the EPM settings and rules policy payload. Check the registry to confirm that it is populated with the settings as per the policy created by the admin. Verify the creation and correct population of the relevant registry entries.

Step 6: Analyse EPM Logs for Errors

If the policy is received as expected, analyse the EPM logs for any relevant errors. Review the EPM.log, EPMConsentUI.log, EPMService.log, and SPMServiceStub.log located in C:\Program Files\Microsoft EPM Agent\Logs. These logs will indicate any errors preventing the application from launching in the admin context.

Important: Troubleshooting is about following the rule of elimination. By systematically eliminating variables through a structured approach, as outlined above, we can identify the potential issue and resolve it effectively.

In the following section of this book, we will explore how to access and interpret EPM-related reporting telemetry within the Intune portal, and how to derive actionable insights from this data.

Gathering Reporting and Insights

The EPM reports are accessible from the Reports tab within the Endpoint Privilege Management node in the Microsoft Intune admin Center. Navigate to Endpoint security > Endpoint Privilege Management, and select the Reports tab. The report data is retained for 30 days.We have the following categories of Elevation reports:

Managed Elevations Report: This report displays details similar to the Elevation report but focuses only on elevations managed by a Windows elevation rule policy.

Elevation Report by Applications: This report provides details for all managed and unmanaged elevations, aggregated by the application that elevated. Details include:

Elevation Report by Publisher: This report displays details for all managed and unmanaged elevations, aggregated by the publisher of the application that elevated. Details include:

Elevation Report by User: This report provides details for all managed and unmanaged elevations, aggregated by the user that elevated.

The following screenshot from the Intune portal shows the EPM related reports available and how to navigate to them:

Figure 2.29: Location of EPM related reports in the Intune portal

Now let’s take a look over a sample Elevation Report below which shows the username and the device in which the elevation happened, the application that was elevated and the timestamp.

Figure 2.30: Closer look at the EPM Elevation report

Data is processed once every 24 hours, so there may be a delay before seeing data in the elevation usage reports.

Intune provides a set of tools at the device level that allow us to verify which EPM policies have been applied and to review the corresponding EPM settings. These tools are highly effective when used alongside log and registry analysis, as discussed earlier in this chapter.In the next section, we will take a closer look at the available EPM tools and how they can support troubleshooting and validation efforts.

Using EPM Tools

The EPM agent includes a PowerShell cmdlet that assists in diagnosing various issues, such as when a specific whitelisted application fails to elevate successfully. This cmdlet allows us to identify the EPM policies and settings received by the device without the need to check log files or registry locations.The EPM tool is designed for IT administrators who are troubleshooting the device, rather than for end users. IT administrators should follow the steps outlined below to utilize the EPM tools effectively:

Launch PowerShell as an Administrator: The IT administrator needs to open PowerShell with administrative privileges.

Import EPM Agent Cmdlets: In PowerShell, navigate to C:\Program Files\Microsoft EPM Agent\EpmTools and import the EPM agent cmdlets by running the following command:

Import-Module .\EpmCmdlets.dll.

This will import the EPM module.

Figure 2.31: Figure illustrating the use of EPM tools

Utilize EPM Tools: The EPM tools are now ready for use. Below are a few example commands that can be executed:

Get-Policies -PolicyType ClientSettings -Verbose | Format-Table -AutoSize

This gives all applications targeted by the EPM rule policy, along with relevant details such as version and policy ID.

Figure 2.32: Figure illustrating the use of EPM tools- Fetching the EPM settings in the device

Get-Policies -PolicyType ElevationRules -Verbose | Format-Table -AutoSize

Figure 2.33: Figure illustrating the use of EPM tools- getting a list of elevation rules and related applications

Now let’s take a look over the most commonly used PowerShell commands available with the EPM tools and its usage in the table below:

Commands | Purpose
Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll' | Loads the EPM Tools module into our PowerShell session.
Get-Policies | Getting a list of all policies that are received by the Microsoft EPM Agent
Get-ElevationRules | Used to retrieve a list of elevation rules that have been received by the EPM Agent on a device.
Get-ClientSettings | Retrieves client-specific EPM settings, such as telemetry and logging configurations.
Get-FileAttributes | Extracts file metadata and certificate chain information to help build accurate elevation rules
Get-DeclaredConfiguration | Returns the full declared configuration received from Intune, including elevation rules and client settings.
Get-DeclaredConfigurationAnalysis | Compares the declared configuration with the current state on the device to identify mismatches or issues.

Table 2.3: List of commonly used PowerShell commands related to EPMHaving now explored how to enhance EPM-related troubleshooting and log analysis using the device-side EPM tools, we will shift our focus in the next section to the recommended deployment approach for EPM. Given the complexity and multi-layered nature of EPM deployment, it is essential to follow a structured and strategic rollout plan.

Deployment Strategy

Rolling out EPM to devices is not a single-step process. It is essential to conduct thorough due diligence before deploying EPM and removing admin rights from end users. Below, I have outlined the steps that can serve as our deployment strategy for rolling out EPM to our production users:

Figure 2.34: Block diagram illustrating the EPM deployment approach

Now let’s understand each of the blocks in detail below:

Step 1: Onboarding Devices to EPM in Audit Mode

In this step, we need to create an EPM Elevation Setting Policy in Intune and assign it to the users/devices. This will install the EPM agent on the devices, collect relevant data, and send it to Intune for the administrator to review and act. This process is transparent to the end user, who will not notice any changes.As seen below- we must go to Intune Admin Center > Endpoint Security > EPM > Policies > Create Policy > Elevation Setting Policy:

Endpoint Privilege Management: Enabled

Default elevation response: Not Configured

Send elevation data for reporting: Yes

Reporting scope: Diagnostic data and all endpoint elevations

Figure 2.35: Creating EPM settings policy from the Intune portal

Once these settings are in place, the device will be onboarded to both MMPC and EPM. The device will then begin sending all elevation-related data to the Intune service.

Step 2: Reviewing the elevations requests

As IT admins, we can access the portal to view the reports. By navigating to Endpoint Security > EPM > Reports, we can see all the applications that end users are elevating to admin context within our organization.This provides us with valuable insights into which applications generally require elevation to admin by our workforce. Based on this information, we can determine which applications need to be whitelisted via EPM.The advantage of having devices in EPM audit mode is that it allows us to gather comprehensive insights from the end devices about the applications being elevated by end users.

Step 3: Creating Elevation Rule and removing users from admin

Based on the insights gathered in the previous step, we are now prepared to take action. We need to create elevation rule policies for the applications that our users require to run with admin privileges. Utilizing reusable settings can simplify the creation of these EPM rule policies.Once these policies are established, we can proceed to remove the admin privileges from the end users' machines using an Intune configuration policy.During EPM deployment, two key configurations must be defined: the EPM Settings Policy and the EPM Rule Policy. The table below outlines the two most used values for these settings, along with their respective impacts. This comparison is intended to guide decision-making by helping determine the most appropriate configuration for various deployment scenarios.

EPM Setting Policy (Default behavior for all apps)
EPM Rule Policy (behavior for whitelisted apps)
Impact

Deny All
Support Approved

This is the most restrictive combination of settings that can be chosen if the organization wants to implement strict controls. By combining these two settings, it ensures that when an end user attempts to elevate to admin for whitelisted applications, they can only do so once it has been approved by the admin from the portal. This implies the highest level of control and restriction.

This combination of settings ensures that IT administrators closely monitor the applications that can be elevated within the organization, and no application is elevated unless explicitly approved. If an end user attempts to elevate any application that has not been whitelisted, the request is denied.

Support Approved
Automatic

This combination of settings is relatively less restrictive. It ensures that any application deemed necessary for productivity by the admin and whitelisted will be elevated automatically when launched by the end user. For any other application, when the end user attempts to elevate it, the request is sent to the admin for approval. Once approved, the end user can launch the application.

This combination of settings is moderately restrictive. By using this approach, the admins only supervise the elevation of applications that have not been whitelisted.

Table 2.4: List of commonly used EPM settings and its impactNow that we have reviewed the possible configuration values for EPM, the next section will focus on how to effectively roll out EPM in a production environment.

Rolling out EPM

Rolling out EPM in a production environment involves multiple steps, as illustrated in the block diagram below. On the device side, it’s essential to ensure that all EPM prerequisites are fulfilled and that the device is enrolled in Intune. On the administrative side, the Intune administrator must deploy EPM by configuring the appropriate policies. Finally, the rollout progress can be monitored by reviewing the logs discussed earlier in this chapter.

Figure 2.36: Block diagram illustrating the steps for EPM rollout

In this section we are going to focus on the Task at admin end for onboarding devices to EPM.There are two steps involved in the process as explained below:

Step 1: Creating the EPM Elevation Setting policy (which is same as the one discussed in the previous section)

This policy is going to enable the EPM functionality in the device. It is going to install the EPM agent and send diagnostic information from the device to Intune service. Creating this is pretty much straight forward and we just have to change a toggle to set it up. Also, in this policy we determine what is the default behaviour when any user tries to elevate any application (for the applications which haven't been explicitly whitelisted). The below figure shows how we can navigate to EPM policy from the Intune console:

Figure 2.37: Creation of EPM Elevation rule policy in the Intune portal

We select Elevation setting policy in the above screen and click on Create. This takes us to the next screen as seen below where we define the EPM related settings.

Figure 2.38: EPM settings in the Intune portal

Once the elevation Setting policy is created and deployed- it will enroll the device to MMP-C and onboard to EPM by installing the EPM agent. Now the next step is creating an EPM Elevation rule policy as discussed below.

Step 2: Creating rules for whitelisting applications in EPM

Now there are a few determinations that we need to make here while deciding on the logic for whitelisting an application in EPM Rule policy.Here we have to decide how we want to whitelist the applications:

Using File name and file hash

Using a Certificate

Both are valid options and can be used. If we want to use file name and hash, then we will have to get the filehash of the executable that we want to whitelist. We can get that using Get-Filehash PowerShell command.On the other hand, if we want to use certificate, we can export the same from the executable and upload it to the policy. To do the same we need to go to Properties of the .exe/.ms1 (by right clicking on it) > Digital Signature > Details.Now a new dialog box will open up. Click on View Certificate > In the new box click on Details tab > Copy to file…

Figure 2.39: Steps for extracting certificate of an executable for EPM rule policy creation

Now a wizard will open which will enable us to export the certificate. We need to click on Next > Select 'DER encoded binary X.509 > Browse and save it to a location of our choice as seen below:

Figure 2.40: Steps for extracting certificate of an executable for EPM rule policy creation

Now the export of the file should be successful.

Figure 2.41: Figure showing successful export of the certificate

We can open the certificate and see its parameters including the Issued To parameter as seen below:

Figure 2.42: Figure showing the extracted certificate to be used in EPM rule policy creation

Now, as seen below, we can use the exported certificate to create an EPM rule policy. We will have to provide the elevation conditions as well as the file information- which EPM will use to detect the application when it is launched by the user.

Figure 2.43: Step showing EPM elevation rule creation in the Intune portal

While creating the elevation rule policy in EPM, there are some key determinations that we must make, which has been explained below.

Other Important Determinations:

Two additional key EPM settings—Child Process Behaviour and Argument List—warrant detailed discussion for clarity. Let’s examine each of them closely below.

Child Process behaviour

Child process behaviour allows us to control the context when a process elevated with EPM creates a child process. This behaviour allows you to further restrict processes which normally would be automatically delegated the context of its parent process.Windows automatically delegates the context of a parent to a child, so take special care in controlling the behaviour for your allowed applications. Ensure you evaluate what is needed when you create elevation rules and implement the principle of least privilege.

Figure 2.44: Settings while configuring EPM rule policy in the Intune portal

Argument List

EPM enables the configuration of file elevation rules based on command-line arguments, offering precise control over which files can be elevated and under what conditions. Specifically, an EPM rule can be tailored to permit elevation only when a predefined argument is used. If a user attempts to elevate a file with an unapproved argument, the elevation is denied.When a user initiates elevation, EPM evaluates the command-line argument against the rule's defined parameters. If there’s a match, elevation is granted; otherwise, it is blocked.This approach delivers:

Enhanced security by limiting elevation to explicitly intended use cases

Greater administrative control through fine-tuned rule definitions

Reduced risk of accidental or malicious elevation by enforcing argument-specific conditions

For instance, we can create an elevation rule for the dsregcmd tool—commonly used to assess device status in Microsoft Entra ID—by specifying approved arguments such as /status and /listaccounts. To prevent unintended actions, sensitive switches like /leave, which unregisters a device, are excluded.With this setup, elevation is granted only when one of the allowed arguments is used as seen below. Any attempt to run dsregcmd with an unapproved switch, like /leave, is automatically blocked—ensuring secure and intentional use.

Figure 2.45: Option to specify EPM argument list

- EPM now supports Windows devices with Arm64 processors as well.

- The EPM policy supports both user and device assignments:

User Assignment: When the policy is assigned to a user, the EPM agent is installed, and the policy is applied after the user signs into the device.

Device Group Assignment: When the policy is assigned to a device group, the EPM agent is installed, and the policy is applied even before the user logs into the device.

- The EPM agent is not installed as part of the Autopilot OOBE process. Consequently, the EPM policy is pushed to the device, and the agent is installed only after the device reaches the desktop screen during the Autopilot process.

- There is no BYOD support for EPM. This is so because the assumption is - on a BYOD device the end user would already be an admin hence EPM is not needed in that scenario

- If we log into a machine as an Admin then EPM is not involved.

- EPM supports co-managed devices without having to move a specific workload to Intune.

Below are 2 good to have features related to EPM which might be available in future:

[Good to have feature under consideration]: The option in EPM to create a Deny rule for an application. This ensures that whenever an end user attempts to elevate a specific blacklisted application to admin status, the request is denied. It is important to note that this deny feature of EPM only restricts the launch of the application in admin context; the application can still be launched as a standard user. If the use case involves blocking the launch of the application altogether, other technologies such as WDAC or AppLocker should be used.

[Good to have feature under consideration]: Additionally, we have the option to determine if the end user can elevate and change system settings like IP address/time setting/Language etc on the device using EPM

When to Use EPM—and When Not To

Now that we’ve covered the purpose and functionality of EPM, it’s important to understand the appropriate scenarios for its use which has been explained in this section below:

Primary Application Deployment Strategy

The preferred method for deploying applications should always be through Microsoft Intune using the “Required” intent, ensuring that essential applications are automatically installed on user devices. If there is uncertainty about whether a user needs a particular application, it should be deployed using the “Available” intent, allowing users to install it on demand via the Company Portal.

When to Use EPM

EPM should be leveraged in specific cases where:

A user needs to install an application that has not been pre-provisioned and is not commonly used across the organization.

A user requires temporary elevation to run tools in an administrative context for legitimate troubleshooting or diagnostic purposes (e.g., using tools like ProcMon, Command Prompt, or PowerShell with elevated privileges).

What EPM Is Not For

EPM is not intended to restrict or block the execution of applications. If the goal is to prevent certain applications from launching-organizations should instead use App Control for Business, which is designed to enforce application allow/block policies at the system level.

Our 2 Cents and Conclusion

Making end users administrators on their machines is never advisable. Therefore, we must first ensure that all end users in our workforce are standard users.Does this mean we need to assign EPM licenses to all end users so they can elevate themselves to admin status for an application session? The answer is NO. Our primary method for installing applications on devices should be to push them as required via Intune. If we are unsure whether an end user truly needs an application, we have the option to push those apps as 'Available.' This makes the applications accessible in the Company Portal, allowing end users to download and install them as needed without requiring elevation to admin status.EPM is designed for scenarios where end users may need to perform extensive testing and install applications that are not commonly deployed by the admin through the Intune portal. Instead of relying on the admin to deploy the application, the user can request elevation for an application session via EPM. Once approved, the user can install the application. To facilitate this, it is necessary to procure and assign an EPM license for such users. Another use case involves situations where specific users need to run a particular application in an admin context for a specific purpose (e.g., a user wants to launch Procmon as an admin to gather data). In such cases, assigning an EPM license to the user and using EPM to facilitate the elevation is a sensible approach.It’s also very important to remember that EPM is an elevation control technology (i.e. it decides which app will be elevated for the end user in admin context), not an app control technology (i.e. it doesn’t decide which application will be restricted from being installed/launched in the machine as standard user)In summary, EPM should not be treated as a solution for all users to install applications. The primary method for delivering applications should still be through Intune, either as available or required. Only users who need to install specific applications that are not deployed by the admin, or users who genuinely need to elevate an application to admin status while running it, require an EPM license.

Summary

In this chapter, we explored the importance of EPM and its alignment with Microsoft’s Zero Trust principles. We examined the underlying processes involved in EPM agent installation and policy deployment. Additionally, we conducted a detailed review of relevant logs and registry entries to establish a structured approach to troubleshooting EPM-related issues. We also introduced the available EPM tools at the device level that support diagnostics and validation. The chapter concluded with a discussion on EPM deployment strategies and an overview of supplementary reference resources to support further learning.In the next chapter, we will delve into Enterprise App Management (EAM), a key component of the Intune Suite. This chapter will highlight how EAM enhances the efficiency of deploying and updating third-party applications across the organization.

Resources

Apart from official Microsoft docs I highly recommend exploring the blogs by Rudy Oms (at https://call4cloud.nl). He is an exceptionally talented blogger who has authored insightful and technically rich articles on EPM, infused with a touch of humor.! His blogs are invaluable resources and should be bookmarked by anyone planning to understand EPM greater detail.

3Enterprise App Management: Streamlining Application Deployment

Join our book community on Discord

https://packt.link/UWVMzIn this chapter, we will explore the importance of Enterprise Application Management (EAM) and how it can be effectively configured and deployed using Microsoft Intune. The chapter will delve into the underlying processes and logging mechanisms involved in EAM app delivery, correlating each step with relevant registry entries to strengthen troubleshooting skills.Additionally, we will cover how to integrate EAM with Microsoft Graph to enable automation and discuss potential features that Microsoft may consider introducing in future iterations of EAM. Finally, the chapter will conclude with a brief competitive analysis comparing EAM to similar third-party solutions in the market, along with an objective evaluation of its overall capabilities. By the end of this chapter readers will be equipped with the knowledge and skills required to deploy new EAM solutions, diagnose issues effectively with existing deployments, and gain a deeper understanding of the underlying processes.The following main topics will be covered:

Why EAM

Deploying and updating an EAM application

End User experience

100-feet overview: Background Flow and Logs

Registry

EAM App Inventory

Integrating with Graph

Troubleshooting

Additional EAM Features to Consider

Compete Analysis

Our 2 Cents

Let’s get started!

Why ‘EAM’?

A decade ago, IT administrators frequently cited two of the most time-consuming tasks:

Creating and patching a golden image for device provisioning.

Packaging and deploying the latest versions of applications.

Microsoft has addressed these challenges by leveraging the power of the cloud!The traditional process of creating a golden image has been replaced by Autopilot, eliminating the need to maintain a standard golden image. Devices can now be provisioned over the internet, becoming business-ready with all necessary apps and updates.The task of packaging third-party applications has been simplified with the introduction of Enterprise App Management (EAM), which we will explore further in this chapter.

Need for EAM

IT administrators worldwide spend considerable time replicating the efforts of their industry counterparts by packaging and deploying the same third-party applications. This task is continuous, as IT admins must constantly monitor for updates released by software vendors, which is highly time-consuming. EAM is Microsoft's latest initiative designed to alleviate the application management burden for IT teams.According to Microsoft Digital Defense Report in 2023, 78 percent of devices remain unpatched nine months after a critical vulnerability fix is released. Delays in applying patches and updating applications pose a significant vulnerability, exposing organizations to potential cyberattacks.Below are some of the key challenges IT administrators commonly encounter when ensuring that all third-party applications on end-user Windows devices across the organization remain up to date.

Managing applications from various developers and ensuring each one is up to date is a complex and time-consuming process.

IT administrators can spend countless hours packaging applications for deployment to ensure end users have reliable access to the necessary tools.

Hence organizations require a streamlined and efficient method for managing third-party applications, encompassing easy access, discovery, and deployment systems. Addressing these challenges necessitates a comprehensive solution.

Background and basics of EAM

EAM is fundamentally an IT function, crafted to function unobtrusively in the background without the end user's knowledge. It aids IT administrators in simplifying app management and gaining control over the entire app management process. Furthermore, it helps keep systems up-to-date by allowing the effortless creation of apps for newer versions, thereby offering IT enhanced control over the app lifecycle and app security.The Enterprise App Catalog features Win32 applications that are prepared and hosted by Microsoft. Microsoft handles the packaging of installation files (EXE or MSI) and creates all necessary components to integrate the app as a Win32 application into Microsoft Intune. When an app from the Enterprise App Catalog is added to Microsoft Intune, it includes a comprehensive set of pre-filled installation details, such as install and uninstall commands, installation behavior, return codes, detection rules, and requirements. This greatly simplifies the process of adding apps to Microsoft Intune, minimizing the need for extensive testing and configuration by IT.

Advantages of EAM

EAM enables IT and security operations teams to optimize the lifecycle management of both first-party and third-party applications through a secure, prepackaged app catalog. This solution reduces the time and effort IT administrators spend on app packaging and update monitoring. It allows IT teams to efficiently deploy patches to vulnerable applications and ensure all apps remain current via the Intune admin center.EAM empowers us to seamlessly Discover, Package and Update an application from the Intune console with just few clicks.EAM ensures that we are regularly updating the 3rd party apps thereby reducing the risks with any vulnerability.

Comparison with Winget

Enterprise app management uses Win32 app methodology at the background to deploy apps to the devices.Both WinGet and Win32 app deployment are methods used for deploying applications via Microsoft Intune, but they have some key differences.

WinGet Deployment via Intune

Package Manager: WinGet is a command-line package manager for Windows, similar to package managers on Linux or macOS.

Sources: It can install applications from multiple sources, including the Microsoft Store, GitHub, and other repositories.

Ease of Use: WinGet simplifies the process of installing, upgrading, and managing applications programmatically.

Deployment Methods: We can deploy WinGet scripts using Intune as PowerShell scripts or as part of proactive remediation.

Flexibility: It supports various package formats like EXE, MSIX, APPX, and MS

(EAM)Win32 App Deployment via Intune

Traditional Method: This method involves packaging Win32 applications (EXE, MSI) and deploying them through Intune.

Packaging: You need to create an .intunewin file using the Microsoft Win32 Content Prep Tool.

Deployment: The packaged application is uploaded to Intune and deployed to devices. Intune handles the installation, updates, and uninstallation.

Control: Provides more granular control over installation parameters, detection rules, and dependencies

Now let’s do a comparison between Winget and win32(EAM) app deployment methodology.

Key Differences

Complexity: WinGet is generally easier to use for simple deployments, while Win32 app deployment offers more control and customization.

Sources: WinGet can pull from multiple repositories, whereas Win32 app deployment typically involves custom-packaged applications.

Integration: Win32 app deployment is more tightly integrated with Intune's management and reporting features

The primary focus of this section is to emphasize that EAM employs the Win32 app deployment methodology. Additionally, it highlights that app deployment using WinGet is supported via Intune, although it is not utilized within EAM.

Deploying and updating an EAM app

In this section, we will walk through the process of initiating a new EAM deployment via the Intune portal. Additionally, we will cover how to update an existing application that was previously deployed through EAM and now has a pending update released by the vendor.

New Deployment of EAM App

Deploying an EAM application from the Intune portal is a straightforward process. Simply select the application name and language we wish to deploy from the catalog. The application binaries, along with the install/uninstall commands and detection logic, will be added to our tenant. We always have the option to edit any of these values.

Please note that the option to deploy an app from the EAM catalog is available only if the relevant license is present in our tenant and assigned to the end users.

Whenever we select any EAM application from the catalog, the wrapped version along with the binaries of the application is provided to us by Microsoft.

The end devices get the application from Microsoft's storage (where the EAM app is wrapped and kept) and not from a 3rd party location

Below are the steps that we need to perform in the Intune portal for making a new EAM app deployment

The first step involves selecting Enterprise App catalog app from the drop down as seen below.

Figure 3.1: Adding EAM application from the Intune portal

Now we need to select the application we wish to deploy as seen below:

Figure 3.2: Selecting the EAM application from the catalog

After selecting the application, its details are automatically pre-populated in the App information screen. Here we can see the Name, Description and Publisher information pre-filled. As of writing this, the Logo of the EAM app does not get added automatically however they can be added manually here.

Figure 3.3: Application Information screen which is pre-populated while adding the EAM app

In the next screen under Program we can see that the Install and Uninstall commands are automatically added along with the relevant return codes. These can be changed if needed, however it’s not recommended as Microsoft has added these parameters after testing them internally.

Figure 3.4: ‘Program’ section of the EAM app which is pre-populated with the install/uninstall commands and exit codes

The next page is Requirements which is auto populated with the minimum version of Operating System which supports this app. We have the option of changing the same as well as adding a custom requirement (based on File location of Registry) which is optional.

Figure 3.5: ‘Requirements’ tab which is pre-populated with minimum OS version

The next page Detection Rules is also pre-populated for this application. This determines how the service will detect where the app was successfully installed in the device or not.

Figure 3.6: ‘Detection Rules’ tab which is pre-populated with File/Registry detection logic

Below are few important pointers to keep in mind while making an EAM app deployment:

The install and uninstall commands, along with return codes, are provided by the application vendor and tested by Microsoft. We have the option to modify these commands in the portal to alter the installation experience however the general recommendation is not changing any of these values unless we have a requirement.

Currently, the application's logo is not automatically added during deployment.

EAM applications always install in the System context, and this setting cannot be changed from the portal. This means the application installs for all users of the device, and users do not need to be logged in for the EAM app to be installed.

The detection logic used for app deployment varies based on the information provided by the vendor. Some EAM apps may use MSI, file, and registry detection logic (i.e., all three), while others may use only one or two of these methods.

Now our EAM application is ready and can be assigned to users or devices as needed. Until now we have understood how to make fresh deployment of EAM application from Intune portal. In the next section we will see how we can successfully update an EAM app for which a newer version has been released by the vendor.

Updating an existing EAM App

When a newer version of any application deployed via EAM becomes available, the admin is notified in the dashboard as shown below. When we click on the same, we will be taken to a list of all EAM apps which have received a new release from the vendor.

Figure 3.7: ‘Overview’ tab in the Intune portal notifying the admin of the EAM apps which have updates available

Alternatively, we can also go to Apps | Monitor | Enterprise App Catalog apps with updates:

Figure 3.8: ‘Monitor’ tab in the Intune portal

As seen below, we can now get a list of all the EAM apps which have received a newer version:

Figure 3.9: Apps under Monitor blade with their current and latest available version

By clicking on the above application or by navigating to the previously deployed EAM app (which has now received an update), there is an option to deploy its updated version by clicking on Update.

Figure 3.10: Option to update an existing EAM application from the portal

Clicking on Update initiates a new deployment of the EAM app and supersedes the old app deployment. Superseding creates a new app with the latest app package and establishes the superdense relationship. Some settings, such as scope tags and assignments, will not be copied to the new app. As seen below the newer version of the app is automatically packaged and added to the portal, while the older version is moved under Supersede.

Figure 3.11: Making deployment of the updated EAM application from the portal

Some applications require the previous version to be uninstalled before the newer version can be installed.

Conversely, there are applications where both versions (V1 and V2) can coexist on the same machine. During the EAM app update deployment, we have the option to choose whether the older version of the EAM app will be uninstalled or not, as shown below.

Figure 3.12: ‘Superdence’ option available while updating an EAM app from the portal

Self-Updating EAM Apps

The Enterprise App Catalog includes apps that self-update, for example Google Chrome as seen below.

Figure 3.13: Self updating apps in the EAM catalog

These applications feature a built-in update mechanism, allowing them to automatically update outside of Microsoft Intune or the IT admin's control. The self-update mechanisms download content directly from the vendor. The app selection wizard will notify us when a self-updating app is selected. Self-updating applications update on client devices according to the vendor's process.

Currently, there is no SLA for the timeframe in which an application will be updated in the catalog after the vendor releases it. However, Microsoft may work towards establishing an SLA for this in the future.

Intune doesn’t provide reports on whether the EAM application is being used or not.

Very soon we will have the ability to block the ESP until an EAM app is deployed during Autopilot provisioning.

At the time of publishing this book, there were approximately 1,000 unique applications in the EAM catalog. Microsoft aims to expand this catalog to around 1,800 unique applications as its north star!

End user experience

When the EAM application is deployed to the device with 'Required' intent from the Intune portal, the installation process is seamless and does not require any user interaction. The user will receive a toast notification, as shown below, indicating the status of the app installation as applicable. In case of any errors with download/installation the same would be reported as a notification

”

Figure 3.14: End user experience while an EAM app gets installed

All the installed EAM apps will be visible in the control panel app list in the device.

1000-feet Overview: Background Flow and Logs

In the following section, we will take a detailed look at the flow involved in EAM app delivery and deployment, supported by relevant log data. By analyzing these logs, we can trace each step of the deployment process. Gaining a clear understanding of this flow is essential, as it not only reinforces key concepts but also enhances our ability to troubleshoot effectively in the event of deployment failures.The IME logs which can help us trace the EAM app deployment are located in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs as seen below:

Figure 3.15: IME logs in the device for troubleshooting EAM issues

It is essential to understand the EAM process through the lens of log analysis, as this provides the most critical insights for effective troubleshooting. Below is an extract from the IME logs of a successful EAM app deployment. The table highlights the primary processes occurring as indicated by the logs. The flow described below remains consistent regardless of the specific EAM application.

Message in the logs
Explanation

Step 1
Intune Management Extension gets initialized
EMS Agent Started

Step 2
Content manager starts

Step 3
Deviceid and OS version is noted

Step 4

IME discovers the Endpoint of Intune (CDNs)

These need to be whitelisted in the firewall (if blocked)as per the network pre-reqs listed earlier

Step 5
Impersonation for the user happens and token is requested/granted

Step 6
PUT request is sent

Step 7
We see a “Get Policies” response, which has the entire policy body. In this case the policy body will contain the binaries of the EAM app from the catalogue which was deployed to the user
We can check and ensure that the policy received by IME is in accordance with the settings configured in the EAM app

Step 8
ExecManager identifies the app name/appid/app installation intent

Step 9
Dependency is checked for the apps discovered above
If dependencies are discovered, then the dependent app is downloaded and installed first

Step 10
Detection rules are checked for the apps.

For Example:

Detection running for policy with id: d7589f12-bc24-45e0-89b9-c7eb57408217.

Path doesn't exists: C:\Program Files\WinRAR\WinRAR.exe applicationDetected: False"

If the app is detected in the device at this stage, the download/installation attempt of the app (in the below step) is skipped

Step 11

Applicability is checked for the app

The minimum requirement for OS version, architecture and RAM/CPU will be checked.

For Example:

(requirement and extended requirement)RequiredOSArchitecture: 2,is64BitOperatingSystem: True,isArm64: False

expected version: 10.0.14393, client version: 10.0.22631, applicability:

ApplicableRequiredMemory is , skip check

RequiredCPUSpeed is , skip check

Step 12
Toast message with: "C:\Program Files (x86)\Microsoft Intune Management Extension\agentexecutor.exe" -toast "ToastDownloadingMessage"
User can see an intuitive prompt in the device notifying that the app is downloading

Step 13
Download job is created/timer is set

For Example:

start creating a new download job, FileId = 225BDA84-AD50-462C-9963-7B74CFBD5C86_6e831210-f8d2-52d8-33e3-0c68342672d8_PE_1742252141, remote URL = https://aam-content-cdn.manage.microsoft.com/cdncontent/6e831210-f8d2-52d8-33e3-0c68342672d8.zip

We can see the remote URL from where the EAM app is getting downloaded.

For Example:

Downloading app (id = d7589f12-bc24-45e0-89b9-c7eb57408217, name WinRAR (English) (x64)) via DO, bytes 0/0 for user 3b91c924-794c-4991-ac6a-2f9d5d684d2f

We can see that the download is trying to use Delivery Optimization

Step 14
Content downloaded to C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming (Staging)

Step 15
Download job completes, time taken is noted, bytes download is noted job closed

Step 16
Verifying encrypted hash, Decryption starts

Step 17
Unzipping starts from “Content\Staging” to C:\Windows\IMECache\

Step 18
Cleaning up staging content

Step 19
Parsing InstallEx
Installer execution starts

Step 20
Prepare msi cmdline for system context

Step 21
winrar-x64-710.exe" /s
Command specified in the EAM app in the portal

Launch Win32AppInstaller in machine session

Step 22
Installation completes,collecting result

Step 23
lpExitCode 0, determines if its a success

Step 24
DeviceRestartBehavior: 2, (checks , device restart behavior), handle is closed
Device restart action as per the policy defined by the admin in the portal

Step 25

Now detection Rule starts by SideCarFileDetectionManager

The Detection rule evaluated above in ‘Step 11’ is evaluated again, post app installation

Step 26

For Example:

Checked filePath: C:\Program Files\WinRAR\WinRAR.exe, Got sizeInBytes:3,311,760.00, compareValue 3,311,760.00

First the file path is checked (if applicable)

For Example:

Checked filePath: C:\Program Files\WinRAR\WinRAR.exe, Got versionStr:7.10.0.0, compareValue 7.10.0.0

Secondly the file version is checked (if applicable)

For Example:

Got reg value path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\WinRAR archiver, name: DisplayVersion, value: 7.10.0 AppWorkload 24-03-2025 11:20:38 7 (0x0007)

actualValue: 7.10.0, DetectionValue: 7.10.0, applicationDetected: True

Lastly the registry values are checked (if applicable)

Step 27
Toast message with: "C:\Program Files (x86)\Microsoft Intune Management Extension\agentexecutor.exe" -toast "ToastSuccessMessage
User is able to see an intuitive prompt in the device notifying that the app is installed successfully/failed (As applicable)

Step 28
Cleaning up staged content C:\Windows\IMECache\59f9a567-b92d-4dc2-9c7a-fdb94e29275c_1

Step 29
Sending reports for user and the app
The result of app's successful installation is sent to the Intune service.

Table 3.1: List of all the important logs while processing of the EAM application at the device endThe 29 steps outlined above give us a clear understanding of the processing we should expect to observe in the IME logs during an EAM app deployment. While troubleshooting, it is important to review the logs mentioned above to identify where the process is breaking and pinpoint the source of any errors.

Registry

Understanding the relevant registry locations associated with EAM is critical for effective troubleshooting. In this section, we will examine the key registry paths and their expected values, which serve as essential reference points when diagnosing issues during EAM deployments.The primary registry location relevant to EAM app deployment is: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\{SID}\{App Id GUID}. Under the Win32Apps key, we will find:

{SID}: A subkey for each user, where the key name matches the user object ID in Azure AD.

{App Id GUID}: The application ID of the EAM application deployed via Intune.

Example Use Case

In the example, the user logged into the device is pm@everythingaboutintune.com, and the user's object ID is 3b91c924-794c-4991-ac6a-2f9d5d684d2f as seen below.

Figure 3.16: User’s objected in the Entra portal

For this user, six EAM applications have been deployed via Intune by following the steps outlined earlier in the chapter under the section New Deployment of EAM App. These applications are listed below as they appear in the Intune portal under the Apps section.

Figure 3.17: EAM applications deployed to the above user from Intune

The application IDs for each application can be found in the Intune portal which have been collated below for this example use case:

EAM Application Name | ApplicationId
Android Studio 4 | 560a3d57-a114-4ea5-b826-2a4523f6c1ed
AnyDesk | 79934a77-c3ca-46b9-8034-59180699a809
Audacity (x64) | 599cd13f-75d4-4771-816d-190f843fb5db
Citrix Receiver | 3c4e1d36-23b2-4390-afee-43769a21f57e
GitHub CLI (x64) | 30141bf0-263d-4e93-9081-565cfe20383d
WinRAR (English) (x64) | d7589f12-bc24-45e0-89b9-c7eb57408217

Table 3.2: List of all the applications deployed to the sample user and its respective appidThe above applicationIds will corresponds with the Appids visible in the registry of the machine as seen below:

Figure 3.18: Registry from the device

_1 at the end of each appid in the registry seen above means this is the 1st version of the application.If we take a close look, we will find that under each application ID, there are two subkeys: ComplianceStateMessage and EnforcementStateMessage. Both the sub-keys contain a REG_SZ key with the same name.

Figure 3.19: Registry from the device

Compliance State Messages node contains information on various attributes of the EAM app targeting and its applicability on the device. The information is stored in JSON format in the ComplianceStateMessage subkey.Enforcement State Messages node provides information on the status of the EAM application, indicating whether it was successfully installed on the device. The results are stored in JSON format within the EnforcementStateMessage subkey.In our example, the relevant values (pasted from REG_SZ into Notepad) are as follows for one of the EAM applications:

REG_SZ Value Name: ComplianceStateMessage
ValueData:  {"Applicability":0,"ComplianceState":1,"DesiredState":2,"ErrorCode":null,"TargetingMethod":0,"InstallContext":2,"TargetType":2,"ProductVersion":null,"AssignmentFilterIds":null}
REG_SZ Value Name: EnforcementStateMessage
Value Data:  {"EnforcementState":1000,"ErrorCode":0,"TargetingMethod":0}

These fields contain information on the applicability of the EAM application, whether it has been targeted to a user or device group, the installation context (System or User), and the success of the installation. Each field has a numerical value that needs to be decoded:

Applicability: A value of 0 means "Applicable".

ComplianceState: A value of 1 means "Installed".

DesiredState: A value of 2 means "Present".

InstallContext: A value of 2 means "System" (the only possibility for EAM applications).

TargetType: A value of 1 means "User" (indicating the EAM policy from Intune has been targeted to a user group).

EnforcementState: A value of 1000 means "Success".

In a successful EAM app deployment, the registry values will resemble those mentioned above.By using any .NET decompiler we can view the source code of the Intune Management Extension which will give us a list of all the state messages and their values which are as follows:

Values for Applicability:

Value | Translation
0 | Applicable"
1 | "RequirementsNotMet"
3 | "HostPlatformNotApplicable"
1000 | "ProcessorArchitectureNotApplicable"
1001 | "MinimumDiskSpaceNotMet"
1002 | "MinimumOSVersionNotMet"
1003 | "MinimumPhysicalMemoryNotMet"
1004 | "MinimumLogicalProcessorCountNotMet"
1005 | "MinimumCPUSpeedNotMet"
1006 | "FileSystemRequirementRuleNotMet"
1007 | "RegistryRequirementRuleNotMet"
1008 | "ScriptRequirementRuleNotMet"
1009 | "NotTargetedAndSupersedingAppsNotApplicable"
1010 | "AssignmentFiltersCriteriaNotMet"
1011 | "AppUnsupportedDueToUnknownReason"
1012 | "UserContextAppNotSupportedDuringDeviceOnlyCheckin"
1011 | "AppUnsupportedDueToUnknownReason"
1012 | "UserContextAppNotSupportedDuringDeviceOnlyCheckin"

Values for ComplianceState:

Value | Translation
1 | "Installed"
2 | "NotInstalled"
4 | "Error"
5 | "Unknown"
100 | "Cleanup

Values for DesiredState:

Value | Translation
0 | "None"
1 | Not Present
2 | Present
3 | Unknown
4 | Available

Values for InstallContext:

Value | Translation
1 | "User"
2 | "System"

Values for TargetType:

Value | Translation
0 | "None"
1 | "User"
2 | "Device"
3 | "Both Device and User"

Values for EnforcementState:

Value | Translation
1000 | "Success"
1003 | "SuccessFastNotify"
1004 | "SuccessButDependencyFailedToInstall"
1005 | "SuccessButDependencyWithRequirementsNotMet"
1006 | "SuccessButDependencyPendingReboot"
1007 | "SuccessButDependencyWithAutoInstallOff"
1008 | "SuccessButIOSAppStoreUpdateFailedToInstall"
1009 | "SuccessVPPAppHasUpdateAvailable"
1010 | "SuccessButUserRejectedUpdate"
1011 | "SuccessUninstallPendingReboot"
1012 | "SuccessSupersededAppUninstallFailed"
1013 | "SuccessSupersededAppUninstallPendingReboot"
1014 | "SuccessSupersedingAppsDetected"
1015 | "SuccessSupersededAppsDetected"
1016 | "SuccessAppRemovedBySupersedence"
1017 | "SuccessButDependencyBlockedByManagedInstallerPolicy"
1018 | "SuccessUninstallingSupersededApps"
2000 | "InProgress"
2007 | "InProgressDependencyInstalling"
2008 | "InProgressPendingReboot"
2009 | "InProgressDownloadCompleted"
2010 | "InProgressPendingUninstallOfSupersededApps"
2011 | "InProgressUninstallPendingReboot"
2012 | "InProgressPendingManagedInstaller"
3000 | "RequirementsNotMet"
4000 | "Unknown"
5000 | "Error"
5003 | "ErrorDownloadingContent"
5006 | "ErrorConflictsPreventInstallation"
5015 | "ErrorManagedInstallerAppLockerPolicyNotApplied"
5999 | "ErrorWithImmeadiateRetry"
6000 | "NotAttempted"
6001 | "NotAttemptedDependencyWithFailure"
6002 | "NotAttemptedPendingReboot"
6003 | "NotAttemptedDependencyWithRequirementsNotMet"
6004 | "NotAttemptedAutoInstallOff"
6005 | "NotAttemptedDependencyWithAutoInstallOff"
6006 | "NotAttemptedWithManagedAppNoLongerPresent"
6007 | "NotAttemptedBecauseUserRejectedInstall"
6008 | "NotAttemptedBecauseUserIsNotLoggedIntoAppStore"
6009 | "NotAttemptedSupersededAppUninstallFailed"
6010 | "NotAttemptedSupersededAppUninstallPendingReboot"
6011 | "NotAttemptedUntargetedSupersedingAppsDetected"
6012 | "NotAttemptedDependencyBlockedByManagedInstallerPolicy"
6013 | "NotAttemptedUnsupportedOrIndeterminateSupe

(Reference for above values: Blog from Ben Whitmore in msendpointmgr.com)In this section, we explored the key registry locations relevant to EAM, along with their expected values and corresponding numerical translations. This understanding serves as a valuable reference for effective troubleshooting.

EAM app inventory

Now we are going to understand how the Intune service runs an inventory for the EAM applications in the Windows device.Windows app inventory is available in Microsoft Intune and the information is shown in the Discovered apps blade for each device in the portal as seen below.

Figure 3.20: Discovered EAM applications for a device from the Intune portal

The process of collecting inventory of all applications (including EAM apps) in an enrolled Windows device is done by the Intune Management Extension (IME).One of the integral components of the IME is the Win32AppInventoryCollector. This component's functionality is encapsulated in Microsoft.Management.Clients.IntuneManagementExtension.Win32AppInventoryCollector.dllIME leverages the Win32_InstalledWin32Program class in WMI to gather the inventory of Win32 applications. The WMI class references the registry location-HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall which contains information of all the apps (including EAM apps) as seen below:

Figure 3.21: Registry from the device highlighting EAM app traces

Another relevant registry for EAM app discovery by the Intune service is HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Inventories. This location will also contain a list of all the EAM apps and its respective versions present in the device.

Figure 3.22: Registry from the device highlighting EAM app traces for inventory

The HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\InventorySetting registry location includes the LastFullSyncTimeUtc value, which records the timestamp of the last full inventory run on the device, as shown below.

Figure 3.23: Registry from the device highlighting timestamp for inventory run cycle

The full inventory process initiates upon IME installation and subsequently runs every 7 days. In the interim, the delta inventory runs every 24 hours or whenever the IME starts.

In this section, we examined how the Intune service identifies and discovers EAM applications installed on a device, and how this information is utilized for inventory purposes.It is possible to automate the EAM application deployment and update process using Microsoft Graph APIs. In the next section, we will explore how to implement such automation effectively.

Integrating with Graph APIs

To automate the deployment and update of EAM apps, we can utilize the exposed Graph APIs. Managing our EAM deployment through Graph APIs makes the flow more seamless! And reduces admin intervention.Below, we will explore few use cases explaining what can be achieved using Graph APIs. The goal is to understand the fundamentals and then build upon them using PowerShell scripts and automation.

Use case 1:

In this use case, we will be installing Required PowerShell Modules, establishing a Connection, and Retrieving EAM Catalog Applications.To implement the use case described above, we must first configure the PowerShell execution policy to Unrestricted, install the required Microsoft Graph modules, and authenticate using Entra ID credentials. Once authenticated, we can proceed to invoke the EAM endpoint. Below, we’ll find the step-by-step process along with the necessary commands to accomplish this.

Firstly, we will run the below commands in PowerShell as administrator which will set the Execution policy and install the Graph modules:

Set-ExecutionPolicy Unrestricted -force
Install-Module Microsoft.Graph
Install-Module Microsoft.Graph.Beta -Force -Verbose
Import-Module Microsoft.Graph.Beta.Devices.CorporateManagement -Verbose

As seen below, once we run the above commands the package and the modules get installed:

Figure 3.24: PowerShell modules being installed

Now we need to run the below commands to connect Graph with our EntraId tenant:

Connect-Graph
Connect-MgGraph
Connect-MgGraph -Scopes “DeviceManagementApps.Read.All”

After running the above commands, we get a pop-up dialog box which require us to enter our admin credentials and accept the relevant permissions as seen below:

Figure 3.25: Prompt for accepting the permissions

Now we are successfully authenticated to our tenant. The next step to achieve the usecase is running the below commands which will help us get a list of all the EAM apps in the catalog and display it in the poweshell output in form of json:

Invoke-MgGraphRequest -Method GET https://graph.microsoft.com/beta/deviceAppManagement/mobileAppCatalogPackages?
$result = Invoke-MgGraphRequest -Method GET -Uri "/beta/deviceAppManagement/mobileAppCatalogPackages?"
$result.value | convertto-json

Executing the above command will return a list of all EAM applications available in the catalog. The results will be displayed in JSON format within the PowerShell console as seen below:

Figure 3.26: PowerShell output: List of EAM apps in json

The above output is not very readable as it contains more than 1000 lines with details of various apps. In the next use case, we will make the output more readable.

Use case 2:

In this section, we will be building on the above output and exporting the list of all the EAM apps in the catalog to an excel file for better visibility/understanding

To achieve the above use case, we will now run the below command to get us a list of all EAM apps in the catalog and export it to a json file.

Invoke-MgGraphRequest -Method GET -Uri "/beta/deviceAppManagement/mobileAppCatalogPackages?$select=productId,productDisplayName,packageAutoUpdateCapable" -OutputFilePath C:\temp\new\filett.json

Now we will be Importing the json file into Excel and filtering to get a list of all the application names, ids and publisher. For this, lets open an Excel as seen below, and do a Get Data from json:

Figure 3.27: Importing the json file into Excel

After loading the JSON data, we can refine the imported content by selecting Choose Columns in Excel. This allows you to include only the relevant fields or exclude any unnecessary columns before finalizing the import. In the example below, I’ve deselected the first three columns and retained the remaining ones for analysis.

Figure 3.28: Filtering the Columns before loading the excel with json data

Once the desired columns have been selected, click OK to proceed. This action will import the JSON data into Excel, presenting a structured view of all applications available in the EAM catalog, as illustrated below.

Figure 3.29: Final Excel sheet containing all the available EAM apps in the catalog

With the data now available in Excel, we can leverage its full analytical capabilities. For example, we can create pivot tables to filter and summarize the information as needed. Additionally, this process can be automated by scheduling regular calls to the relevant Graph API endpoints, enabling consistent and up-to-date exports.

Use case 3: Getting a list of all the EAM apps added to our tenant

As the next use case, if we wish to get a list of the EAM apps which have been added to our tenant, we need to call the below Graph endpoint. Additionally, we can use ‘Select-Object’ parameter and just filter out the useful details like DisplayName, Id and Creation date.

Get-MgBetaDeviceAppManagementMobileApp -Filter "(isof('microsoft.graph.win32CatalogApp'))" | Select-Object -Property DisplayName, Id, CreatedDateTime

The output would look like the below, listing all the EAM apps that have been added to the tenant by the admin:

Figure 3.30: PowerShell output showing the list of EAM apps added to the tenant

Lastly, it is also possible to add a new EAM from the catalog to our tenant using Graph. To do this, we need to make a POST request to the same Graph API endpoint. This request must include a policy body containing key details such as the applicationId, displayName, description, and other relevant metadata required for the app configuration.Using the above 3 use cases, the primary goal of this section was to understand that similar to most tasks in the Intune portal, EAM-related tasks can also be managed by administrators through the appropriate Graph APIs. If we have a team that deals with automation, they can do a lot of cool stuff with this!

High Level Summary of the Flow

Below is a block diagram representation of the flow established from the IME logs as seen in the section above.

Figure 3.31: High level block diagram explaining the flow behind EAM app installation

Our troubleshooting approach must align with the established flow. If there are errors during app installation, the IME log will capture them.During troubleshooting, we need to ensure that each step of the flow is checked. Various factors can cause EAM app installation failures, such as inaccessible URLs, incorrect detection logic, or unmet device requirements. By tracing the logs, we can pinpoint the cause and work towards a resolution.

Additional EAM Features to Consider

Microsoft might consider the development of the following capabilities to enhance EAM app deployment based on the feedback received, making the feature even more robust. Currently, there is no ETA for these enhancements:

Integration with MDE: For instance, MDE could detect a vulnerability in a third-party application, and that vulnerability could be addressed through deployment from Intune via the EAM catalog.

Updating Unmanaged Applications: Extending the ability to push updates to applications that are not currently managed. Scenario could be updating apps that may not have been deployed via the catalog, but an update or security vulnerability has been detected

Support for macOS and Linux: Expanding EAM capabilities to include macOS and Linux operating systems.

Compete Analysis

PatchMyPC is a notable competitor in the EAM space, having provided third-party app management for many years with a comprehensive product. In comparison to Intune, they have two key unique selling points (USPs):

SLA for App Updates: PatchMyPC guarantees the availability of app updates within 24 hours of the vendor's release. In contrast, Microsoft has not provided an SLA for app updates, which currently may take a couple of months to appear in the catalog. However, this is expected to improve in the future.

Pricing: The retail pricing for EAM in Intune is $2 per user per month ($24 annually) with no minimum starting price, allowing for the purchase of a single license for one month. PatchMyPC charges $3.5 per device per year, with a minimum starting price of $2,499.

The pricing for EAM becomes more economical when purchasing the entire Intune suite at $10 per user per month. Additionally, PatchMyPC's licensing is device-based, meaning costs can add up if a user has multiple devices. In contrast, the EAM license in Intune is user-based, allowing a user to have up to 15 devices under a single license.

We are generally not in favor of deploying third-party agents onto devices unless absolutely necessary. Utilizing a compete solution typically requires deploying an additional agent onto the device. In contrast, using EAM leverages the IME agent, which is installed by default when a device is EntraId joined and enrolled to Intune.

Our 2 Cents

We believe the EAM capability in the Intune suite is a valuable addition to its features. While pricing may be a consideration, the advantage of having a single pane of glass (i.e., Intune) for all management tasks is highly beneficial from an administrative perspective. Additionally, Microsoft might consider expanding EAM to macOS, which would be a significant enhancement.

Summary

In this chapter, we explored the background, purpose, and key benefits of using EAM. We examined the end-to-end process of EAM app delivery, including the underlying logs and registry interactions that support effective troubleshooting. We also covered how to automate EAM deployments using Microsoft Graph. The chapter concluded with a discussion on potential future enhancements and a competitive analysis comparing EAM with similar third-party solutions.

Further reading

https://www.microsoft.com/en-us/security/blog/2024/05/30/exposed-and-vulnerable-recent-attacks-highlight-critical-need-to-protect-internet-exposed-ot-devices/

https://www.microsoft.com/en-in/security/security-insider/microsoft-digital-defense-report-2023