Something I have been waiting on for a while with Entra ID Global Secure Access (GSA) has been the availability of the Internet traffic profile on iOS.
When I check the latest version of Defender on my iDevices I found that this has now been enabled, provided better protection and advanced filtering like I have on other devices.
When I also updated my Windows devices I found that there is a nice new admin console available as well.
Microsoft Entra ID Global Secure Access helps small businesses protect their data and simplify IT by combining secure sign-in, app access, and network protection in one solution. It uses a modern “Zero Trust” approach, which means every user and device is verified before getting access, reducing the risk of cyberattacks. Instead of juggling multiple tools or complex VPNs, you get a single, easy-to-manage system that works for office, remote, and mobile workers. It improves employee experience with one login for all apps, supports flexible work without slowing things down, and scales as your business grows—all while saving costs by replacing multiple security products with one integrated service.
This guide will provide a comprehensive, production-safe approach using both the Microsoft 365 Defender portal and Exchange Online PowerShell. We will start with a baseline of security and then layer on advanced protections. The core strategy involves keeping the default EOP anti-malware policy as a foundational safety net while creating a higher-priority, custom policy for sensitive users, such as executives and finance teams. This ensures critical assets have the most aggressive, up-to-date protection without disrupting the entire organisation. We’ll also cover essential features like the Common Attachment Filter, Safe Attachments, Safe Links, and the Zero-hour Auto Purge (ZAP) engine to defend against a wide array of evolving threats, from zero-day malware to sophisticated phishing attacks.
1. Prerequisites & Licensing Checks
Before you begin, it’s crucial to understand your licensing model.
Exchange Online Protection (EOP): This is the baseline email security included with all Microsoft 365 subscriptions (e.g., Business Basic, Standard, E3). It provides fundamental anti-malware and anti-spam protection.
Microsoft Defender for Office 365 (MDO): This is an add-on or an included feature in higher-tier plans (e.g., Microsoft 365 Business Premium, E5). MDO Plan 1 adds Safe Attachments and Safe Links, while MDO Plan 2 adds advanced hunting, investigation, and automation features (e.g., Threat Explorer, Automated Investigation and Response). This guide assumes you may have an MDO licence and will detail the optional add-ons.
2. Policy Inventory & Strategic Approach
Best Practice: Do not modify the Default anti-malware policy. This ensures a consistent baseline of protection across all users who aren’t covered by a custom policy. Instead, create new, more restrictive policies for targeted, high-risk groups. Policies are processed by priority (0 being the highest), so a new custom policy with priority 0 will apply to its users, and the default policy will catch everyone else.
GUI Method: Inventory Existing Policies
Navigate to the Microsoft Defender portal at https://security.microsoft.com.
Go to Email & collaboration → Policies & rules → Threat policies.
Under the Policies section, click on Anti-malware. You will see the default policy and any custom ones you have created.
PowerShell Method: Inventory Existing Policies
First, connect to Exchange Online.
PowerShell
# Connect to Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName <your-admin-email> -ShowProgress:$true
Then, view the current policies.
PowerShell
# Get all malware filter policies and their associated rules
Get-MalwareFilterPolicy
Get-MalwareFilterRule
3. Recommended Anti-malware Settings
This section details the recommended settings for your new custom anti-malware policy.
GUI Method: Creating a New Policy
In the Microsoft Defender portal, go to the Anti-malware page from the previous step.
Click Create a policy.
Give the policy a descriptive Name (e.g., High-Risk Users - Anti-malware Policy) and a Description. Click Next.
On the Users and domains page, choose the users, groups, or domains you want to protect. For our example, select Groups and search for ExecutiveTeam. Click Next.
On the Protection settings page, configure the following:
Protection settings
Enable zero-hour auto purge for malware: This is a service-side feature that, when enabled, automatically removes previously delivered malicious messages from user mailboxes. It’s a key part of EOP and is highly recommended.
Quarantine policy: Use the default AdminOnlyAccessPolicy. The rationale is simple: end-users should not be able to release malware. This prevents them from accidentally or maliciously releasing a dangerous file.
Common attachments filter
Check Enable common attachments filter. This is a powerful, extension-based block list that is a fantastic first line of defence. The list of file types has been expanded by Microsoft, but you should periodically review it.
Click Customize file types and ensure a robust list of high-risk file types is selected. The list should include: exe, dll, js, jse, vbs, vbe, ps1, com, cmd, bat, jar, scr, reg, lnk, msi, msix, iso, img, 7z, zipx. You can also add other file types that are not needed in your environment, such as wsf, wsh, url.
Notifications
Admin notifications: Check Notify an admin about undelivered messages from internal senders and Notify an admin about undelivered messages from external senders. Use your security mailbox for this (e.g., security@contoso.com).
Sender notifications:Do not enable Notify internal sender or Notify external sender. Notifying external senders can validate their address for future spam, and an internal sender’s mailbox might be compromised, which could alert the attacker.
PowerShell Method: Creating and Configuring the Policy
This script is idempotent (you can run it multiple times without errors) and will create or update the policies as needed.
PowerShell
# --- PowerShell Script to Configure Exchange Online Anti-malware Policies ---
# Define variables for your tenant
$tenantDomain = "contoso.com"
$highRiskGroupName = "ExecutiveTeam"
$adminNotificationMailbox = "security@contoso.com"
$policyName = "High-Risk Users - Anti-malware Policy"
$ruleName = "High-Risk Users - Anti-malware Rule"
# Define the common attachment filter file types
$fileTypes = @(
'ade','adp','ani','app','bas','bat','chm','cmd','com','cpl',
'crt','csh','dll','exe','fxp','hlp','hta','inf','ins','isp',
'jar','js','jse','ksh','lnk','mda','mdb','mde','mdt','mdw',
'mdz','msc','msi','msix','msp','mst','pcd','pif','prg','ps1',
'reg','scr','sct','shb','shs','url','vb','vbe','vbs','wsc',
'wsf','wsh','xnk','iso','img','7z','zipx','docm','xlsm'
)
# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName $adminNotificationMailbox -ShowProgress:$true
# Check if the policy exists
$policy = Get-MalwareFilterPolicy -Identity $policyName -ErrorAction SilentlyContinue
if ($null -ne $policy) {
Write-Host "Policy '$policyName' already exists. Updating settings..." -ForegroundColor Yellow
Set-MalwareFilterPolicy -Identity $policyName `
-Action DeleteMessage `
-EnableFileFilter:$true `
-FileTypes $fileTypes `
-EnableInternalSenderAdminNotifications:$true `
-EnableExternalSenderAdminNotifications:$true `
-AdminDisplayName "Custom policy for high-risk users."
} else {
Write-Host "Policy '$policyName' not found. Creating a new one..." -ForegroundColor Green
New-MalwareFilterPolicy -Name $policyName `
-Action DeleteMessage `
-EnableFileFilter:$true `
-FileTypes $fileTypes `
-EnableInternalSenderAdminNotifications:$true `
-EnableExternalSenderAdminNotifications:$true `
-AdminDisplayName "Custom policy for high-risk users."
}
# Check if the rule exists
$rule = Get-MalwareFilterRule -Identity $ruleName -ErrorAction SilentlyContinue
if ($null -ne $rule) {
Write-Host "Rule '$ruleName' already exists. Updating settings..." -ForegroundColor Yellow
Set-MalwareFilterRule -Identity $ruleName `
-MalwareFilterPolicy $policyName `
-Comments "Applies to high-risk group." `
-SentToMemberOf $highRiskGroupName `
-Priority 0
} else {
Write-Host "Rule '$ruleName' not found. Creating a new one..." -ForegroundColor Green
New-MalwareFilterRule -Name $ruleName `
-MalwareFilterPolicy $policyName `
-Comments "Applies to high-risk group." `
-SentToMemberOf $highRiskGroupName `
-Priority 0
}
Write-Host "Configuration complete. Run 'Get-MalwareFilterPolicy' and 'Get-MalwareFilterRule' to verify." -ForegroundColor Green
4. Defender for Office 365 Add-ons (If Licensed)
These advanced policies provide an additional layer of protection.
Safe Attachments: This sandboxing technology “detonates” email attachments in a virtual environment to detect zero-day malware.
Block: The most secure option. Messages with attachments are held while being scanned. If a threat is found, the message is blocked and quarantined. This can introduce a short delay (minutes) for emails with attachments.
Dynamic Delivery: A balance between security and user experience. The email body is delivered immediately with a placeholder for the attachment. The attachment is delivered once the scan is complete. Use this for users who can tolerate a minor delay on the attachment itself but need the email content right away. For a high-risk user group, Block is often the recommended setting.
Safe Links: This feature scans URLs at the time of the click, not just upon arrival. If a URL is later determined to be malicious, it will be blocked even if it was safe when the email was first received.
Zero-hour Auto Purge (ZAP): ZAP for malware is included in EOP and is enabled by default. MDO adds ZAP for high-confidence phishing and spam. This is a powerful, service-side feature that removes messages that have already been delivered to a user’s inbox if new threat intelligence indicates they are malicious. There is no per-policy PowerShell switch for this; its behaviour is managed by the service and the policy’s action on detection.
5. Quarantine Policies
Quarantine policies control what users can do with messages held in quarantine.
The default quarantine policy for malware (AdminOnlyAccessPolicy) prevents end-users from releasing messages. This is the recommended setting. You can create a new policy and enable notifications or release requests for other threat types (e.g., spam), but for malware, keep it locked down.
You can set up quarantine notifications (digests) for users, which provide a summary of messages in their quarantine.
6. Testing & Validation
Once your policies are configured, you must validate them.
The EICAR Test
Use a safe, legal test file to validate your policies. The EICAR (European Institute for Computer Antivirus Research) test file is a non-malicious file that all major anti-malware programs will detect.
To test the Common Attachment Filter, create a plain text file, rename it to eicar.zip, and place the EICAR string X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* inside it.
To test Safe Attachments, send a test email with the EICAR file attached (as a .zip or other container) to a user in your test group.
Verifying with Message Trace
In the Microsoft Defender portal, go to Email & collaboration → Exchange message trace.
Search for the test message.
Click on the message to view details. The Event field should show a Fail status with the reason Malware.
Header Analysis: You can also check the message headers. Look for the X-Forefront-Antispam-Report header and the SCL (Spam Confidence Level) and PCL (Phishing Confidence Level) values. A message blocked by an anti-malware policy will have a CAT (Category) entry indicating malware.
7. Ongoing Monitoring & Tuning
Threat Explorer (MDO P2) / Reports (EOP): Regularly review the Threat Explorer (or Reports for EOP) in the Microsoft Defender portal to see what threats are being blocked. This helps you identify trends, attack vectors, and potential false positives.
Configuration Analyzer: Located under Email & collaboration → Policies & rules → Threat policies → Configuration analyzer, this tool compares your custom policies to Microsoft’s recommended Standard and Strict preset security policies. Use it to find and fix settings that are less secure than the recommended baselines.
ORCA Module: The Office 365 Recommended Configuration Analyzer (ORCA) is a community-developed PowerShell module that provides a comprehensive report of your M365 security posture. While not an official Microsoft tool, it’s an excellent resource for a deeper dive.
False Positive/Negative Submissions: If a legitimate message is blocked (false positive) or a malicious message gets through (false negative), you must submit it to Microsoft for analysis to improve their detection engines. The submission workflow is found under Actions & submissions → Submissions in the Microsoft Defender portal.
8. Change Control & Rollback
Documentation: Always document any changes made to a policy, including the date, reason, and the specific settings changed.
Phased Rollout: When creating a new policy, first apply it to a small test group before rolling it out to production users.
Rollback: If you encounter issues, you can disable the custom policy in the GUI by toggling its status to Off or with PowerShell using Set-MalwareFilterRule -Identity "Rule Name" -State Disabled. You can also decrease its priority to ensure it no longer applies.
9. Final Checklist
Use this checklist to ensure all best practices have been implemented.
[ ] Prerequisites: Confirm M365 Business Premium or Defender for Office 365 licensing for advanced features.
[ ] Policy Strategy: Leave the default anti-malware policy untouched as a safety net.
[ ] New Policy: Create a new custom anti-malware policy for high-risk users/groups (e.g., ExecutiveTeam).
[ ] Action: Set the action for malware detection to Quarantine the message.
[ ] Common Attachment Filter: Enable and verify a comprehensive list of high-risk file extensions.
[ ] Admin Notifications: Configure admin notifications for malware detections.
[ ] Sender Notifications: Disable notifications for both internal and external senders.
[ ] Safe Attachments (if licensed): Configure a new policy and set the action to Block for high-risk users.
[ ] Safe Links (if licensed): Configure a new policy to scan URLs in emails at the time of click.
[ ] Quarantine Policies: Confirm the quarantine policy for malware is set to AdminOnlyAccessPolicy to prevent user releases.
[ ] Testing: Send a test email with a containerised EICAR file to a user in the new policy’s scope.
[ ] Validation: Use Message Trace to confirm the message was blocked, and review the headers for malware detection results.
[ ] Monitoring: Schedule a regular review of threat reports and submissions.
[ ] Tuning: Address false positives/negatives by submitting them to Microsoft.
[ ] Change Control: Document all changes and have a rollback plan in place.
[ ] Configuration Analyser: Run the Configuration Analyser and compare your policies to Microsoft’s recommended settings.
For more information, refer to these authoritative resources:
Small and medium businesses (SMBs) with remote employees have shifted from a single “office network” model to a Zero Trust model. Microsoft 365 Business Premium (BPP) already includes extensive security layers – identity protection, device management, email scanning, and endpoint defenselearn.microsoft.comlearn.microsoft.com. With those controls fully configured, the traditional on-premises network perimeter (and thus an expensive firewall appliance) becomes far less critical. In practice, a standard router/NAT firewall combined with Windows/macOS built‑in firewalls and M365’s cloud protections can cost‑effectively secure a remote SMB. We explain how M365 BPP’s features cover typical firewall functions, and when a dedicated firewall (beyond a basic one) may not be needed.
Built-In Security in Microsoft 365 Business Premium
Microsoft 365 Business Premium bundles multiple security layers: endpoint protection, identity/access controls, device management, and more. Key built‑in features include:
Endpoint Security – Microsoft Defender for Business (included) provides next‑gen antivirus, threat detection/response and a host firewall on each devicelearn.microsoft.comlearn.microsoft.com. Devices (Windows, macOS, iOS, Android) get managed protection against ransomware, malware and network attacks.
Email and App Protection – Defender for Office 365 Plan 1 (included) scans email attachments and links for malware and phishing. Safe Links/Safe Attachments help stop threats before they reach userslearn.microsoft.com.
Identity and Access (Zero Trust) – Azure AD Premium P1 (included) enables Conditional Access policies and mandatory multi-factor authenticationmicrosoft.comlearn.microsoft.com. Only compliant, enrolled devices can access company resources, and admins/devices are always re‑authenticated.
Device Management – Microsoft Intune can enforce security policies on all devices: requiring device encryption (BitLocker), patching, endpoint firewalls, and even configuring VPN or Wi‑Fi profileslearn.microsoft.comlearn.microsoft.com. In short, Intune ensures every device meets the company’s security baseline before it connects.
Secure Remote Access – Azure AD Application Proxy (via Azure AD P1) publishes any on‑premises app through Azure AD, so remote users can reach internal resources without opening inbound firewall portssherweb.com. This often replaces a VPN or on‑site reverse proxy, making remote access simpler and safer.
These built-in layers cover most attack vectors. For example, M365 BPP’s Defender for Business includes a managed host-based firewall and web filtering, so each laptop is protected on any networklearn.microsoft.com. And Conditional Access can block sign-ins from unsecured locations or unregistered devices, effectively extending the network perimeter to only trusted endpoints.
Zero Trust and Remote Work
In a modern SMB, employees “can work anywhere,” so the old model of trusting the office LAN no longer applies. As Microsoft describes, traditional protections rely on firewalls and VPNs at fixed locations, whereas Zero Trust assumes no network is inherently safelearn.microsoft.com. Every sign-in is verified (via Azure AD) and every device is checked (via Intune) no matter where the user is.
In this diagram, a corporate firewall on the left no longer suffices when employees roam (right side)learn.microsoft.com. With Business Premium, identity and device policies take over: multifactor authentication and Conditional Access ensure only known users on compliant devices connectlearn.microsoft.commicrosoft.com. In effect, the organization’s “perimeter” is the cloud. Remote workers authenticate directly to Azure/Office 365 and receive Microsoft’s protection (e.g. encrypted tunnels, safe browser checks), rather than passing first through an on‑site firewall.
Host-Based Firewalls and Device Security
Even without a hardware firewall, devices must protect themselves on untrusted networks. All common operating systems include a built‑in firewall. Enabling these host firewalls is free and highly effective – many MSP guides advise turning on Windows Defender Firewall (and macOS’s) on every device before even buying a hardware applianceguardianangelit.com. Microsoft Defender for Business not only installs antivirus but can manage each device’s firewall settings: for instance, Intune can push a profile that blocks all inbound traffic except essential serviceslearn.microsoft.com.
By treating each endpoint as its own secured “network edge,” an SMB covers the user’s connection in coffee shops or home Wi‑Fi. For example, if a user’s laptop is on public Wi‑Fi, the Windows firewall (enforced by Defender policies) stops inbound attacks, while Defender’s web protection filters malicious sites. This layered endpoint approach (antivirus+EDR + host firewall + encrypted disk) significantly shrinks the need for a central firewall inspecting all traffic.
Network Perimeter and When to Use Firewalls
If an SMB still maintains an office or data closet, some firewall or router will normally be used for basic perimeter functions (NAT, DHCP, segmentation of guest networks, etc.). However, the level of firewall needed is typically minimal. A basic managed router or inexpensive UTM is often enough to separate IoT/guest Wi-Fi from internal staff, and to enforce outbound rules. Beyond that, heavy enterprise firewalls yield little benefit in a predominantly cloud-centric setup.
For remote-heavy SMBs, many experts suggest zero-trust access (e.g. VPN, ZTNA) instead of relying on office hardware. ControlD’s SMB security checklist, for instance, recommends ensuring VPN or Zero-Trust Network Access for remote employees, rather than expecting them to route through the office firewallcontrold.com. In other words, with cloud apps and M365-managed devices, the on‑site firewall sees only its local subnet – almost all work and threats are already handled by Microsoft’s cloud services and endpoint defenses.
Configuring M365 Business Premium as Your “Firewall”
A Business Premium tenant can be tuned to cover typical firewall functions:
Enroll and Update All Devices: Use Intune (part of BPP) to enroll every company device (Windows, Mac, mobile) and onboard them to Defender for Businesslearn.microsoft.comlearn.microsoft.com. Ensure full disk encryption (BitLocker/FileVault), automatic OS updates, and Defender real‑time protection are all enabled.
Enforce Host Firewalls: Create an Intune endpoint security policy that turns on Windows Defender Firewall for all profiles (Domain/Private/Public) and disables unnecessary inbound rulesguardianangelit.comlearn.microsoft.com. Similarly, enable the macOS firewall via Intune configuration. This ensures devices block unwanted network traffic by default.
Enable Multi-Factor Authentication & Conditional Access: Turn on Azure AD security defaults or define Conditional Access policies so that every login requires MFA and checks device compliancelearn.microsoft.commicrosoft.com. You can restrict access by device state or location, preventing unknown devices from even reaching company apps.
Protect Email and Apps: Activate Defender for Office 365 (Plan 1) to scan all incoming email and Teams messages. Safe Links/Attachments in Office documents serve as an additional layer that no firewall can providelearn.microsoft.com.
Use Application Proxy for Internal Apps: If you have any on-premises servers, install the Azure AD Application Proxy connector. This publishes apps (e.g. intranet, CRM) through Azure without punching holes in your firewallsherweb.com. Remote users then access the app via Azure AD login, with no need to maintain a VPN or open router ports.
Monitor and Respond: Use Microsoft 365 Defender’s security portal (included) to monitor alerts. Its threat analytics will flag unusual traffic or sign-ins. Automated investigation and remediation in Defender for Business can contain a threat on a device before it spreads.
Network-Level Protections (Optional): For extra DNS- or web-filtering, an SMB might add services like Microsoft Defender SmartScreen (built into Edge/Windows) or a cloud DNS filter. These complement – but don’t replace – the firewall; they block malicious domains at the device level.
In this configuration, each device and identity becomes a control point. The M365 stack effectively sits in front of your data, rather than hardware at the network perimeter.
Cost vs. Benefit of Dedicated Firewalls
Without regulatory mandates, a high-end firewall appliance is often not cost-justified for an SMB fully on M365. The hardware itself and ongoing subscriptions (threat feeds, VPN licenses, maintenance) add significant cost. Given that M365 Business Premium already provides next-generation protection on endpoints and enforces secure access, the marginal security gain from a $2k+ firewall is small for remote-centric SMBs.
That said, a simple firewall/router is still recommended for the office LAN. It can provide:
Basic NAT/segmentation: Separating staff devices from guest or IoT VLANs.
VPN termination (if needed): A site‑to‑site VPN or point‑to‑site gateway for branch offices or legacy systems (though Azure VPN with Azure AD is an alternative).
On‑prem device connectivity: If on-premises servers exist, the firewall can regulate incoming traffic.
For example, installing Azure AD Application Proxy (no cost beyond BPP license) often removes the need to expose an on‑site port for remote accesssherweb.com. Similarly, if home users connect via secure VPN with M365 credentials, the corporate firewall is bypassed by design.
In contrast, host-based security and cloud controls cover most threats: phishing and remote intrusion are handled by Defender and MFA, malware is stopped at the device, and data exfiltration is controlled by identity and DLP settings. As one MSP guide notes, for small businesses the built-in OS firewalls should be used before investing in hardware firewallsguardianangelit.com. In practice, the total protective overlap from Intune+Defender+Conditional Access can eliminate many risks that a hardware firewall is meant to address.
Conclusion
For a typical SMB with Microsoft 365 Business Premium fully enabled, the need for an expensive dedicated firewall is greatly reduced. M365 BPP delivers comprehensive security – endpoint protection, email filters, and zero-trust access – that, when properly configured, cover most attack vectorslearn.microsoft.comlearn.microsoft.com. A basic network firewall (even the one built into a router) is useful for simple segmentation, but beyond that most protections are handled by Microsoft’s cloud services and host firewalls. In short, by leveraging Business Premium’s features (Defender, Intune, Azure AD P1, etc.), an SMB can safely rely on default and cloud-managed defenses rather than purchasing a high-end firewall applianceguardianangelit.comsherweb.com.
Here are 10 tailored prompts you can use with your ASD Secure Cloud Blueprint agent to address common Microsoft 365 Business Premium security concerns for SMBs, with a focus on automated implementation using PowerShell:
🔐 Identity & Access Management
“What are the ASD Blueprint recommendations for securing user identities in M365 Business Premium, and how can I enforce MFA using PowerShell?”
“How does the ASD Blueprint suggest managing admin roles in M365 Business Premium, and what PowerShell scripts can I use to audit and restrict global admin access?”
📁 Data Protection & Information Governance
“What ASD Blueprint controls apply to protecting sensitive data in M365 Business Premium, and how can I automate DLP policy deployment with PowerShell?”
“How can I implement ASD Blueprint-compliant retention policies in Exchange and SharePoint using PowerShell for M365 Business Premium tenants?”
🛡️ Threat Protection
“What are the ASD Blueprint recommendations for Defender for Office 365 in Business Premium, and how can I configure anti-phishing and safe links policies via PowerShell?”
“How can I automate the deployment of Microsoft Defender Antivirus settings across endpoints in line with ASD Blueprint guidance using PowerShell?”
🔍 Auditing & Monitoring
“What audit logging standards does the ASD Blueprint recommend for M365 Business Premium, and how can I enable and export unified audit logs using PowerShell?”
“How can I use PowerShell to monitor mailbox access and detect suspicious activity in accordance with ASD Blueprint security controls?”
🔧 Configuration & Hardening
“What baseline security configurations for Exchange Online and SharePoint Online are recommended by the ASD Blueprint, and how can I apply them using PowerShell?”
“How can I automate the disabling of legacy authentication protocols in M365 Business Premium to meet ASD Blueprint standards using PowerShell?”
Here are 10 ready-to-use prompts you can ask your ASD-aligned security agent to tackle the most common SMB security issues in Microsoft 365 Business Premium tenants. Each prompt is engineered to:
Align with the ASD Secure Cloud Blueprint / Essential Eight and ACSC guidance
Use only features available in M365 Business Premium
Produce clear, step-by-step outcomes you can apply immediately
Avoid E5-only capabilities (e.g., Entra ID P2, Defender for Cloud Apps, Insider Risk, Auto-labelling P2, PIM)
Tip for your agent: For each prompt, request outputs in this structure: (a) Current state → (b) Gaps vs ASD control → (c) Recommended configuration (Business Premium–only) → (d) Click-path + PowerShell → (e) Validation tests & KPIs → (f) Exceptions & rollback.
Prompt: “Assess our tenant’s MFA and sign-in posture against ASD/ACSC guidance using only Microsoft 365 Business Premium features. Return: (1) Conditional Access policies to enforce MFA for all users, admins, and high-risk scenarios (without Entra ID P2); (2) exact assignments, conditions, grant/ session controls; (3) block legacy authentication; (4) break-glass account pattern; (5) click-paths in Entra admin portal and Exchange admin centre; (6) PowerShell for disabling per-user MFA legacy and enabling CA-based MFA; (7) how to validate via Sign-in logs and audit; (8) exceptions for service accounts and safe rollback.”
Prompt: “Create Intune compliance and configuration baselines for Windows/macOS/iOS/Android aligned to ASD/ACSC using Business Premium. Include: (1) Windows BitLocker and macOS FileVault enforcement; (2) OS version minimums, secure boot, tamper protection, firewall, Defender AV; (3) jailbreak/root detection; (4) role-based scope (admins stricter); (5) conditional access ‘require compliant device’ for admins; (6) click-paths and JSON/OMA-URI where needed; (7) validation using device compliance reports and Security baselines; (8) exceptions for servers/VDI and rollback.”
4) BYOD Data Protection (App Protection / MAM-WE)
Prompt: “Design BYOD app protection for iOS/Android using Intune App Protection Policies (without enrollment), aligned to ASD data protection guidance. Deliver: (1) policy sets for Outlook/Teams/OneDrive/Office mobile; (2) cut/copy/save restrictions, PIN/biometrics, encryption-at-rest, wipe on sign-out; (3) Conditional Access ‘require approved client app’ and ‘require app protection policy’; (4) blocking downloads to unmanaged locations; (5) step-by-step in Intune & Entra; (6) user experience notes; (7) validation and KPIs (unenrolled device access, selective wipe success).”
5) Endpoint Security with Defender for Business (EDR/NGAV/ASR)
Prompt: “Harden endpoints using Microsoft Defender for Business (included in Business Premium) to meet ASD controls. Return: (1) Onboarding method (Intune) and coverage; (2) Next-Gen AV, cloud-delivered protection, network protection; (3) Attack Surface Reduction rules profile (Business Premium-supported), Controlled Folder Access; (4) EDR enablement and Automated Investigation & Response scope; (5) threat & vulnerability management (TVM) priorities; (6) validation via MDE portal; (7) KPIs (exposure score, ASR rule hits, mean time to remediate).”
6) Patch & Update Strategy (ASD: Patch Apps/OS)
Prompt: “Produce a Windows Update for Business and Microsoft 365 Apps update strategy aligned to ASD Essential Eight for SMB. Include: (1) Intune update rings and deadlines; (2) quality vs feature update cadence, deferrals, safeguards; (3) Microsoft 365 Apps channel selection (e.g., Monthly Enterprise); (4) TVM-aligned prioritisation for CVEs; (5) rollout waves and piloting; (6) click-paths, policies, and sample assignments; (7) validation dashboards and KPIs (patch latency, update compliance, CVE closure time).”
7) External Sharing, DLP & Sensitivity Labels (ASD: Data Protection)
Prompt: “Lock down external sharing and implement Data Loss Prevention using Business Premium (no auto-labelling P2), aligned to ASD guidance. Deliver: (1) SharePoint/OneDrive external sharing defaults, link types, expiration; (2) guest access policies for Teams; (3) Purview DLP for Exchange/SharePoint/OneDrive—PII templates, alerting thresholds; (4) user-driven sensitivity labels (manual) for email/files with recommended taxonomy; (5) transport rules for sensitive emails to external recipients; (6) step-by-step portals; (7) validation & KPIs (external sharing volume, DLP matches, label adoption).”
8) Least Privilege Admin & Tenant Hygiene (ASD: Restrict Admin)
Prompt: “Review and remediate admin privileges and app consent using Business Premium-only controls. Provide: (1) role-by-role least privilege mapping (Global Admin, Exchange Admin, Helpdesk, etc.); (2) emergency access (‘break-glass’) accounts with exclusions and monitoring; (3) enforcement of user consent settings and admin consent workflow; (4) risky legacy protocols and SMTP AUTH usage review; (5) audit logging and alert policies; (6) step-by-step remediation; (7) validation and KPIs (admin count, app consents, unused privileged roles).”
9) Secure Score → ASD Gap Analysis & Roadmap
Prompt: “Map Microsoft Secure Score controls to ASD Essential Eight and generate a 90‑day remediation plan for Business Premium. Return: (1) Top risk-reducing actions feasible with Business Premium; (2) control-to-ASD mapping; (3) effort vs impact matrix; (4) owner, dependency, and rollout sequence; (5) expected Secure Score lift; (6) weekly KPIs and reporting pack (including recommended dashboards). Avoid recommending E5-only features—offer Business Premium alternatives.”
10) Detection & Response Playbooks (SMB-ready)
Prompt: “Create incident response playbooks using Defender for Business and Defender for Office 365 for common SMB threats (phishing, BEC, ransomware). Include: (1) alert sources and severities; (2) triage steps, evidence to collect, where to click; (3) auto-investigation actions available in Business Premium; (4) rapid containment (isolate device, revoke sessions, reset tokens, mailbox rules sweep); (5) user comms templates and legal/escalation paths; (6) post-incident hardening steps; (7) validation drills and success criteria.”
Optional meta‑prompt you can prepend to any of the above
“You are my ASD Secure Cloud Blueprint agent. Only recommend configurations available in Microsoft 365 Business Premium. If a control typically needs E5/P2, propose a Business Premium‑compatible alternative and flag the limitation. Return exact portal click-paths, policy names, JSON samples/PowerShell, validation steps, and KPIs suitable for SMBs.”
ASD’s Blueprint for Secure Cloud is a comprehensive set of security guidelines published by the Australian Signals Directorate. It details how to configure cloud services (including Microsoft 365) to meet high security standards, incorporating strategies like the Essential Eight. For Microsoft 365, the Blueprint covers everything from enforcing multi-factor authentication and blocking legacy authentication, to hardening Office 365 services (Exchange, SharePoint, Teams) and securing Windows devices via Intune policies[1][2]. By creating a dedicated Copilot Chat agent based on this Blueprint, you give your organisation an easy way to access all that expertise. The agent will act as a virtual security advisor: available through Microsoft Teams (Copilot Chat) to answer questions, provide configuration guidance, and even supply automation scripts – all for free using your existing M365 subscription.
Below is a step-by-step guide to build the agent within the Copilot Chat interface, followed by examples of how it can improve your Microsoft 365 security management.
Step-by-Step: Creating the Copilot Agent in Teams Copilot Chat
You can create the agent entirely within the Microsoft 365 Copilot Chat interface (such as in Teams), using the built-in Agent Builder. There’s no need to use separate tools or write code. Here’s how to set it up quickly:
Note: The above assumes that the Copilot Agents feature is enabled in your tenant. Microsoft made Copilot Chat available to all users by 2025, but an admin might need to turn on custom agent creation if it’s in preview. Check your M365 admin settings for “Copilot” or “Agents” if you don’t see the option to create an agent. Once enabled, any user can build or use agents in Copilot Chat[3].
How the Agent Improves M365 Security
With your M365 Security Copilot agent up and running, your IT team (and potentially all employees) can leverage it in several ways to strengthen security. Here are some examples of what it can do:
1. Instant Q&A on Security Best Practices
The agent can answer questions about Microsoft 365 security configurations, drawing directly from the ASD Blueprint’s guidance and related Microsoft documentation. This is like having a security policy expert available 24/7.
Example:“What does the ASD Blueprint say about email protection?” – The agent might respond: “It recommends enabling Microsoft Defender for Office 365 features like Safe Links and Safe Attachments for all users[2]. Safe Links will check URLs in emails and documents for malicious content and redirect users if the link is unsafe. Safe Attachments will open email attachments in a sandbox to detect malware before delivering them to the recipient[2].” It would likely go on to mention anti-phishing policies as well. This guidance helps you know which settings to configure (e.g. turn on Safe Links and Safe Attachments in your Exchange Online security policies).
Example:“Do we allow legacy email protocols?” – Legacy protocols like IMAP/POP3 (which use Basic Auth) are a known security risk. The agent knows the Blueprint stance is to disable them in favour of Modern Authentication. It might answer: “No. According to ASD’s guidelines, legacy authentication protocols such as POP3 and IMAP should be disabled[4]. This prevents attackers from bypassing MFA. You should ensure only Modern Auth is allowed for Exchange Online.” The agent could even cite Microsoft’s policy that basic auth is deprecated. This reminds your team to verify those settings (or use the script the agent provides, which we’ll see below).
Example:“What are the password requirements for Windows 10 devices?” – The agent can pull from the Intune compliance policy Blueprint. It could respond: “The Blueprint’s baseline for Windows 10 requires a complex password of at least 15 characters[1]. Simple passwords are blocked, and the device must be encrypted with BitLocker[1]. It also enforces screen lock after 15 minutes of inactivity.” This gives a clear answer that aligns with your organisation’s policy (assuming you adopt the Blueprint settings).
Why this helps: It eliminates guesswork. Admins and helpdesk staff don’t have to search through lengthy documents or remember every detail. They can just ask the agent and get an authoritative answer with the reasoning included. This ensures consistent application of security best practices.
2. Guidance for Implementation and Automation
The agent doesn’t just cite policy – it can help you implement it. Through step-by-step guidance or actual code snippets, it translates the recommendations into action:
Step-by-Step Instructions: For instance, if you ask “How do I enforce MFA for all users?”, the agent will explain the methods. It might say: “To enforce MFA, you have options: (1) Enable Security Defaults in Azure AD, which require MFA for all users by default; or (2) create a Conditional Access policy that requires MFA for all sign-ins[2]. In Azure AD portal, go to Conditional Access -> New policy, assign to all users, cloud apps All, then under Access Controls, require MFA.” It will outline these steps clearly. If the Blueprint or Microsoft docs have a sequence, it will present it in order. This is like having a tutor walk you through the Azure AD configuration.
PowerShell Script Generation: Perhaps the biggest time-saver. The agent can generate scripts to configure settings across your tenant:
If you say, “Give me a PowerShell script to disable POP and IMAP for all mailboxes,” the agent can produce something like:
It knows from context that disabling these protocols is recommended, and the commands to do so. In fact, this script (getting all mailboxes and piping to Set-CASMailbox to turn off POP/IMAP) is a common solution[4]. The agent might add, “This script connects to Exchange Online and then disables POP and IMAP on every user’s mailbox.” With this, an admin can copy-paste and execute it in PowerShell to enforce the policy in seconds.
Another example: “Generate a script to require MFA for all users.” The agent could output a script using Azure AD PowerShell to set MFA on each account. For instance, it might use the MSOnline module:
And it would explain that this iterates through all users and enforces MFA. This aligns with the Blueprint’s mandate for MFA everywhere. The agent is effectively writing the code so you don’t have to. (As always, you should test such scripts in a safe environment, but it provides a solid starting point.) Not here that the MSOL module has been deprecated by Microsoft and you really should use the latest option. Always check your results from AI!
The agent can assist with device policies too. If you ask, “How can I deploy the Windows 10 baseline settings?”, apart from describing the steps in Intune, it might mention scriptable options (like exporting the Blueprint’s Intune configuration as JSON and using Graph API or PowerShell to import it). It will guide you to the appropriate tooling.
Why this helps: It automates tedious work and ensures it’s done right. Many IT admins know what they need to do conceptually, but writing a script or clicking through dozens of settings can be error-prone. The agent provides ready-made, Blueprint-aligned solutions. This speeds up implementation of secure configurations. Your team can focus on higher-level oversight rather than nitty-gritty syntax.
3. Organisation-Wide Security Awareness
By sharing the agent with the whole organisation, you extend its benefits beyond the IT/security team (if desired):
Empowering Helpdesk and Junior Staff: Frontline IT support can use the agent to answer user questions or to verify they’re giving correct advice. For example, if a user asks “Why can’t I use my old Outlook 2010 with company email?”, a helpdesk tech could consult the agent, which might answer: “Outlook 2010 uses legacy authentication which is not allowed because it doesn’t support modern security features. We require newer Outlook versions or clients that support Modern Auth to protect your account.” This backs up the helpdesk with authoritative reasoning.
Training New Team Members: New hires in the IT department can learn your security policies by interacting with the agent. They can ask it various “why do we do X” questions and get consistent answers. It’s like an interactive policy manual. Over time, this improves everyone’s understanding of security in the company.
Consistent Messaging: The agent will always refer to the Blueprint’s guidance. This means the language and recommendations are consistent. If two different people ask about, say, OneDrive sharing settings, they’ll get the same answer from the agent. Consistency is key in security – you don’t want conflicting info. The agent ensures one voice (that of the ASD Blueprint) is answering.
4. Keeping the Agent (and Advice) Up-to-Date
As threats evolve and the ASD Blueprint (or Microsoft’s recommendations) update, you can refresh the agent easily:
Periodically check the Blueprint site for updates. If new sections or changes appear (e.g., a new recommendation to use a particular security feature), you can update the agent’s knowledge. In Copilot’s agent settings, you can re-index the website or add new URLs if needed. For example, if a new “Design Decision” is added on the blueprint site about a feature, include it.
You might also feed the agent additional sources. Suppose Microsoft releases a detailed blog on a new M365 security feature not covered by the current Blueprint. You can add that blog URL to the agent’s sources. Now the agent can incorporate that into its answers as well.
Because you can edit the agent’s instructions at any time, you can also adjust its behavior. If your organisation decides on a custom policy that slightly deviates from the Blueprint, you can instruct the agent about that. For instance, “our company chooses to disable feature X due to internal reasons – reflect that in answers.”
All of this ensures the agent remains a living tool that adapts to the latest best practices and your organisation’s needs.
Example Questions & Agent Responses
To illustrate, here are some example questions you could ask your new security Copilot agent, and the kind of answers you can expect:
Question
Agent’s Response (Summary)
“How do I enforce MFA for all users?”
“Multi-Factor Authentication is mandatory for all users. The ASD Blueprint advises enabling it tenant-wide. You can do this by turning on Azure AD Security Defaults or creating a Conditional Access policy requiring MFA for all accounts. This ensures every login uses a second factor, which makes accounts 99.9% less likely to be compromised[5].” The agent would then guide through setting up the policy (as described in step-by-step above).
“Give me a script to disable legacy email auth.”
“To block legacy authentication (like basic auth for POP/IMAP) on Exchange Online, run the following PowerShell commands: Connect-ExchangeOnline -Credential (Get-Credential) Get-Mailbox -ResultSize Unlimited | Set-CASMailbox -PopEnabled $false -ImapEnabled $false This disables POP and IMAP for all mailboxes[4], forcing the use of Modern Authentication (which supports MFA).”
“What are the device security requirements?”
“For Windows 10/11 devices, the Blueprint baseline requires: BitLocker disk encryption enabled, a password of at least 15 characters with complexity, screen lock after 15 minutes, and up-to-date antivirus/antispyware protection[1]. Jailbroken or rooted mobile devices are not compliant. These ensure devices meet a strong security standard.”
“How can we protect email from phishing?”
“Use Microsoft Defender for Office 365. The Blueprint recommends Safe Links and Safe Attachments for all users[2]. Safe Links will scan and rewrite URLs in incoming emails to shield users from malicious sites. Safe Attachments will open email attachments in a virtual machine to detect malware. Enable these in your Office 365 security center under Threat Management > Policy.” The agent might also mention anti-phishing policies and user training reminders.
“Why do we insist on MFA for login?”
“Because it dramatically improves security. As Microsoft reports, an account is over 99.9% less likely to be hacked if MFA is enabled[5]. The ASD Blueprint therefore mandates MFA for all users. Even if a password is stolen, the attacker cannot get in without the second factor.” This kind of answer provides the rationale you can pass on to users or execs who ask the same question.
These examples show how the agent can be used in practice. It provides precise, actionable answers with evidence (often even citing the official guidance). By interacting with the agent, your IT staff can save time and ensure they’re following the correct procedures, and your end-users get consistent answers on why security measures are in place.
In summary, a dedicated Copilot Chat agent based on the ASD Secure Cloud Blueprint can greatly streamline your Microsoft 365 security operations. It’s free to set up (since Copilot Chat agents are available to all M365 users[3]), quick to distribute via Teams, and immediately useful for both answering questions and executing security tasks. Your organisation gets the benefit of an always-available expert that reflects approved best practices, helping you raise the security baseline across the board.
In this episode of the CIAOPS “Need to Know” podcast, we dive into the latest updates across Microsoft 365, GitHub Copilot, and SMB-focused strategies for scaling IT services. From new Teams features to deep dives into DLP alerts and co-partnering models for MSPs, this episode is packed with insights for IT professionals and small business tech leaders looking to stay ahead of the curve. I also take a look at building an agent to help you work with frameworks like the ASD Blueprint for Secure Cloud.
Microsoft’s Windows Autopilot is a cloud-based suite of technologies designed to streamline the deployment and configuration of new Windows devices for organizations[1]. This guide provides a detailed look at the latest updates to Windows Autopilot – specifically the new Autopilot v2 (officially called Windows Autopilot Device Preparation) – and offers step-by-step instructions for implementing it in a Microsoft 365 Business environment. We will cover the core concepts, new features in Autopilot v2, benefits for businesses, the implementation process (from prerequisites to deployment), troubleshooting tips, and best practices for managing devices with Autopilot v2.
1. Overview of Microsoft Autopilot and Its Purpose
Windows Autopilot simplifies the Windows device lifecycle from initial deployment through end-of-life. It leverages cloud services (like Microsoft Intune and Microsoft Entra ID) to pre-configure devices out-of-box without traditional imaging. When a user unboxes a new Windows 10/11 device and connects to the internet, Autopilot can automatically join it to Azure/Microsoft Entra ID, enroll it in Intune (MDM), apply corporate policies, install required apps, and tailor the out-of-box experience (OOBE) to the organization[1][1]. This zero-touch deployment means IT personnel no longer need to manually image or set up each PC, drastically reducing deployment time and IT overhead[2]. In short, Autopilot’s purpose is to get new devices “business-ready” with minimal effort, offering benefits such as:
Reduced IT Effort – No need to maintain custom images for every model; devices use the OEM’s factory image and are configured via cloud policies[1][1].
Faster Deployment – Users only perform a few quick steps (like network connection and sign-in), and everything else is automated, so employees can start working sooner[1].
Consistency & Compliance – Ensures each device receives standard configurations, security policies, and applications, so they immediately meet organizational standards upon first use[2].
Lifecycle Management – Autopilot can also streamline device resets, repurposing for new users, or recovery scenarios (for example, using Autopilot Reset to wipe and redeploy a device)[1].
2. Latest Updates: Introduction of Autopilot v2 (Device Preparation)
Microsoft has recently introduced a next-generation Autopilot deployment experience called Windows Autopilot Device Preparation (commonly referred to as Autopilot v2). This new version is essentially a re-architected Autopilot aimed at simplifying and improving deployments based on customer feedback[3]. Autopilot v2 offers new capabilities and architectural changes that enhance consistency, speed, and reliability of device provisioning. Below is an overview of what’s new in Autopilot v2:
No Hardware Hash Import Required: Unlike the classic Autopilot (v1) which required IT admins or OEMs to register devices in Autopilot (upload device IDs/hardware hashes) beforehand, Autopilot v2 eliminates this step[4]. Devices do not need to be pre-registered in Intune; instead, enrollment can be triggered simply by the user logging in with their work account. This streamlines onboarding by removing the tedious hardware hash import process[3]. (If a device is already registered in the old Autopilot, the classic profile will take precedence – so using v2 means not importing the device beforehand[5].)
Cloud-Only (Entra ID) Join: Autopilot v2 currently supports Microsoft Entra ID (Azure AD) join only – it’s designed for cloud-based identity scenarios. Hybrid Azure AD Join (on-prem AD) is not supported in v2 at this time[3]. This focus on cloud join aligns with modern, cloud-first management in Microsoft 365 Business environments.
Single Unified Deployment Profile: The new Autopilot Device Preparation uses a single profile to define all deployment settings and OOBE customization, rather than separate “Deployment” and “ESP” profiles as in legacy Autopilot[3]. This unified profile encapsulates join type, user account type, and OOBE preferences, plus it lets you directly select which apps and scripts should install during the setup phase.
Enrollment Time Grouping: Autopilot v2 introduces an “Enrollment Time Grouping” mechanism. When a user signs in during OOBE, the device is automatically added to a specified Azure AD group on the fly, and any applications or configurations assigned to that group are immediately applied[5][5]. This replaces the old dependence on dynamic device groups (which could introduce delays while membership queries run). Result: faster and more predictable delivery of apps/policies during provisioning[5].
Selective App Installation (OOBE): With Autopilot v1, all targeted device apps would try to install during the initial device setup, possibly slowing things down. In Autopilot v2, the admin can pick up to 10 essential apps (Win32, MSI, Store apps, etc.) to install during OOBE; any apps not selected will be deferred until after the user reaches the desktop[3][6]. By limiting to 10 critical apps, Microsoft aimed to increase success rates and speed (as their telemetry showed ~90% of deployments use 10 or fewer apps initially)[6].
PowerShell Scripts Support in ESP: Autopilot v2 can also execute PowerShell scripts during the Enrollment Status Page (ESP) phase of setup[3]. This means custom configuration scripts can run as part of provisioning before the device is handed to the user – a capability that simplifies advanced setup tasks (like configuring registry settings, installing agent software, etc., via script).
Improved Progress & UX: The OOBE experience is updated – Autopilot v2 provides a simplified progress display (percentage complete) during provisioning[6]. Users can clearly see that the device is installing apps/configurations. Once the critical steps are done, it informs the user that setup is complete and they can start using the device[6][6]. (Because the device isn’t identified as Autopilot-managed until after the user sign-in, some initial Windows setup screens like EULA or privacy settings may appear in Autopilot v2 that were hidden in v1[3]. These are automatically suppressed only after the Autopilot policy arrives during login.)
Near Real-Time Deployment Reporting: Autopilot v2 greatly enhances monitoring. Intune now offers an Autopilot deployment report that shows status per device in near real time[6]. Administrators can see which devices have completed Autopilot, which stage they’re in, and detailed results for each selected app and script (success/failure), as well as overall deployment duration[5][5]. This granular reporting makes troubleshooting easier, as you can immediately identify if (for example) a particular app failed to install during OOBE[5][5].
Availability in Government Clouds: The new Device Preparation approach is available in GCC High and DoD government cloud environments[6][5], which was not possible with Autopilot previously. This broadens Autopilot use to more regulated customers and is one reason Microsoft undertook this redesign (Autopilot v2 originated as a project to meet government cloud requirements and then expanded to all customers)[7].
The table below summarizes key differences between Autopilot v1 (classic) and Autopilot v2:
Feature/Capability
Autopilot v1 (Classic)
Autopilot v2 (Device Preparation)
Device preregistration (Hardware hash upload)
Required (devices must be registered in Autopilot device list before use)[4]
Not required (user can enroll device directly; device should not be pre-added, or v2 profile won’t apply)[5]
Supported join types
Azure AD Join; Hybrid Azure AD Join (with Intune Connector)[3]
Azure/Microsoft Entra ID Join only (no on-prem AD support yet)[3]
Not supported in initial release[3] (future support is planned for these scenarios)
Deployment profiles
Separate Deployment Profile + ESP Profile (configuration split)
Single Device Preparation Policy (one profile for all settings: join, account type, OOBE, app selection)[3]
App installation during OOBE
Installs all required apps targeted to device (could be many; admin chooses which are “blocking”)
Installs selected apps only (up to 10) during OOBE; non-selected apps wait until after OOBE[3][6]
PowerShell scripts in OOBE
Not natively supported in ESP (workarounds needed)
Supported – can run PowerShell scripts during provisioning (via device prep profile)[3]
Policy application in OOBE
Some device policies (Wi-Fi, certs, etc.) could block in ESP; user-targeted configs had limited support
Device policies synced at OOBE (not blocking)[3]; user-targeted policies/apps install after user reaches desktop[3]
Out-of-Box experience (UI)
Branding and many Windows setup screens are skipped (when profile is applied from the start of OOBE)
Some Windows setup screens appear by default (since no profile until sign-in)[3]; afterwards, shows new progress bar and completion summary[6]
Reporting & Monitoring
Basic tracking via Enrollment Status Page; limited real-time info
Detailed deployment report in Intune with near real-time status of apps, scripts, and device info[5]
Why these updates? The changes in Autopilot v2 address common pain points from Autopilot v1. By removing the dependency on upfront registration and dynamic groups, Microsoft has made provisioning more robust and “hands-off”. The new architecture “locks in” the admin’s intended config at enrollment time and provides better error handling and reporting[6][6]. In summary, Autopilot v2 is simpler, faster, more observable, and more reliable – the guiding principles of its design[5] – making device onboarding easier for both IT admins and end-users.
3. Benefits of Using Autopilot v2 in a Microsoft 365 Business Environment
Implementing Autopilot v2 brings significant advantages, especially for organizations using Microsoft 365 Business or Business Premium (which include Intune for device management). Here are the key benefits:
Ease of Deployment – Less IT Effort: Autopilot v2’s no-registration model is ideal for businesses that procure devices ad-hoc or in small batches. IT admins no longer need to collect hardware hashes or coordinate with OEMs to register devices. A user can unbox a new Windows 11 device, connect to the internet, and sign in with their work account to trigger enrollment. This self-service enrollment reduces the workload on IT staff, which is especially valuable for small IT teams.
Faster Device Setup: By limiting installation to essential apps during OOBE and using enrollment time grouping, Autopilot v2 gets devices ready more quickly. End-users see a shorter setup time before reaching the desktop. They can start working sooner with all critical tools in place (e.g. Office apps, security software, etc. installed during setup)[7][7]. Non-critical apps or large software can install in the background later, avoiding long waits up-front.
Improved Reliability and Fewer Errors: The new deployment process is designed to “fail fast” with better error details[6]. If something is going to go wrong (for example, an app that fails to install), Autopilot v2 surfaces that information quickly in the Intune report and does not leave the user guessing. The enrollment time grouping also avoids timing issues that could occur with dynamic Azure AD groups. Overall, this means higher success rates for device provisioning and less troubleshooting compared to the old Autopilot. In addition, by standardizing on cloud join only, many potential complexities (like on-prem domain connectivity during OOBE) are removed.
Enhanced User Experience: Autopilot v2 provides a more transparent and reassuring experience to employees receiving new devices. The OOBE progress bar with a percentage complete indicator lets users know that the device is configuring (rather than appearing to be stuck). Once the critical setup is done, Autopilot informs the user that the device is ready to go[6]. This clarity can reduce helpdesk calls from users unsure if they should wait or reboot during setup. Also, because devices are delivered pre-configured with corporate settings and apps, users can be productive on Day 1 without needing IT to personally assist.
Better Monitoring for IT: In Microsoft 365 Business environments, often a single admin oversees device management. The Autopilot deployment report in Intune gives that admin a real-time dashboard to monitor deployments. They can see if a new laptop issued to an employee enrolled successfully, which apps/scripts ran, and if any step failed[5][5]. For any errors, the admin can drill down immediately and troubleshoot (for instance, if an app didn’t install, they know to check that installer or assign it differently). This reduces guesswork and allows proactive support, contributing to a smoother deployment process across the organization.
Security and Control: Autopilot v2 includes support for corporate device identification. By uploading known device identifiers (e.g., serial numbers) into Intune and enabling enrollment restrictions, a business can ensure only company-owned devices enroll via Autopilot[4][4]. This prevents personal or unauthorized devices from accidentally being enrolled. Although this requires a bit of setup (covered below), it gives small organizations an easy way to enforce that Autopilot v2 is used only for approved hardware, adding an extra layer of security and compliance. Furthermore, Autopilot v2 automatically makes the Azure AD account a standard user by default (not local admin), which improves security on the endpoint[5].
In summary, Autopilot v2 is well-suited for Microsoft 365 Business scenarios: it’s cloud-first and user-driven, aligning with the needs of modern SMBs that may not have complex on-prem infrastructure. It lowers the barrier to deploying new devices (no imaging or device ID admin work) while improving the speed, consistency, and security of device provisioning.
4. Implementing Autopilot v2: Step-by-Step Guide
In this section, we’ll walk through how to implement Windows Autopilot Device Preparation (Autopilot v2) in your Microsoft 365 Business/Intune environment. The process involves: verifying prerequisites, configuring Intune with the new profile and required settings, and then enrolling devices. Each step is detailed below.
4.1 Prerequisites and Initial Setup
Before enabling Autopilot v2, ensure the following prerequisites are met:
Windows Version Requirements: Autopilot v2 requires Windows 11. Supported versions are Windows 11 22H2 or 23H2 with the latest updates (specifically, installing KB5035942 or later)[3][5], or any later version (Windows 11 24H2+). New devices should be shipped with a compatible Windows 11 build (or be updated to one) to use Autopilot v2. Windows 10 devices cannot use Autopilot v2; they would fall back to the classic Autopilot method.
Microsoft Intune: You need an Intune subscription (Microsoft Endpoint Manager) as part of your M365 Business. Intune will serve as the Mobile Device Management (MDM) service to manage Autopilot profiles and device enrollment.
Azure AD/Microsoft Entra ID: Devices will be Azure AD joined. Ensure your users have Microsoft Entra ID accounts with appropriate Intune licenses (e.g., Microsoft 365 Business Premium includes Intune licensing) and that automatic MDM enrollment is enabled for Azure AD join. In Azure AD, under Mobility (MDM/MAM), Microsoft Intune should be set to Automatically enroll corporate devices for your users.
No Pre-Registration of Devices: Do not import the device hardware IDs into the Intune Autopilot devices list for devices you plan to enroll with v2. If you previously obtained a hardware hash (.CSV) from your device or your hardware vendor registered the device to your tenant, you should deregister those devices to allow Autopilot v2 to take over[5]. (Autopilot v2 will not apply if an Autopilot deployment profile from v1 is already assigned to the device.)
Intune Connector (If Hybrid not needed): Since Autopilot v2 doesn’t support Hybrid AD join, you do not need the Intune Connector for Active Directory for these devices. (If you have the connector running for other hybrid-join Autopilot scenarios, that’s fine; it simply won’t be used for v2 deployments.)
Network and Access: New devices must have internet connectivity during OOBE (Ethernet or Wi-Fi accessible from the initial setup). Ensure that the network allows connection to Azure AD and Intune endpoints. If using Wi-Fi, users will need to join a Wi-Fi network in the first OOBE steps. (Consider using a provisioning SSID or instructing users to connect to an available network.)
Plan for Device Identification (Optional but Recommended): Decide if you will restrict Autopilot enrollment to corporate-owned devices only. For better control (and to prevent personal device enrollment), it’s best practice to use Intune’s enrollment restrictions to block personal Windows enrollments and use Corporate device identifiers to flag your devices. We will cover how to set this up in the steps below. If you plan to use this, gather a list of device serial numbers (and manufacturers/models) for the PCs you intend to enroll.
4.2 Configuring the Autopilot v2 (Device Preparation) Profile in Intune
Once prerequisites are in place, the core setup work is done in Microsoft Intune. This involves creating Azure AD groups and then creating a Device Preparation profile (Autopilot v2 profile) and configuring it. Follow these steps:
1. Create Azure AD Groups for Autopilot: We need two security groups to manage Autopilot v2 deployment:
User Group – contains the users who will be enrolling devices via Autopilot v2.
Device Group – will dynamically receive devices at enrollment time and be used to assign apps/policies.
In the Azure AD or Intune portal, navigate to “Groups” and create a new group for users. For example, “Autopilot Device Preparation – Users”. Add all relevant user accounts (e.g., all employees or the subset who will use Autopilot) to this group[4]. Use Assigned membership for explicit control.
Next, create another security group for devices, e.g., “Autopilot Device Preparation – Devices”. Set this as a Dynamic Device group if possible, or Assigned (we will be adding devices automatically via the profile). An interesting detail: Intune’s Autopilot v2 mechanism uses an application identity called “Intune Provisioning Client” to add devices to this group during enrollment[4]. You can assign that as the owner of the group (though Intune may handle this automatically when the profile is used).
2. Create the Device Preparation (Autopilot v2) Profile: In the Intune admin center, go to Devices > Windows > Windows Enrollment (or Endpoint Management > Enrollment). There should be a section for “Windows Autopilot Device Preparation (Preview)” or “Device Preparation Policies”. Choose to Create a new profile/policy[4].
Name and Group Assignment: Give the profile a clear name (e.g., “Autopilot Device Prep Policy – Cloud PCs”). For the target group, select the Device group created in step 1 as the group to assign devices to at enrollment[4]. (In some interfaces, you might first choose the device group in the profile so the system knows where to add devices.)
Deployment Mode: Choose User-Driven (since user-driven Azure AD join is the scenario for M365 Business). Autopilot v2 also has an “Automatic” mode intended for Windows 365 Cloud PCs or scenarios without user interaction, but for physical devices in a business, user-driven is typical.
Join Type: Select Azure AD (Microsoft Entra ID) join. (This is the only option in v2 currently – Hybrid AD join is not available).
User Account Type: Choose whether the end user should be a standard user or local admin on the device. Best practice is to select Standard (non-admin) to enforce least privilege[5]. (In classic Autopilot, this was an option in the deployment profile as well. Autopilot v2 defaults to standard user by design, but confirm the setting if presented.)
Out-of-box Experience (OOBE) Settings: Configure the OOBE customization settings as desired:
You can typically configure Language/Region (or set to default to device’s settings), Privacy settings, End-User License Agreement (EULA) acceptance, and whether users see the option to configure for personal use vs. organization. Note: In Autopilot v2, some of these screens may not be fully suppressible as they are in v1, but set your preferences here. For instance, you might hide the privacy settings screen and accept EULA automatically to streamline user experience.
If the profile interface allows it, enable “Skip user enrollment if device is known corporate” or similar, to avoid the personal/work question (this ties in with using corporate identifiers).
Optionally, set a device naming template if available. However, Autopilot v2 may not support custom naming at this stage (and users can be given the ability to name the device during setup)[3]. Check Intune’s settings; if not present, plan to rename devices via Intune policy later if needed.
Applications & Scripts (Device Preparation): Select the apps and PowerShell scripts that you want to be installed during the device provisioning (OOBE) phase[4]. Intune will present a list of existing apps and scripts you’ve added to Intune. Here, pick only your critical or required applications – remember the limit is 10 apps max for the OOBE phase. Common choices are:
Company Portal (for user self-service and additional app access)[4].
Endpoint protection software (antivirus/EDR agent, if not already part of Windows).
Any other crucial line-of-business app that the user needs immediately. Also select any PowerShell onboarding scripts you want to run (for example, a script to set a custom registry or install a specific agent that’s not packaged as an app). These selected items will be tracked in the deployment. (Make sure any app you select is assigned in Intune to the device group we created, or available for all devices – more on app assignment in the next step.)
Assign the Profile: Finally, assign the Device Preparation profile to the User group created in step 1[4]. This targeting means any user in that group who signs into a Windows 11 device during OOBE will trigger this Autopilot profile. (The device will get added to the specified device group, and the selected apps will install.)
Save/create the profile. At this point, Intune has the Autopilot v2 policy in place, waiting to apply at next enrollment for your user group.
3. Assign Required Applications to Device Group: Creating the profile in step 2 defines which apps should install, but Intune still needs those apps to be deployed as “Required” to the device group for them to actually push down. In Intune:
Go to Apps > Windows (or Apps section in MEM portal).
For each critical app you included in the profile (Company Portal, Office, etc.), check its Properties > Assignments. Make sure to assign the app to the Autopilot Devices group (as Required installation)[4]. For example, set Company Portal – Required for [Autopilot Device Preparation – Devices][4].
Repeat for Microsoft 365 Apps and any other selected application[4]. If you created a PowerShell script configuration in Intune, ensure that script is assigned to the device group as well.
Essentially, this step ensures Intune knows to push those apps to any device that appears in the devices group. Autopilot v2 will add the new device to the group during enrollment, and Intune will then immediately start installing those required apps. (Without this step, the profile alone wouldn’t install apps, since the profile itself only “flags” which apps to wait for but the apps still need to be assigned to devices.)
4. Configure Enrollment Restrictions (Optional – Corporate-only): If you want to block personal devices from enrolling (so that only corporately owned devices can use Autopilot), set up an enrollment restriction in Intune:
In Intune portal, navigate to Devices > Enrollment restrictions.
Create a new Device Type or Platform restriction policy (or edit the existing default one) for Windows. Under Personal device enrollment, set Personally owned Windows enrollment to Blocked[4].
Assign this restriction to All Users (or at least all users in the Autopilot user group)[4].
This means if a user tries to Azure AD join a device that Intune doesn’t recognize as corporate, the enrollment will be refused. This is a good security measure, but it requires the next step (uploading corporate identifiers) to work smoothly with Autopilot v2.
5. Upload Corporate Device Identifiers: With personal devices blocked, you must tell Intune which devices are corporate. Since we are not pre-registering the full Autopilot hardware hash, Intune can rely on manufacturer, model, and serial number to recognize a device as corporate-owned during Autopilot v2 enrollment. To upload these identifiers:
Gather device info: For each new device, obtain the serial number, plus the manufacturer and model strings. You can get this from order information or by running a command on the device (e.g., on an example device, run wmic csproduct get vendor,name,identifyingnumber to output vendor (manufacturer), name (model), and identifying number (serial)[4]). Many OEMs provide this info in packing lists or you can scan a barcode from the box.
Prepare CSV: Create a CSV file with columns for Manufacturer, Model, Serial Number. List each device’s information on a separate line[4]. For example:\ Dell Inc.,Latitude 7440,ABCDEFG1234\ Microsoft Corporation,Surface Pro 9,1234567890\ (Use the exact strings as reported by the device/OEM to avoid mismatches.)
Upload in Intune: In the Intune admin center, go to Devices > Enrollment > Corporate device identifiers. Choose Add then Upload CSV. Select the format “Manufacturer, model, and serial number (Windows only)”[4] and upload your CSV file. Once processed, Intune will list those identifiers as corporate.
With this in place, when a user signs in on a device, Intune checks the device’s hardware info. If it matches one of these entries, it’s flagged as corporate-owned and allowed to enroll despite the personal device block[4][4]. If it’s not in the list, the enrollment will be blocked (the user will get a message that enrolling personal devices is not allowed). Important: Until you have corporate identifiers set up, do not enable the personal device block, or Autopilot device preparation will fail for new devices[6][6]. Always upload the identifiers first or simultaneously.
At this stage, you have completed the Intune configuration for Autopilot v2. You have:
A user group allowed to use Autopilot.
A device preparation profile linking that user group to a device group, with chosen settings and apps.
Required apps assigned to deploy.
Optional restrictions in place to ensure only known devices will enroll.
4.3 Enrollment and Device Setup Process (Using Autopilot v2)
With the above configuration done, the actual device enrollment process is straightforward for the end-user. Here’s what to expect when adding a new device to your Microsoft 365 environment via Autopilot v2:
Out-of-Box Experience (Initial Screens): When the device is turned on for the first time (or after a factory reset), the Windows OOBE begins. The user will select their region and keyboard (unless the profile pre-configured these). The device will prompt for a network connection. The user should connect to the internet (Ethernet or Wi-Fi). Once connected, the device might check for updates briefly, then reach the “Sign in” screen.
User Sign-In (Azure AD): The user enters their work or school (Microsoft Entra ID/Azure AD) credentials – i.e., their Microsoft 365 Business account email and password. This is the trigger for Autopilot Device Preparation. Upon signing in, the device joins your organization’s Azure AD. Because the user is in the “Autopilot Users” group and an Autopilot Device Preparation profile is active, Intune will now kick off the device preparation process in the background.
Device Preparation Phase (ESP): After credentials are verified, the user sees the Enrollment Status Page (ESP) which now reflects “Device preparation” steps. In Autopilot v2, the ESP will show the progress of the configuration. A key difference in v2 is the presence of a percentage progress indicator that gives a clearer idea of progress[6]. Behind the scenes, several things happen:
The device is automatically added to the specified Device group (“Autopilot Device Preparation – Devices”) in Azure AD[5]. The “Intune Provisioning Agent” does this within seconds of the user signing in.
Intune immediately starts deploying the selected applications and PowerShell scripts to the device (those that were marked for installation during OOBE). The ESP screen will typically list the device setup steps, which may include device configuration, app installation, etc. The apps you marked as required (Company Portal, Office, etc.) will download and install one by one. Their status can often be viewed on the screen (e.g., “Installing Office 365… 50%”).
Any device configuration policies assigned to the device group (e.g., configuration profiles or compliance policies you set to target that group) will also begin to apply. Note: Autopilot v2 does not pause for all policies to complete; it mainly ensures the selected apps and scripts complete. Policies will apply in parallel or afterwards without blocking the ESP[3].
If you enabled BitLocker or other encryption policies, those might kick off during this phase as well (depending on your Intune configuration for encryption on Azure AD join).
The user remains at the ESP screen until the critical steps finish. With the 10-app limit and no dynamic group delay, this phase should complete relatively quickly (typically a few minutes to perhaps an hour for large Office downloads on slower connections). The progress bar will reach 100%.
Completion and First Desktop Launch: Once the selected apps and scripts have finished deploying, Autopilot signals that device setup is complete. The ESP will indicate it’s done, and the user will be allowed to proceed to log on to Windows (or it may automatically log them in if credentials were cached from step 2). In Autopilot v2, a final screen can notify the user that critical setup is finished and they can start using the device[6]. The user then arrives at the Windows desktop.
Post-Enrolment (Background tasks): Now the device is fully Azure AD joined and enrolled in Intune as a managed device. Any remaining apps or policies that were not part of the initial device preparation will continue to install in the background. For example, if you targeted some less critical user-specific apps (say, OneDrive client or Webex) via user groups, those will download via Intune management without interrupting the user. The user can begin working, and they’ll likely see additional apps appearing or software finishing installations within the first hour of use.
Verification: The IT admin can verify the device in the Intune portal. It should appear under Devices with the user assigned, and compliance/policies applying. The Autopilot deployment report in Intune will show this device’s status as successful if all selected apps/scripts succeeded, or flagged if any failures occurred[5]. The user should see applications like Office, Teams, Outlook, and the Company Portal already installed on the Start Menu[4]. If all looks good, the device is effectively ready and managed.
4.4 Troubleshooting Common Issues in Autopilot v2
While Autopilot v2 is designed to be simpler and more reliable, you may encounter some issues during setup. Here are common issues and how to address them:
Device is blocked as “personal” during enrollment: If you enabled the enrollment restriction to block personal devices, a new device might fail to enroll at user sign-in with a message that personal devices are not allowed. This typically means Intune did not recognize the device as corporate. Ensure you have uploaded the correct device serial, model, and manufacturer under corporate identifiers before the user attempts enrollment[4]. Typos or mismatches (e.g., “HP Inc.” vs “Hewlett-Packard”) can cause the check to fail. If an expected corporate device was blocked, double-check its identifier in Intune and re-upload if needed, then have the user try again (after a reset). If you cannot get the identifiers loaded in time, you may temporarily toggle the restriction to allow personal Windows enrollments to let the device through, then re-enable once fixed.
Autopilot profile not applying (device does standard Azure AD join without ESP): This can happen if the user is not in the group assigned to the Autopilot Device Prep profile, or if the device was already registered with a classic Autopilot profile. To troubleshoot:
Verify that the user who is signing in is indeed a member of the Autopilot Users group that you targeted. If not, add them and try again.
Check Intune’s Autopilot devices list. If the device’s hardware hash was previously imported and has an old deployment profile assigned, the device might be using Autopilot v1 behavior (which could skip the ESP or conflict). Solution: Remove the device from the Autopilot devices list (deregister it) so that v2 can proceed[5].
Also ensure the device meets OS requirements. If someone somehow tried with an out-of-date Windows 10, the new profile wouldn’t apply.
One of the apps failed to install during OOBE: If an app (or script) that was selected in the profile fails, the Autopilot ESP might show an error or might eventually time out. Autopilot v2 doesn’t explicitly block on policies, but it does expect the chosen apps to install. If an app installation fails (perhaps due to an MSI error or content download issue), the user may eventually be allowed to log in, but Intune’s deployment report will mark the deployment as failed for that device[5]. Use the Autopilot deployment report in Intune to see which app or step failed[5]. Then:
Check the Intune app assignment for that app. For instance, was the app installer file reachable and valid? Did it have correct detection rules? Remedy any packaging error.
If the issue was network (e.g., large app timed out), consider not deploying that app during OOBE (remove it from the profile’s selected apps so it installs later instead).
The user can still proceed to work after skipping the failed step (in many cases), but you’ll want to push the necessary app afterward or instruct the user to install via Company Portal if possible.
User sees unexpected OOBE screens (e.g., personal vs organization choice): As noted, Autopilot v2 can show some default Windows setup prompts that classic Autopilot hid. For example, early in OOBE the user might be asked “Is this a personal or work device?” If they see this, they should select Work/School (which leads to the Azure AD sign-in). Similarly, the user might have to accept the Windows 11 license agreement. To avoid confusion, prepare users with guidance that they may see a couple of extra screens and how to proceed. Once the user signs in, the rest will be automated. In future, after the device prep profile applies, those screens might not appear on subsequent resets, but on first run they can. This is expected behavior, not a failure.
Autopilot deployment hangs or takes too long: If the process seems stuck on the ESP for an inordinate time:
Check if it’s downloading a large update or app. Sometimes Windows might be applying a critical update in the background. If internet is slow, Office download (which can be ~2GB) might simply be taking time. If possible, ensure a faster connection or use Ethernet for initial setup.
If it’s truly hung (no progress increase for a long period), you may need to power cycle. The good news is Autopilot v2 is resilient – it has more retry logic for applying the profile[8]. On reboot, it often picks up where it left off, or attempts the step again. Frequent hanging might indicate a problematic step (again, refer to Intune’s report).
Ensure the device’s time and region were set correctly; incorrect time can cause Azure AD token issues. Autopilot v2 does try to sync time more reliably during ESP[8].
Post-enrollment policy issues: Because Autopilot v2 doesn’t wait for all policies, you might notice things like BitLocker taking place only after login, or certain configurations applying slightly later. This is normal. However, if certain device configurations never apply, verify that those policies are targeted correctly (likely to the device group). If they were user-targeted, they should apply after the user logs in. If something isn’t applying at all, treat it as a standard Intune troubleshooting case (e.g., check for scope tags, licensing, or conflicts).
Overall, many issues can be avoided by testing Autopilot v2 on a pilot device before mass rollout. Run through the deployment yourself with a test user and device to catch any application installation failures or unexpected prompts, and adjust your profile or process accordingly.
5. Best Practices for Maintaining and Managing Autopilot v2 Devices
After deploying devices with Windows Autopilot Device Preparation, your work isn’t done – you’ll want to manage and maintain those devices for the long term. Here are some best practices to ensure ongoing success:
Establish Clear Autopilot Processes: Because Autopilot v2 and v1 may coexist (for different use cases), document your process. For example, decide: will all new devices use Autopilot v2 going forward, or only certain ones? Communicate to your procurement and IT teams that new devices should not be registered via the old process. If you buy through an OEM with Autopilot registration service, pause that for devices you’ll enroll via v2 to avoid conflicts.
Keep Windows and Intune Updated: Autopilot v2 capabilities may expand with new Windows releases and Intune updates. Ensure devices get Windows quality updates regularly (this keeps the Autopilot agent up-to-date and compatible). Watch Microsoft Intune release notes for any Autopilot-related improvements or changes. For instance, if/when Microsoft enables features like self-deploying or hybrid join in Autopilot v2, it will likely come via an update[6] – staying current allows you to take advantage.
Limit and Optimize Apps in the Profile: Be strategic about the apps you include during the autopilot phase. The 10-app limit forces some discipline – include only truly essential software that users need immediately or that is required for security/compliance. Everything else can install later via normal Intune assignment or be made available in Company Portal. This ensures the provisioning is quick and has fewer chances to fail. Also prefer Win32 packaged apps for reliability and to avoid Windows Store dependencies during OOBE[2]. In general, simpler is better for the OOBE phase.
Use Device Categories/Tags if Needed: Intune supports tagging devices during enrollment (in classic Autopilot, there was “Convert all targeted devices to Autopilot” and grouping by order ID). In Autopilot v2, since devices aren’t pre-registered, you might use dynamic groups or naming conventions post-enrollment to organize devices (e.g., by department or location). Consider leveraging Azure AD group rules or Intune filters if you need to deploy different apps to different sets of devices after enrollment.
Monitor Deployment Reports and Logs: Take advantage of the new Autopilot deployment report in Intune for each rollout[5]. After onboarding a batch of new devices, review the report to see if any had issues (e.g., maybe one device’s Office install failed due to a network glitch). Address any failures proactively (rerun a script, push a missed app, etc.). Additionally, know that users or IT can export Autopilot logs easily from the device if needed[5] (there’s a troubleshooting option during the OOBE or via pressing certain key combos). Collecting logs can help Microsoft support or your IT team diagnose deeper issues.
Maintain Corporate Identifier Lists: If you’re using the corporate device identifiers method, keep your Azure AD device inventory synchronized with Intune’s list. For every new device coming in, add its identifiers. For devices being retired or sold, you might remove their identifiers. Also, coordinate this with the enrollment restriction – e.g., if a top executive wants to enroll their personal device and you have blocking enabled, you’d need to explicitly allow or bypass that (possibly by not applying the restriction to that user or by adding the device as corporate through some means). Regularly update the CSV as you purchase hardware to avoid last-minute scrambling when a user is setting up a new PC.
Plan for Feature Gaps: Recognize the current limitations of Autopilot v2 and plan accordingly:
If you require Hybrid AD Join (joining on-prem AD) for certain devices, those devices should continue using the classic Autopilot (with hardware hash and Intune Connector) for now, since v2 can’t do it[3].
If you utilize Autopilot Pre-Provisioning (White Glove) via IT staff or partner to pre-setup devices before handing to users (common for larger orgs or complex setups), note that Autopilot v2 doesn’t support that yet[3]. You might use Autopilot v1 for those scenarios until Microsoft adds it to v2.
Self-Deploying Mode (for kiosks or shared devices that enroll without user credentials) is also not in v2 presently[3]. Continue using classic Autopilot with TPM attestation for kiosk devices as needed. It’s perfectly fine to run both Autopilot methods side-by-side; just carefully target which devices or user groups use which method. Microsoft is likely to close these gaps in future updates, so keep an eye on announcements.
End-User Training and Communication: Even though Autopilot is automated, let your end-users know what to expect. Provide a one-page instruction with their new laptop: e.g., “1) Connect to Wi-Fi, 2) Log in with your work account, 3) Wait while we set up your device (about 15-30 minutes), 4) You’ll see a screen telling you when it’s ready.” Setting expectations helps reduce support tickets. Also inform them that the device will be managed by the company (which is standard, but transparency helps trust).
Device Management Post-Deployment: After Autopilot enrollment, manage the devices like any Intune-managed endpoints. Set up compliance policies (for OS version, AV status, etc.), Windows Update rings or feature update policies to keep them up-to-date, and use Intune’s Endpoint analytics or Windows Update for Business reports to track device health. Autopilot has done the job of onboarding; from then on, treat the devices as part of your standard device management lifecycle. For instance, if a device is reassigned to a new user, you can invoke Autopilot Reset via Intune to wipe user data and redo the OOBE for the new user—Autopilot v2 will once again apply (just ensure the new user is in the correct group).
Continuous Improvement: Gather feedback from users about the Autopilot process. If many report that a certain app wasn’t ready or some setting was missing on first login, adjust your Autopilot profile or Intune assignments. Autopilot v2’s flexibility allows you to tweak which apps/scripts are in the initial provision vs. post-login. Aim to find the right balance where devices are secure and usable as soon as possible, without overloading the provisioning. Also consider pilot testing Windows 11 feature updates early, since Autopilot behavior can change or improve with new releases (for example, a future Windows 11 update might reduce the appearance of some initial screens in Autopilot v2, etc.).
By following these best practices, you’ll ensure that your organization continues to benefit from Autopilot v2’s efficiencies long after the initial setup. The result is a modern device deployment strategy with minimal hassle, aligned to the cloud-first, zero-touch ethos of Microsoft 365.
Conclusion: Microsoft Autopilot v2 (Windows Autopilot Device Preparation) represents a significant step forward in simplifying device onboarding. By leveraging it in your Microsoft 365 Business environment, you can add new Windows 11 devices with ease – end-users take them out of the box, log in, and within minutes have a fully configured, policy-compliant workstation. The latest updates bring more reliability, insight, and speed to this process, making life easier for IT admins and employees alike. By understanding the new features, following the implementation steps, and adhering to best practices outlined in this guide, you can successfully deploy Autopilot v2 and streamline your device deployment workflow[4][5]. Happy deploying!
CIAOPS 