Microsoft has quietly broken a critical MSP workflow with Windows 11 24H2. The traditional method of using provisioning packages to skip OOBE screens during Windows resets no longer functions, forcing manual intervention where none was previously required.

What Used to Work

For years, MSPs relied on a elegant solution for remote Windows resets:

1. Place a provisioning package containing RMM agent installer at C:\Recovery\Customizations\test.ppkg
2. Create C:\Recovery\Customizations\InstallOrder.ini pointing to the package
3. User performs Windows Reset → “Remove everything” → “Local reinstall”
4. System skips OOBE screens automatically
5. Machine boots to desktop with RMM access restored

This workflow enabled MSPs to completely wipe and reload Windows machines remotely without losing access or requiring on-site intervention.

What Microsoft Changed

Starting with Windows 11 22H2 and confirmed in 24H2, Microsoft fundamentally altered how provisioning packages apply during the reset process:

Old Behavior: Provisioning packages applied before OOBE, allowing OOBE skip settings to function

New Behavior: Provisioning packages applied after reset completion but before first user login, making OOBE skip settings ineffective

The evidence is clear in setup logs:

2025-07-22 09:48:19, Info DISM: Process package type CommonSettings successfully  
2025-07-22 09:51:12, Info SYSPRP: Provisioning packages are applied successfully

The package applies successfully, but the timing change renders OOBE skip configurations useless.

Why Traditional Workarounds Fail

OEM Extensibility Scripts Don’t Execute

Microsoft’s built-in provisioning system now takes precedence over OEM extensibility frameworks. Custom ResetConfig.xml scripts that previously ran during reset are completely bypassed.

Testing revealed no evidence of custom scripts executing during the reset process, despite proper configuration in the recovery environment.

Recovery Image Customization Ignored

Even embedding provisioning packages directly into the Windows Recovery Environment (winre.wim) fails to restore the previous behavior. Windows applies its own built-in provisioning logic regardless of custom recovery modifications.

DISM Commands Don’t Execute

Custom wrapper scripts designed to apply provisioning packages via DISM during reset phases show no execution evidence in system logs, confirming Microsoft’s override of the traditional extensibility system.

Microsoft’s Strategic Intent

This change aligns with Microsoft’s push toward cloud-based device management:

• Force Modern Management: Eliminate traditional bypass methods
• Drive Intune Adoption: Push enterprises toward Microsoft’s cloud services
• Ensure Connectivity: Require network connection and account creation
• Secure by Default: Implement mandatory security updates during OOBE

Microsoft’s OOBE update KB5048779 explicitly states: “Critical driver updates, and critical Windows zero-day patch (ZDP) updates, will begin downloading automatically during OOBE after the user has connected to a network. The user can’t opt-out.”

Impact on MSP Operations

What Still Works

• Fresh installations with unattend.xml (new deployments only)
• USB provisioning packages during OOBE (requires manual intervention)
• Autopilot/Intune workflows (Microsoft’s preferred path)

What’s Broken

• Remote Windows reset capabilities
• Automated kiosk deployment workflows
• Traditional enterprise OOBE skipping
• Any provisioning package-based OOBE automation

Business Consequences

Manual Intervention Required: Technicians must now complete OOBE screens manually, adding time and complexity to previously automated workflows.

Lost Remote Access: During reset-to-reimage workflows, MSPs lose the ability to maintain remote connectivity without manual OOBE completion.

Increased Deployment Time: What was once a fully automated process now requires human interaction at each reset.

Training Requirements: Teams must learn new procedures and adjust expectations around remote capabilities.

Community Confirmation

Multiple Microsoft Q&A forum posts confirm widespread impact:

• “same ppkg packages work to enroll 22h1 devices but fail when trying with 22h2”
• “It seems that HideOOBE parameters has not effect from 22H2”
• “HideLocalAccountScreen setting…its not working on 24H2”

The consistent theme: traditional OOBE bypass methods stopped working starting with 22H2 and are definitively broken in 24H2.

The Path Forward

Microsoft has effectively eliminated the traditional provisioning package workflow for remote resets. Organizations have three options:

1. Accept Manual OOBE: Adapt workflows to include manual intervention
2. Adopt Intune/Autopilot: Migrate to Microsoft’s cloud-based management
3. Maintain Legacy Systems: Avoid Windows 11 24H2 deployment

For MSPs serving smaller clients without Enterprise licensing, option 1 represents the most realistic path forward, despite the operational impact.

Technical Details

This conclusion stems from comprehensive testing on Dell Latitude systems with Windows 11 Pro 24H2 (Build 26100.4061), including:

• Recovery environment customization attempts
• OEM extensibility script integration
• Log analysis confirming provisioning package application timing
• Community report verification across multiple hardware platforms

The evidence consistently shows that Microsoft’s built-in systems now override traditional customization methods, making OOBE skip settings ineffective regardless of implementation approach.

Windows 11 24H2 represents a fundamental shift in Microsoft’s approach to device provisioning, prioritizing cloud connectivity and security over traditional automation workflows. MSPs must adapt their procedures accordingly.