My first look at Intune Agents

Unless you've been sleeping for the past year you'll have heard about Microsoft's Copilot offering. There are different flavours: M365 Copilot, Security Copilot, GitHub Copilot etc. I'm an Intune guy, so I'm mostly interested in Security Copilot. In this blog post I'll discuss how to get started and my first look at the Intune Agents, which are in Public Preview and use Security Copilot under the hood.

First the prerequisites for Security Copilot, there are a few.

• You need an Azure subscription in order to provision Security Compute Units (SCUs); more about that below.
• You need an account which has been assigned the correct role to configure Copilot capacity (SCUs); also more about that below.

Security Compute Units

Security Compute Units (SCUs) are the compute capacity required to run Security Copilot workloads. 

At Ignite 2025 Microsoft announced that Security Copilot will be available to all Microsoft 365 E5 customers. The rollout starts November 18, 2025, for existing Security Copilot customers, and will continue in the upcoming months for all Microsoft 365 E5 customers. What does that mean? Customers with Microsoft 365 E5 will have 400 Security Compute Units (SCU) each month for every 1,000 paid user license, up to 10,000 SCUs each month. So, an organization with 4,000 user licenses gets 1,600 SCUs/month. This is great news and has made Security Copilot more affordable for organizations. It's important to note that the cost for M365 E5 licenses has increased at this time, but Microsoft have also added the Intune Suite features to the E5 subscription.

How will you know how many SCUs are being consumed? Security Copilot provides a usage monitoring dashboard for Copilot owners, allowing them to track usage over time. We'll have a look at that later. 

Microsoft Entra and Microsoft Purview roles

The following Microsoft Entra and Microsoft Purview roles automatically inherit Copilot owner access:

Microsoft Entra roles:

• Billing Administrator
• Entra Compliance Administrator
• Global Administrator
• Intune Administrator
• Security Administrator

Microsoft Purview roles:

• Purview Compliance Administrator
• Purview Data Governance Administrator
• Purview Organization Management

Once Security Copilot is rolled out to your organization and available via your M365 E5 licensing, then SCUs will automatically be available. If you don't qualify through your licensing, then you will have to provision SCUs yourself. The Microsoft documentation shows you how to get started with that.

This is done by navigating to https://securitycopilot.microsoft.com where you are guided through the steps.

Tip: SCUs are provisioned on an hourly basis. To maximize usage, make SCU provisioning changes at the beginning of the hour.

Intune Agents

Once SCUs have been provisioned, then Security Copilot is available for your organization. This lights up Agents in the Intune portal.

For now, three Agents are available in the Public Preview.

• Change Review Agent: uses Microsoft Security Copilot's generative AI to evaluate Multi Admin Approval requests for PowerShell scripts on Windows devices. It provides risk-based recommendations and contextual insights to help administrators understand script behaviour and associated risks. I'll be concentrating on this agent for this blog post.
• Device Offloading Agent: identifies stale or misaligned devices across Intune and Entra ID, providing actionable insights and offboards devices subject to admin approval.
• Policy Configuration Agent:  helps IT admins to translate complex requirements and industry standard documents into actionable Intune settings, and allows administrators to quickly generate Intune settings catalog policies. 

Ok, let's look more closely at the Change Review Agent.

Click on View details.

You are prompted to Set up agent.

After the agent is set up, click Run to start a job. This should examine my PowerShell scripts (that are subject to Multi-Admin approval) and to identify and risks associated with the script.

My first run didn’t identify any suggestions, which surprised me. I had previously uploaded a script which was subject to multi-admin approval. The script had been approved by a second administrator. This script is very destructive as it resets any Windows device back to factory settings. I ran the agent and expected to see some suggestions about the script but received nothing. 

Then I figured out that the agent was only targeted to "pending" requests, not requests that have actually been "approved". I uploaded the script again without approving and ran the agent again. 

This time I received a suggestion called Reject Device reset. I clicked on the suggestion and was very impressed with the output. The agent figured out exactly what this script would do and told me that I should reject the approval. Then I knew that I had to be very careful with this script that someone else created.

 

Suggested action: Reject

The script is designed to perform a remote wipe operation on devices using WMI, which is a highly destructive action. While there are no explicit signs of malicious code or prior security rejections, the script's purpose and actions involve significant risk due to the potential for data loss and system disruption. The business justification is minimal, and the script's risk level is high based on its destructive capability. All validation points except Script Reputation have sufficient data, but the lack of reputation data does not mitigate the high inherent risk of the script's function.

The script interacts with the Windows Management Instrumentation (WMI) to invoke a remote wipe method on a device. It connects to the `root\cimv2\mdm\dmmap` namespace and targets the `MDM_RemoteWipe` class. The method `doWipeMethod` is executed with specific parameters, potentially to perform a remote wipe operation. The script includes error handling to capture and display any exceptions that occur during the process.

Factors:

• Script Purpose: The script's primary function is to execute a remote wipe, which is a destructive operation. Although the actions are well-documented, the risk of unintended or malicious use is high. The metrics require no risky constructs and a well-defined scope, but the destructive nature of the script outweighs these controls for a Create operation.
• Approval/Rejection History: There is no history of prior rejections or security risk decisions for this script, so this point is satisfied.
• Alert History (Script): No high-severity alerts or active incidents are associated with the script, meeting the criteria for this point.
• Business Justification: The justification is minimal and lacks detail on scope, controls, and privacy. For a high-risk operation like remote wipe, a more comprehensive justification is required.
• Requestor Risk Indicators: The requestor is not marked as deleted or risky, and there are no unresolved risk indicators, so this point is satisfied.

Very accurate, really clever stuff.

Finally browse to Security Copilot Usage Monitoring to see how many SCUs are being used.

I hope you found this useful. Until next time.......

Autopilot - this user is not authorized to enroll (80180003)

I was setting up a new demo tenant for testing this week and I encountered something I hadn't seen before. I had configured an Autopilot solution using deployment profiles but experienced this problem during testing.

I could see that my test device had been assigned a profile.

This was validated when I saw the Company Branding on the test device.

However I received the error:

"Something went wrong. This user is not authorized to enroll. You can try to do this again or contact your system administrator with the error code 80180003".

I'd seen this issue before. There are several reasons you can get this error. Microsoft have a pretty decent article describing it.

https://learn.microsoft.com/en-us/troubleshoot/mem/intune/device-enrollment/windows-user-cannot-enroll

This is an extract from that document:

These errors can result from any of the following conditions:

• The user has already enrolled the maximum number of devices allowed in Intune.
• The device is blocked by the device type restrictions.
• The computer is running Windows 10 Home. However, enrolling in Intune or joining Microsoft Entra ID is only supported on Windows 10 Pro and higher editions. 
• The Microsoft Entra setting Users may join devices to Microsoft Entra ID is set to None, which prevents new users from joining their devices to Microsoft Entra ID. Therefore Intune enrollment fails.

I checked all these conditions and couldn't find the problem.

The user had not enrolled any device previously so that wasn't it.

Windows MDM enrollments are allowed. I don't need Personally owned Windows devices as I'm not using Autopilot Device Preparation.

The device is running Windows 11 Professional.

All users are allowed to join devices to Entra ID.

The troubleshooting article doesn't mention licensing but I checked that too and all was good.

Then I found it. The MDM Authority was set to Unknown. I hadn't been asked to select it when setting up the tenant. I'd never seen this before.

Luckily there are a few ways to fix this. You can use this link to get directly to where you can select Intune as the MDM Authority    

https://intune.microsoft.com/#view/Microsoft_Intune_Enrollment/ChooseMDMAuthorityBlade

Alternatively you can use a Guided Scenario to force the page to show. 

Navigate to Troubleshooting + Support and select Guided scenarios (preview). Click Start.

The Choose MDM Authority page appears. Select Intune MDM Authority and click Choose.

The MDM Authority has been set to Intune.

I could see that reflected in the console. That's more like it.

That solved the problem and I could continue with my testing. 

I hope this helps. Until next time......

Managed software updates on Apple devices with Intune

We've been able to configure software update policies on iOS and macOS devices for a while, right. However this is new and different, released in March 2025 (Service release 2503). "Managed software updates" means something very specific. We can now configure devices to automatically update to the latest OS version using Apple Declarative device management.

Declarative device management (DDM) is an update to the existing protocol for device management that can be used in combination with the existing MDM protocol capabilities. It allows the device to asynchronously apply settings and report status back to the MDM solution without constant polling. This is ideal for performance and scalability.

To configure Managed software updates, navigate to Devices > Manage devices > Configuration > Create > New policy > choose iOS/iPadOS or macOS for platform > select Settings catalog for profile type.

Add the setting Declarative device management > Software Update Enforce Latest. 

You'll also see the "Software Update" and "Software Updates Settings" setting, more on them shortly.

We have three items to configure

• Enforce Latest Software Update Version: If true, devices will upgrade to the latest OS version that is available for that device model. This uses the Software Update Enforcement configuration and will force devices to restart and install the update after the deadline passes.
• Delay In Days: Specifies the number of days that should pass before a deadline is enforced. This delay is based on either the posting date of the new update when released by Apple, or when the policy is configured.
• Install Time (optional): Specifies the local device time for when updates are enforced. This setting uses the 24-hour clock format where midnight is 00:00 and 11:59pm is 23:59. Ensure that you include the leading 0 on single digit hours. For example, 01:00, 02:00, 03:00.

The configuration in the screenshot will force an update of the device 1 day after Apple release an update, at no particular time. The device will always remain at the latest OS version. This is called an "automatic managed software updates policy".

If you select the Software Update setting in the settings picker, your options are different.

• Details URL (optional): Enter a web page URL that has more information on the update. Typically, this URL is a web page hosted by your organization that users can select if they need organization-specific help with the update.
• Target Build Version (optional): Enter the target build version to update the device to, like 20A242. The build version can include a supplemental version identifier, like 20A242a. If the build version you enter isn't consistent with the Target OS Version value you enter, then the Target OS Version value takes precedence.
• Target Date Time: Select or manually enter the date and the time that specifies when to force the installation of the software update.
• Target OS Version: Select or manually enter the target OS version to update the device to. This value is the OS version number, like 16.1. You can also include a supplemental version identifier, like 16.1.1.

This is called a "manual managed software updates policy" as you need to create a new one for every OS version you need to update to. You would use this policy if you are unsure about updating to the latest and greatest as soon as possible.

Remember Software Updates Setting in the Setting picker, what is that one about?.

This give us a single place to configure managed software updates. You may want to manage aspects of the software update process leading up to the enforcement of an update. Using this configuration, you can:

• Require that an admin or standard user can perform updates on the device
• Control how users can manually interact with software update settings like automatic download and install or the behavior of Rapid Security Responses
• Hide updates from users for a specified time period
• Suppress update notifications up to one hour before the enforcement deadline
• Control whether users are allowed to update to the latest major update, latest minor update, or are offered both.

Precedence

Now that we have several places to configure updates for iOS and macOS devices, what happens when there is a conflict? Managed software updates (both automatic and manual) have precedence over other policies that configure software updates. If you configure managed software updates and also have other software update policies assigned, then it's possible the other update policies have no effect.

iOS/iPadOS precedence order:

1. Managed software updates (Settings catalog > Declarative Device Management > Software Update)
2. Update policies (Devices > Update policies for iOS/iPadOS)

macOS precedence order:

1. Managed software updates (Settings catalog > Declarative Device Management > Software Update)
2. Update policies (Devices > Update policies for macOS)
3. Software updates (Settings catalog > System Updates > Software Update)

We have seen that you can create software update policies or managed software update policies for Apple devices in Intune. Both policy types can manage the install of software updates on devices. However, there are some differences between the two policy types. Microsoft have provided a table to help you decide which policy type to use.

I hope this helps you to understand the new "managed" policy type and how it differs from what we already had. Until next time.....

On-premises printing with cloud native devices

In the past year my colleagues and I have helped many customers to prepare their environments for cloud native devices. 

What is a cloud native device? It's a device where all management is provided by the cloud. In the Microsoft world this means a device which is Entra joined and enrolled in Intune. The key here is the authentication. The device must authenticate with Entra. Entra hybrid devices authenticate with Active Directory so they do not qualify as cloud native devices.

Printing is usually one of the challenges organizations face. Often Group Policy Objects have traditionally been used to control access to printers. By default non-administrators are not allowed to install drivers on domain joined devices. This can be managed by allowing users to install driver packages for the classes below, all configured by GPO:

• {4658ee7e-f050-11d1-b6bd-00c04fa372a7}
• {4d36e979-e325-11ce-bfc1-08002be10318}

All the users need to do is browse to the print server and double click the printer to add the queue without any elevation.

GPOs are not applied to Entra devices so we need to find another way to deal with printers using Intune. I know, I know we should be using Universal Printing. However many customers have heavy investments in on-premises printing and we need to help them rather than tell them that they are wrong.

There is an equivalent Intune configuration policy where we can allow users to install drivers for the same classes above. However I don't want users to install drivers at all. I want to pre-install all the necessary print drivers to make the device as secure as possible. It's pretty straightforward and involves a couple of scripts. 

Disclaimer: I'm not a master scripter. The scripts don't contain any error checking. However they are functional and they work well. No complaints please 😏😏😏

I've picked an example printer that I worked with recently.

The Canon Image Runner Advanced C256i is a big old expensive printer and was one of the models used by a recent customer. The customer provided the print driver.

Tip: you do not need all the files that are downloaded in a bundle from the vendor website. In this case it contained 47.4MB of data.

You just need the drivers. Typically this is a folder containing .inf and .cab files. This one had 17MB of data. You'll notice a few extra files here. We'll come to them shortly.

First we need to check that these files will add the print driver that I need. Open the .inf file to see what is inside. It's called cnnv4_cb3_fgeneric.inf in this example but the name will be different in each case.

I can see that this .inf file is aware of two print drivers

• Canon Generic LIPSLX V4
• Canon Generic UFR II V4

Which one do I need? I had a look in the properties of the queue on the print server and could see that I needed "Canon Generic LIPSLX V4". Now I could get started.

The install.cmd file is a simple script that performs the following actions:

1. Creates a local folder C:\PrinterDrivers\Canon
2. Copies all the required files to this folder
3. Adds the print driver using prndrvr.vbs

What is prndrvr.vbs? It's a Visual Basic script native to the operating system which adds, deletes and lists printer drivers. You can read about it here. 

The script uses the following parameters:

• a: adds a printer
• m: specifies (by name) the driver you want to install
• i: specifies the complete path and file name for the driver you want to install

install.cmd script (you'll need to replace the vendor name, the driver name and the inf filename).

@echo off

mkdir C:\PrinterDrivers\Canon

xcopy *.* /h /c /k /e /r /y C:\PrinterDrivers\Canon

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs" -a -m "Canon Generic LIPSLX V4" -i "C:\PrinterDrivers\Canon\cnnv4_cb3_fgeneric.inf"

I'm going to deploy the solution as a Win32 app. Therefore I also need a detection method. I'm using a custom script for that. The script performs the following:

1. Executes Get-PrinterDriver
2. Looks for "Canon Generic LIPSLX V4"
3. Returns an exit code, 0 = success

Detection_Script.ps1

$driverExists = Get-Printerdriver | Where-Object {$_.Name -like "Canon Generic LIPSLX V4"}

if($driverExists) {

  Write-Host "Success"

  Exit 0

} else {

  Exit 1

}

Next job is to create and deploy a Win32 app using Install.cmd as the installation and Detection_Script.ps1 as the custom detection.

This is the result. The correct print driver is pre-installed. You can see a few others there as well as the Canon.

What happens next? Well, now you can just browse to the print server and double click to add the print queue. The driver already exists so you will not be prompted for elevation.

Alternatively you could create an available Win32 app which could be self-installed via Company Portal. Replace with the name of your print server and queue

Add-Printer -ConnectionName \\printserver.domain.local\Canon_Colour

This will work as the installation script.

$printerExists = Get-CimInstance -Class Win32_Printer | Where-Object {$_.Name -like "\\printserver.domain.local\Canon_Colour}

if($printerExists) {

  Write-Host "Success"

  Exit 0

} else {

  Exit 1

}

This will work as the detection script.

Thanks to my colleague Rahul Jindal for reminding me about prndrvr

I hope this helps. Until next time.....

Apple Rapid Security Response and Intune

Back to main macOS page

Rapid Security Responses (RSR) are a type of software release for iPhone, iPad, and MacOS devices. They deliver important security improvements between major software updates. They can also be used to mitigate some security issues more quickly. Rapid Security Responses are supported for versions starting with iOS 16.4.1, iPadOS 16.4.1, and macOS 13.3.1.

By default, Apple devices automatically apply Rapid Security Responses. Users may be prompted to restart their device.

iPhone or iPad: Go to Settings > General > Software Update > Automatic Updates, you should see that "Security Responses & System Files" is turned on. This is from my iOS 18.3.1 device.

Mac: Choose Apple menu > System Settings. Click General in the sidebar, then click Software Update on the right. Click the Show Detail button next to Automatic Updates, you should see that "Install Security Responses and system files" is turned on.

When a Rapid Security Response has been applied, a letter appears after the software version number, for example, macOS 13.3.1 became 13.3.1 (a) after the first RSR was applied, then (b) etc. Build numbers is a bit more complicated. The build number for macOS 13.3.1 is 22E261 but 13.3.1 (a) is 22E772610a. You need to know the build number if you will be configuring Intune policies.

So what can we configure with Intune? Remember RSR is enabled by default.

Settings catalog

Some configurations are available via the Settings Catalog and are identical for iOS and macOS.

Settings are available in two categories:

Restrictions:

• Allow Rapid Security Response Installation - if 'false', Rapid Security Response will be disabled
• Allow Rapid Security Response Removal - if 'false', users are unable to remove the Rapid Security Response option.

Declarative Device Management preview Software Update Settings:

• Enable - if 'false', Rapid Security Responses are not offered for user installation. If 'true', Rapid Security Responses are offered to the user.
• Enable Rollback - if 'false', Rapid Security Response rollbacks are not offered to the user. If 'true', Rapid Security Response rollbacks are offered to the user.

Compliance

You can configure an Apple Rapid Security Response update as the minimum OS build in an Intune compliance policy, for use with conditional access. 

Enter the supplemental build version. For example, 22E772610a is macOS 13.3.1 (a). Note that this had some teething problems when first released as the version wasn't detected correctly and conditional access blocked compliant devices. 

I hope this helps you to understand Apple Rapid Security Responses and what you can configure in Intune. Until next time......