My first look at Intune Agents (part3)

This is the third is a series of blog posts about Intune Agents. Intune Agents (also known as Security Copilot agents) are AI-powered assistants, available in the Intune Admin Center, that enhance enterprise security. They automate tasks for endpoint protection, identity management, threat intelligence, and device configuration, and they help IT teams quickly address vulnerabilities, policy gaps, and emerging threats.

The first post in the series introduced Security Copilot and SCUs, and then took a closer look at the Change Review Agent. The second post concentrated on the Device Offboarding Agent. In this post I'll be looking at the Policy Configuration Agent, arguably the most useful of the Intune Agents. It helps IT admins to translate complex requirements and industry standard documents into actionable Intune settings. You give the agent an input that has your policy requirements. It can be a document you upload or direct text input. In this way, admins can quickly generate Intune settings catalog policies.

Set up the agent as follows.

In the Intune admin center, select Agents > Policy Configuration Agent > View details

In Overview, select Set up agent.

The Set up Policy Configuration Agent pane lists the required permissions to set up the agent, and provides more information about the setup requirements. Select Set up agent.

When it completes, the agent is ready to use.

I want to add a document to give some context to the agent. I do this selecting Create New > Knowledge source. My first thought would be that it would be really cool to be able to add a CIS benchmark baseline here. 

I entered a Knowledge Source name and description. However this first attempt at adding a Knowledge Source failed. The CIS benchmark is a 7MB PDF. It was then that I noticed that only .txt files up to 100KB are supported. I believe that this is under review. 

Also there is an error in the UI which then refers to 2KB being the maximum. 

For demo purposes I copied the first few pages from the CIS benchmark into a .txt file and I could create a Knowledge Source with the following instructions.

Ensure 'Enforce password history' is set to '24 or more password(s)'

Ensure 'Maximum password age' is set to '365 or fewer days, but not 0'

Ensure 'Minimum password age' is set to '1 or more day(s)'

Ensure 'Network access: Named Pipes that can be accessed anonymously' is set to 'None'

Ensure 'Network access: Remotely accessible registry paths' is configured

Select Review to continue.

The agent has provided suggested next steps. Click on the Suggestion.

We are provided with a Document Analysis Summary.

Scrolling down we can see the proposed settings. I've reviewed them and I'm happy that is what I want.

Next step is to create a Policy Draft.

Enter a name and refer to the CIS benchmark Knowledge source. Under Instructions, I've asked the agent to create a configuration policy with these settings.

The agent generates a suggested Policy Draft. Click on the draft.

The agent shows us the suggested policy settings. Click on Create configuration profile.

We can see the policy settings. Click Next.

The configuration profile has been created, based on the Settings catalog. Assign the configuration profile to a group as required.

I can also just use natural language to generate a configuration policy without the need for a knowledge source. 

In this case I just need a Policy Draft.

Enter a name and description but do not select a knowledge source. Under Instructions, I've asked the agent to generate a policy to set the local timezone on Windows devices. to GMT. This is a standard request.

The agent has provided a suggested draft. Click on the draft.

We can see the policy summary.

Scroll down to see the specific settings. Click Create configuration policy.

Looks good. This is exactly the setting I would configure if I was doing this manually. Continue to create the policy and assign to a group.

I hope you are finding these posts helpful to see how useful the Intune agents can be. Currently there are three available (in Preview), but more will surely follow. My next post in this series will explore how we can find and use additional agents.

Until next time....

My first look at Intune Agents (part2)

This is a continuation of the blog post I published last week. In that post I had my first look at Intune Agents and looked more closely at the Change Review Agent. This time I'll be looking at the Device Onboarding Agent. This agent identifies stale devices across Intune and Entra ID, provides actionable insights, and offboards stale devices for you.

Some things to know:

• To run an Agent, you will need sufficient Security Compute Units (SCUs) in the tenant, as per the previous blog post.
• The agent supports Windows, iOS/iPadOS, macOS, Android, and Linux devices.
• The agent supports both corporate-owned and BYOD scenarios.
• At this time, the agent doesn't support:
• Hybrid Entra-joined Windows devices
• Windows Autopilot devices
• Shared devices
• Microsoft Teams Phones
• Once the Agent has been configured, it can be run by a Read Only Operator (Intune) and Security Reader (Entra).
• The agent identifies devices that were retired, wiped, or deleted from Intune within the last 30 days.
• The agent limits results to the first 10,000 devices.

Ok, so let's get started. Navigate to Agents in the Intune Admin Center.

Click View details for the Device Offboarding Agent.

Click to Run the Agent.

You are told that re-running the agent clears previous suggestions and recommendations. Click Run to start the job.

The Agent finishes and I have a result. This is my test lab where I have created a stale device for demonstration purposes. I can see Suggested next steps and one device affected. Click on Remove Windows Corporate devices.

We are presented with a Summary and associated factors. The Summary tells us that "there is one corporate Windows device that is no longer in Intune but is in other portals. This device should be removed". It would be better if I had more devices in the report but that is still pretty cool.

We also get a recommended action plan of six actions. 

Action 1: Download affected device list.

Click Download CSV

The CSV file contains the Entra device ID(s) of the stale devices.

Action 2: Back up BitLocker recovery keys

We are presented with the recommended steps to back up BitLocker recovery keys (outside the scope of the agent).

Action 3: Back up Local Admin Password Solution

We are presented with the recommended steps to export LAPS passwords (outside the scope of the agent).

Action 4: Remove devices from the Defender portal

We are presented with the recommended steps to remove devices from the Defender portal (outside the scope of the agent).

Action 5: Remove devices from Autopilot

We are presented with the recommended steps to remove devices from Autopilot (outside the scope of the agent).

Action 6: Disable devices in Microsoft Entra

The last action allows us to disable the stale devices in Microsoft Entra. Click on Disable devices.

We have to confirm that we want to Disable the devices. This action removes all the stale devices from Entra ID.

We can now see this under the Suggestions tab. These are not retained when the Agent is run again.

Note that you have to manually change the Status tab to Completed.

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

See my follow up post

My first look at Intune Agents (part3)

My first look at Intune Agents (part1)

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.......

See my follow up posts

My first look at Intune Agents (part2)

My first look at Intune Agents (part3)

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......