Troubleshooting Windows Feature updates in Microsoft Intune
By: Luke Ramsdale – Sr Security Customer Escalation Engineer | Microsoft Intune Effectively managing feature updates for Windows devices is essential for maintaining system performance and security. This article focuses on the troubleshooting steps necessary to address common issues with feature update policies in Intune. The feature update policy in Intune allows you to choose the Windows feature update version that devices should stay on or update to. The process of managing feature updates on Windows 10 and 11 devices is done through a combination of update ring and feature update policies. Update ring policies utilize the Policy CSP - Update to configure the Windows devices with the desired settings. Note: The unified suite of Windows update tools is officially known as Windows Autopatch. For further details, please visit: Why Windows Autopatch is the smart update solution - Windows IT Pro Blog to learn more. Prerequisites The first step in troubleshooting feature updates is to ensure the prerequisites are in place. This is a crucial step to take to ensure a smooth feature update policy implementation; missing a prerequisite accounts for many feature update failures or undesirable behavior. Licenses The core functionality requires an Intune license, but it’s important to note that the cloud-based capabilities such as gradual rollout and optional feature updates require a license that includes access to the Windows Update for Business deployment service, for example: Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) Windows 10/11 Education A3 or A5 (included in Microsoft 365 A3 or A5) Windows Virtual Desktop Access E3 or E5 Microsoft 365 Business Premium For more information about gradual rollouts please refer to the following document: Configure schedules to gradually roll out Windows Updates in Intune Telemetry Ensure that a device restriction policy is deployed to all devices in scope for feature updates with reporting and telemetry configured. At minimum the Share usage data setting needs to be configured to “Required”. For more details on this setting, review: Device restriction settings for Windows 10/11 in Microsoft Intune Enable Windows diagnostic data collection Configuring diagnostic data collection is essential to ensure feature update reporting is accurate. This is a tenant wide setting and is configured in the Intune admin center under Tenant administration > Connectors and tokens > Windows data. For more information, review: Use Windows Update for Business reports for Windows Updates in Microsoft Intune Microsoft Account sign-in Assistant service Ensure the Microsoft Account sign-in Assistant service isn’t disabled, by default this is set to Manual. Connected User Experiences and Telemetry service Ensure the Connected User Experiences and Telemetry service is not disabled , by default this is set to Automatic. Supported version of Windows 10/11 The Windows operating system being updated must be either Professional, Enterprise or Education editions.editions. Network endpoints Ensure the devices can access the Intune and Windows update endpoints: Network endpoints for Microsoft Intune Connection endpoints for Windows 10, version 1809 - Windows Privacy Deploying feature update policies with update rings If you’re deploying update rings in parallel to feature update policies, then it is important to consider the implications of configuring certain settings in the update ring policy: Feature update deferral period (days) The recommendation is to configure this to ‘0’ but if you choose to change this it’ll delay the deployment of feature updates. Upgrade Windows 10 devices to Latest Windows 11 release If this option is configured to yes, then eligible Windows 10 devices will update to the latest Windows 11 feature update regardless of what is configured in any feature update policy. Note: It’s important to understand this update ring policy setting will overrule any Windows 10 feature update policy deployed. Paused feature updates If feature updates are paused in an update ring policy, then targeted devices won’t receive feature updates; ensure that feature updates are running for any update ring policies targeting users or devices that also have feature updates policies deployed. Conflicting feature update policies There are a couple of scenarios that are important to keep in mind when deploying feature update policies: Deploying multiple feature update policies to devices could target multiple versions of feature updates to a device at the same time. The latest feature update will always be offered to the device under these circumstances. An eligible Windows 10 device targeted with both Windows 10 and 11 feature update policies will update to Windows 11. Our recommendation is to target a single feature update policy per operating system version, in other words, one for Windows 10 and one for Windows 11 devices. We also recommended to deploy a new feature update policy per release, one policy for Windows 11 23H2 and a separate policy for Windows 11 24H2. In this scenario administrators remove the devices from the group targeted with Windows 11 23H2 and move them to a group targeted with the Windows 11 24H2 policy. Microsoft Entra hybrid joined devices When feature updates are failing to deploy to machines that are Microsoft Entra hybrid joined, it’s important to investigate whether there are any pre-existing group policy objects (GPOs) deployed via Active Directory Services. These can conflict with the settings configured in Intune in general and the feature updates specifically. There are a couple of ways to attempt to check and troubleshoot potential GPO conflicts: On a device you suspect has conflicts run the following at the command line as a local administrator: gpresult /v >c:\temp\gpo.txt Open the text file and examine the contents for group policies which are configuring Windows update settings or redirecting update scanning to WSUS servers. Consider configuring a scan source GPO to specify which sources should be used for each individual class of Windows update. For example, you can configure Feature Updates to use Windows Server Update Services (WSUS) and Quality Updates to use Windows Update as shown in the screenshot below. Configuring a scan source group policy can help ease the transition from an on premises managed environment and Intune. For more information about scan source group policy objects refer to Use Windows Update for Business and Windows Server Update Services (WSUS) together. Note: Using the GPO wins over the mobile device management (MDM) setting doesn’t work with Windows update policies. Safeguard holds A safeguard hold is a Windows function that prevents your device from receiving new feature updates. The Windows update service enforces a safeguard hold on a device when it determines that a feature update may have a negative impact on your device. Safeguard holds are applied when quality and compatibility data identify issues that might cause a Windows client feature update to fail or roll back. These holds can also be applied when a customer, partner, or internal validation finds an issue that would cause severe effects, such as data loss or loss of key functionality. The lifespan of a safeguard hold varies depending on the time required to investigate and fix the issue. Once a fix is found and verified, the safeguard hold is lifted, and Windows Update resumes offering new operating system versions to the affected devices It’s important to check the feature update failures report, which is mentioned in the next section. For more information on safeguard holds and Windows release health refer to: Safeguard holds for Windows Windows release health Troubleshooting Feature updates from the Intune admin center It’s important to enable the prerequisites for update reporting, there are two prerequisites which you must meet: Enable Windows diagnostic data collection from devices by configuring telemetry to be at least required. Configure the tenant level Windows data collection. Windows feature update report The Windows feature update report is a good starting point to get an overall status of the feature update deployment policy status. (Reports > Windows updates > Reports > Windows feature update report) This report runs on individual feature update policies and provides a summary and details of the feature update state. This report doesn’t automatically update and you need to generate it manually. The important data on this report is contained in the update state and update substate columns. If the update state is set to “Offering” and the update substate is set to “Offer ready”, then Windows update made the feature update available to the device. If the update state is “Pending” and update substate is “Scheduled”, then the update will be available for installation later. If it’s “Pending validation”, then there’s a problem validating the device by Windows update. Feature update failures report The first point of contact for troubleshooting feature updates should be the feature update failures report which is in the Intune admin center > Devices > Monitor > Feature update policies with alerts. This report shows you the reasons why individual devices have failed to install a feature update. Note: You need to configure the data collection pre-requisite discussed above before this report shows any data. This lists all the current feature update policies with an overview of the number of devices with errors. Clicking on the feature update policy will drill into the details and list the failures. This report should be the first place that an administrator checks to understand whether the feature update install has been attempted on a device and subsequently failed. For a full list of possible errors populated in this report and recommendations for remediation refer to:Use Windows Update for Business reports for Windows Updates in Microsoft Intune - Microsoft Intune. Checking the Windows update service using PowerShell It’s possible to interact with the Windows Autopatch service via graph explorer or via PowerShell cmdlets using Windows update APIs. The cmdlets are documented in Microsoft.Graph.Beta.WindowsUpdates Module and theGraph APIs are documented in Windows updates API overview. There is also a training course on how to manage updates using the SDK Manage Windows updates for cloud-connected devices by using the Microsoft Graph PowerShell SDK - Training. Administrators don’t need to use the SDK when deploying updates via Intune, but it can be used to investigate and troubleshoot deployment issues.deployment issues. The following is an example of how to request the properties of a Microsoft Entra device using the device identifier. You can view this record using a PowerShell cmdlet called: 'Get-MgBetaWindowsUpdatesUpdatableAsset' with the Microsoft Entra device id as a parameter, here is an example PowerShell script which gets the update information: Import-Module Microsoft.Graph.Beta.WindowsUpdates Connect-MgGraph $updateInfo = Get-MgBetaWindowsUpdatesUpdatableAsset -UpdatableAssetId '<insert Entra device id>' Write-Host "Update Information:`n$($updateInfo | ConvertTo-Json -Depth 10)" This is an example of the output where the feature update enrollment state is still “enrolling.” A Microsoft Entra ID device will need to be successfully enrolled into the Windows Autopatch service before it can start receiving the feature update policies. In this case the enrolling state could be caused if the feature update is paused in an update ring policy. Update Information: { "Id": "13315f1b-96b4-4a88-b453-342d984a6e05", "AdditionalProperties": { "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/updatableAssets/$entity", "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice", "errors": [], "enrollment": { "feature": { "enrollmentState": "enrolling", "lastModifiedDateTime": "2025-01-23T14:39:07.8854424Z" }, "quality": { "enrollmentState": "notEnrolled" }, "driver": { "enrollmentState": "enrolledWithPolicy", "lastModifiedDateTime": "2024-02-08T15:14:30.5073437Z" } } } } The ideal state is as follows; this shows the Microsoft Entra ID device is enrolled in the Windows Update for business service for feature updates. Note that the Entra ID enrollment into Windows Autopatch is distinct from enrolling a Windows device into Intune: Update Information: { "Id": "0dde8413-951b-4d95-b628-705881f4901b", "AdditionalProperties": { "@odata.context": "https://graph.microsoft.com/beta/$metadata#admin/windows/updates/updatableAssets/$entity", "@odata.type": "#microsoft.graph.windowsUpdates.azureADDevice", "errors": [ ], "enrollment": { "feature": { "enrollmentState": "enrolled", "lastModifiedDateTime": "2025-02-06T16:02:59.0065266Z" }, "quality": { "enrollmentState": "notEnrolled" }, "driver": { "enrollmentState": "enrolled", "lastModifiedDateTime": "2025-02-06T16:02:57.5209828Z" } } } } The enrollment state should equal enrolled if the device has a policy targeting one of the updates. Graph explorer The same principle can be used with graph explorer by navigating to https://developer.microsoft.com/graph/graph-explorer and querying the following: https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/<insert Microsoft Entra Device id> This returns the data associated with the asset in JSON format. In this example we see that the device is still enrolling for feature updates rather than enrolled. Note: When you create a feature update policy in Intune it will interact directly with Windows Update for Business using the documented Windows Autopatch APIs to configure the policies, however, these policies are not visible either though Graph or PowerShell. Troubleshooting Feature updates from the client side Device diagnostics The first step when troubleshooting feature updates from the client side is to get hold of the device side logs. Intune provides a way to gather logs from the device using the Intune admin center within device diagnostics. To ensure that device diagnostics is available in your tenant, navigate to Tenant admin > Device diagnostics and ensure that the options are enabled. Once enabled it’s possible to collect diagnostics from the device by navigating to the device overview page, Collect diagnostics. After a short period, the diagnostics will be available to download from the device diagnostics view on the device: For more information about device diagnostics please refer to Collect diagnostics from an Intune managed device - Microsoft Intune. Device diagnostic logs The device diagnostics feature in Intune gathers all the relevant MDM event logs along with other relevant data such as registry keys, log files, and commands. When troubleshooting feature updates, the key logs to investigate from the device diagnostics are the following: %windir%\logs\CBS\cbs.log The CBS, or component-based servicing, log gives detailed information on the installation of updates which relate to the component-based servicing system. This includes some aspects of the feature update install. If a feature update fails due to a missing or corrupted system component, the CBS.log may contain relevant errors. %windir%\logs\Panther\unattendgc\setupact.log Setupact.log contains detailed step by step records of the Windows setup process. This log contains the actions performed during a feature update installation and is useful for scenarios where the update is delivered to the device but has not installed correctly. SetupDiag is also available to download to help determine why upgrades fails for more information refer to: SetupDiag. %windir%\logs\WindowsUpdate\*.etl The Windows update log is useful for investigating issues with scanning, downloading, and installing updates. The etl files can be converted to a more friendly text log file using the PowerShell cmdlet Get-WindowsUpdateLog. For more information about troubleshooting via the Windows update logs refer to Windows Update log files. %temp%\MDMDiagnostics\mdmlogs-<Date/Time>.cab The mdmlogs cab is a diagnostic log package generated by the device diagnostics to capture all relevant MDM logs and compresses them into a cab file. The key logs and files for investigating feature updates are the MDM diagnostics report HTML file (which is discussed in detail below) and the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx. Checking the prerequisites via MDM diagnostics report Once the diagnostics are downloaded, the first step is to check that all the prerequisites for feature updates are satisfied. To do this unzip the DiagLogs zip file and search for a folder called: temp_MDMDiagnostics_mdmlogs, for example temp_MDMDiagnostics_mdmlogs-2025-01-28-16-51-20_cab, extract the files from the CAB file and search for the file MDMDiagHtmlReport.html. The MDM diagnostic information has a list of all the policies that are applied to the device from Intune, and in the case of feature updates, the following settings need to be deployed and configured on the device. Note that there are two columns for the values, the default Windows value and the current value which is configured by Intune. Here’s an example of how the policies look in the MDMDiagHtmlReport.html: Search this file for the CSP area, such as Update or DeviceHealthMonitoring as in the example below: These are the prerequisites areas, policies and settings that you should check: Area Policy Default Current Update DeferFeatureUpdatesPeriodInDays 0 0 Update ConfigureDeadlineForFeatureUpdates 7 10 Update PauseFeatureUpdates 0 0 DeviceHealthMonitoring AllowDeviceHealthMonitoring 0 1 DeviceHealthMonitoring ConfigDeviceHealthMonitoringScope BootPerformance, WindowsUpdates System AllowTelemetry 1 1 In this example the policy values equate to: Setting Value Description DeferFeatureUpdatesPeriodInDays 0 The number of days a feature update can be deferred, 0 days is recommended but this can be configured for up to 365 days. ConfigureDeadlineForFeatureUpdates 10 Number of days before the feature update is installed automatically, in this case 10 days. PauseFeatureUpdates 0 0 means that feature updates are not paused. 1 means that they are paused. AllowDeviceHealthMonitoring 1 1 means DeviceHealthMonitoring connection is enabled. ConfigDeviceHealthMonitoringScope BootPerformance and WindowsUpdates data are sent to Microsoft. AllowTelemetry 3 3 means that all telemetry data is being sent to help fix problems, 1 is basic. Basic is the minimum telemetry setting required for feature updates. If you want to understand these values further, refer to the CSP documentation: Policy CSP - Update Policy CSP - System Policy CSP - DeviceHealthMonitoring Verifying Intune policy is applied When a policy fails to apply on a device, the error returned from the CSP is reflected in the Intune admin center reports. For all CSPs, including the update, device health monitoring and system policy CSP, any errors that occur when applying the CSP settings appear in the microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin event log. To access this event log, you can either request the device diagnostics from a device and extract it from the zip file or access the event log directly on the device. To access this on a device, open the event viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Here is an example of an error in the DeviceManagement-Enterprise-Diagnostics-Provider admin event log from the WiFi CSP: The error is as follows: MDM ConfigurationManager: Command failure status. Configuration Source ID: (773B7171-7CB3-41CE-9480-64439F370613), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (WiFi), Command Type: (Add: from Replace or Add), CSP URI: (./Vendor/MSFT/WiFi/Profile/Danger Zone/WlanXml), Result: (The service has not been started.). In the above error, a Wifi profile has failed to be applied via the Add/Replace command. The ‘Result’ is the important part. This can take the form of a hex code, such as 0x86000009, or can be more meaningful as in the example above: “The service has not been started”. In this case the device is a virtual machine which has no WiFi adapter, so the service is not running. Update, System, and Device health monitoring CSP errors are not common, but it is important to understand how to investigate potential CSP errors. Check the registry The best method for checking the device side settings is to review the MDM diagnostics report that can be collected using device diagnostics as described above. The diagnostics report reflects the settings configured in the registry. It’s also possible to check the prerequisites and the update settings in the registry. This helps verify the settings are configured as per the policies in Intune. Safeguard holds Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TargetVersionUpgradeExperienceIndicators This key specifically is related to Windows feature updates and tracks information about how a system is expected to behave during an upgrade to a newer Windows version. The GE24H2 subkey in the above screenshot refers to Windows 11 24H2 and the values in this subkey help assess whether the device is ready for the update. Telemetry settings Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection This location is where Windows stores telemetry specific settings, the value should either be 1 (Basic) or 3 (Full). In this screenshot, the AllowTelemetry_PolicyManager value shows 3 which means “Full”. Device health monitoring Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceHealthMonitoring The device health monitoring settings highlighted in red below are required for various update reports in the Intune admin center. Make sure the WindowsUpdates setting is present for ConfigDeviceHealthMonitoringScope and AllowDeviceHealthMonitoring is set to 1 (enabled). Reviewing these registry entries is useful for verifying the settings have applied successfully, editing the values directly in the registry has no impact on functionality. Note: If the administrator has configured the tenant wide Windows data settings in Tenant administration > Connectors and token > Windows data, the Windows update scope entry will not be present. This is only present when deploying the health monitoring settings via a device configuration profile: Use Windows Health Monitoring profile on Windows devices in Microsoft Intune. Update settings Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update This key contains all the update CSP settings which are configured by the update policies. This includes feature, quality, driver, and update ring settings. There are potentially many settings in this key and they vary depending on the settings configured in the policies configured in Intune. To understand what these settings mean refer to: Update Policy CSP. Microsoft Compatibility Appraiser The Microsoft Compatibility Appraiser is a built-in Windows telemetry component that evaluates the compatibility of installed software and hardware in Windows. It runs as part of the Windows Compatibility Telemetry process. Windows uses Microsoft Compatibility Appraiser for reporting and telemetry and is a key component for the Intune feature update reports. You configure Intune to leverage this tool using the Windows data tenant wide setting as described previously in the prerequisites section. In some circumstances where devices show up as unknown in the Intune update reports, it’s useful to attempt to trigger Microsoft Compatibility Appraiser manually to force the device to report back telemetry data. To do this you can either manually run a scheduled task on the device or execute it using PowerShell or the command line. Manually running the scheduled task Navigate to the start menu > type “task scheduler” and open the task scheduler > navigate to Microsoft > Windows > Application Experience > Microsoft Compatibility Appraiser Exp> right click > Run. Running the appraiser at the command line The task above runs a command which you can also execute manually or script it to run on many machines: Compattelrunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun Both methods will trigger Microsoft Compatibility Appraiser to report the required telemetry data and update the Windows update reports. Summary This blog covered many aspects of troubleshooting feature updates, here are the key points: Make sure the prerequisites are in place. It’s important to emphasize that implementing the prerequisites for feature updates is important to ensuring a smooth feature update deployment. Take time to ensure that these are configured correctly as this is especially important for reporting. In more complex environments with Microsoft Entra hybrid joined devices, it’s important to ensure that there are no conflicting settings deployed from multiple sources, for example, having GPO settings, Microsoft Configuration Manager update policies, and conflicting Intune update policies deployed. Try to ensure that update policies are deployed from only one source. If multiple sources must be used, consider using the scan source group policy. It’s possible to interact with Windows Autopatch using PowerShell cmdlets and Graph APIs. This provides insight into a tenant's configuration, but it’s not a requirement as Intune will configure this for you using feature update and update ring policies. Note: It’s also important to understand that the Intune configured Windows Update client policies will not be visible via the PowerShell cmdlets or Graph APIs. Take note of whether safeguard holds are applied to specific device models, checking the feature update failures report will assist with identifying these. The device side event logs, Windows update logs, MDM diagnostics report, and registry values are all important sources for trying to narrow down why a device isn’t installing a feature update, or if a feature update was unexpectedly not installed or installed. Collecting diagnostics from affected devices will gather the relevant logs and data required for troubleshooting, this is important to gather if a support request is opened. Hopefully these tips help you with troubleshooting feature updates! If you have any questions, leave a comment on this post or reach out on X @IntuneSuppTeam. Post update: 04/10/25: Added link to: Why Windows Autopatch is the smart update solution - Windows IT Pro Blog.Configure the new Microsoft Intune connector for Active Directory with the least privilege principle
By: Arpit Sinha | Support Escalation Engineer – Microsoft Intune The purpose of the Microsoft Intune Connector for Active Directory, also known as the Offline Domain Join (ODJ) Connector, is to join computers to an on-premises domain during the Windows Autopilot process with the device ultimately becoming Microsoft Entra hybrid joined after the user logs into the device for the first time. The Intune Connector for Active Directory creates computer objects in a specified Organizational Unit (OU) in Active Directory during the domain join process. Important Note: Although fully supported, performing hybrid join during Windows Autopilot isn’t recommended as it can be difficult to configure, troubleshoot, and support over time. For additional information on this topic refer to Join your cloud-native endpoints to Microsoft Entra and the blog, Success with remote Windows Autopilot and hybrid Azure Active Directory join. Earlier this year, Intune released an updated Intune Connector for Active Directory that strengthens security and follows least privilege principles by using a Managed Service Account (MSA). As communicated in both the blog and Message Center, as started in July 2025, older versions of the connector will cease to operate successfully. Below are the useful steps you should follow while configuring the updated Intune Connector for Active Directory: Sign in to the Intune Connector for Active Directory Verify the Intune Connector for Active Directory is active Configure the MSA to allow creating objects in OUs (optional) Error when granting permissions to MSA account An issue that a small number of customers may experience during the connector installation is the inability for the installation process to grant the MSA account the necessary permissions on the default computers container or a specific organizational unit. The below screenshot shows the error message displayed when you encounter this error during installation. The installation log is named odjconnectorUI.txt, located in C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard, and shows the following when you encounter this error: Unknown error: System.DirectoryServices.DirectoryServicesCOMException (0x8007202F): A constraint violation occurred. Workaround and walk through To workaround the above issue, the following is a walkthrough for successfully installing the connector and the steps required to handle the MSA permission error. Follow the Install the Intune Connector for Active Directory on the server guidance to setup the new ODJ connector. You need to initiate the installation with an account that has the following rights: Create msDs-ManagedServiceAccount objects in the Managed Service Accounts container (domain rights) Local administrator on your Windows Server After successful installation and Microsoft Entra sign in (using an Intune Admin or Global Admin account), you’ll get the below confirmation screen in the Intune Connector for Active Directory showing that the connector is successfully enrolled and that an MSA account was successfully created. After selecting on ‘Ok’ in the above confirmation screen, wait a few seconds, and you might receive the error that mentions the MSA account 'could not be granted permission' and will show the MSA name which was created as highlighted in the below screenshot. Note the name of the MSA account as this is needed in a below step. Note: If setup is complete and successful, it won’t throw the above error. If the dialog is closed, go to location ‘C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard’ and relaunch ‘ODJConnectorEnrollmentWizard.exe’. Verify that the connector installation successfully created the MSA in Manager Service Account container in the Active Directory User and Computers console. Note that you must enable Advanced Features in the View menu to show this container. Validate that the 'Intune ODJ connector service' is Running with an Automatic Startup Type and with 'Log on As' use the MSA account configured during the connector’s installation only. As shown in the following example screenshot. Verify in the Intune admin center under Device > Enrollment > Intune Connector for Active Directory that the connector is Active. Note: Inactive connectors in the Intune Connector for Active Directory page will automatically be cleaned up after 30 days. Grant the Create Computer objects permission to the MSA account created by the connector installation on the organization unit or container that you configured the connector to use. This is best done using the Delegation of Control Wizard in the Active Directory User and Computers console. The following screenshot shows the end result. Note: Selecting ‘Configure Managed Service Account’ again will still result in the same permissions error. This is a known issue that can be ignored and will be addressed in the next released build of the connector.You can now proceed with provisioning devices using Autopilot. Look for the following event log events in Event Viewer on the server hosting the connector to validate correct functionality: Event Log Event Application and Services Logs > Microsoft > Intune > ODJConnectorService > Admin Event ID 30120 (successful Event) Application and Services Logs > Microsoft > Intune > ODJConnectorService > Operational Event ID 30130 and 30140 (successful Events) Summary Ensure that you’ve updated to the new connector as old versions will stop working. Additionally, ensure that the Managed Service Account has the correct permissions on the designated organizational unit. This is essential for the smooth operation of the Intune Connector for Active Directory. While you may encounter an error when selecting "Configure Managed Service Account", this can typically be safely ignored during initial setup. To confirm that the connector is functioning correctly and that devices can be provisioned through Autopilot without issues, monitor the event logs under the Intune ODJConnectorService. These logs provide critical insight into the provisioning process and helps validate successful connector enrollment and operation. Related information: Enrollment for Microsoft Entra hybrid joined devices Plan for Change: New Intune connector for deploying Microsoft Entra hybrid joined devices using Windows Autopilot Microsoft Intune Connector for Active Directory security update If you have any questions or want to share how you’re managing your Windows Autopilot devices with Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn.Security baseline for Windows Server 2025, version 2506
Microsoft is pleased to announce the June 2025 revision of the security baseline package for Windows Server 2025 (v2506)! You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Starting with this release, we plan to revise the Windows Server baseline more frequently to keep pace with evolving threats, new Windows features, and community feedback. Summary of Changes in This Release (v2506) This release includes several changes made since the last release of the security baseline for Windows Server 2025 in January 2025 to further assist in the security of enterprise customers along with better aligning with the latest standards. The changes include what is now depicted in the table below. Security Policy Change Summary Deny log on through Remote Desktop Services Allow remote logon for non-admin local accounts on MS and add “BUILTIN\Guests” to both DC and MS. WDigest Authentication Remove from the baseline Allow Windows Ink Workspace Remove from the baseline Audit Authorization Policy Change Set to “Success” in both DC and MS Include command line in process creation events Enable in both DC and MS Control whether exclusions are visible to local users Moved to Not Configured as it is overridden by the parent setting. Deny log on through Remote Desktop Services We updated SeDenyRemoteInteractiveLogonRight on member servers to use S-1-5-114 (Local account and member of Administrators group) instead of S-1-5-113 (all local accounts) to strike a better balance between security and operational flexibility. This change continues to block remote RDP access for high-risk local admin accounts—our primary threat vector—while enabling legitimate use cases for non-admin local accounts, such as remote troubleshooting and maintenance during failover or domain unavailability. By allowing non-admin local accounts to log on interactively, we preserve a secure recovery path without weakening protection for privileged accounts. In addition, to strengthen the Remote Desktop Services (RDS) posture on both Windows Server 2025 Domain Controllers and Member Servers, we added the Guests group to the "Deny log on through Remote Desktop Services" policy. While the Guest account is disabled by default, explicitly denying its RDP access adds a defense-in-depth measure that helps prevent misuse if the group is ever enabled or misconfigured. This complements the existing restriction on Local Account logon for DCs and helps ensure a consistent security posture across server roles. WDigest Authentication We removed the policy "WDigest Authentication (disabling may require KB2871997)" from the security baseline because it is no longer necessary for Windows Server 2025. This policy was originally enforced to prevent WDigest from storing users plaintext passwords in memory, which posed a serious credential theft risk. However, starting with 24H2 update (KB5041160) for Windows Server 2022 and continuing into Windows Server 2025, the engineering teams have deprecated this policy. As a result, there is no longer a need to explicitly enforce this setting, and the policy has been removed from the baseline to reflect the current default behavior. Allow Windows Ink Workspace We removed the policy “Allow Windows Ink Workspace” from the Windows Server 2025 security baseline. This policy applies only to Windows client editions and is not available on Windows Server. Including it in the baseline caused confusion removing an unnecessary setting from the baseline reduces GPO processing time and helps ensure all recommended settings are applicable for the Windows Server environment. Audit Authorization Policy Change We set Audit Authorization Policy Change (Success) on the baseline for both Domain Controllers and Member Servers to ensure visibility into any changes that affect the system’s security posture, including modifications to user rights and audit policies. These changes directly impact how access is granted and how activity is monitored, making them critical to detect for both security and compliance purposes. Logging successful changes helps identify misconfigurations, unauthorized privilege assignments, or malicious tampering — especially in cases of lateral movement or privilege escalation. Because these events occur infrequently, they generate minimal log volume while offering high forensic and operational value. While Failure auditing is not set, it is available as an optional setting on both Domain Controllers and Member Servers for organizations that have the monitoring capability to interpret and act on failed attempts to modify security policies. This provides an added layer of visibility in high-assurance or tightly controlled environments. Include command line in process creation events We added Include command line in process creation events in the baseline to improve visibility into how processes are executed across the system. Capturing command-line arguments allows defenders to detect and investigate malicious activity that may otherwise appear legitimate, such as abuse of scripting engines, credential theft tools, or obfuscated payloads using native binaries. This setting supports modern threat detection techniques with minimal performance overhead and is widely recommended. Visibility of Microsoft Defender Antivirus Exclusions We updated the configuration for the policy "Control whether exclusions are visible to local users" (Computer Configuration\Windows Components\Microsoft Defender Antivirus) to Not Configured in this release. This change was made because the parent policy "Control whether or not exclusions are visible to Local Admins" is already set to Enabled, which takes precedence and effectively overrides the behavior of the former setting. As a result, explicitly configuring the child policy is unnecessary and may introduce confusion without impacting actual behavior. You can continue to manage exclusion visibility through the parent policy, which provides the intended control over whether local administrators can view exclusion lists. UEFI Lock and Virtualization-Based Protections In Windows, some security features are protected by Secure Boot and the TPM. When combined with firmware protections that lock UEFI configuration variables, these protections become tamper-resistant: Windows can detect and respond to unauthorized hardware changes or tamper attempts, making it significantly harder for attackers to disable key security features after deployment. In the Windows Server 2025 security baseline, two policy categories are configured to take advantage of UEFI lock: Virtualization-Based Security (VBS) — managed via the policy: System\Device Guard\Turn On Virtualization Based Security Local Security Authority (LSA) Protection — managed via the policy: System\Local Security Authority\Configure LSASS to run as a protected process While there are no changes to the recommended settings for these policies in this release, we want to highlight their role in strengthening system defenses and provide guidance to help you make informed deployment decisions. UEFI lock enforces these protections in a way that prevents local or remote tampering—even by administrators. This aligns with strong security requirements in sensitive or high-assurance environments. However, it also introduces important operational considerations: Some hardware platforms may not fully support UEFI lock Compatibility issues, reduced performance, or system instability may occur Once enabled, UEFI lock is difficult to reverse Please let us know your thoughts by commenting on this post or through the Security Baseline Community.Support tip: Understanding Microsoft Intune compliance policies reporting SyncML(500) errors
By: Brett Lock - Sr. Tech Support Engineer | Microsoft Intune When deploying Windows device compliance policies with Microsoft Intune, the compliance report may show the following error for the Firewall settings (as depicted in the screenshot below): “2016345612(Syncml(500): The recipient encountered an unexpected condition which prevented it from fulfilling the request.)” Example screenshot of a Windows device compliance policy displaying the SyncML(500) error. The Syncml(500) error for the Firewall setting typically occurs during device startup, if or when the mobile device management (MDM) agent service starts before the firewall or antivirus services have fully initialized. In this scenario, the MDM agent reports a “service not started state” back to Intune which appears as the Syncml(500) error in the report. This is normal and expected. This error is temporary and doesn’t affect the compliance state of the device, unless the device doesn’t synchronize with the Intune service. The compliance service provides a 7-day grace period for devices with this error, marking them non-compliant if no sync occurs within that timeframe. In most cases, the error is resolved within 10 minutes after the user has logged on however, manual synchronization may be needed. On the device, navigate to Settings > Accounts > Access work or school > Account > Info > Sync to clear the error or run a compliance check from the Intune Company Portal app. Alternatively, admins can remotely sync the device from the Intune admin center through the device actions to achieve this (Devices > Windows > select the device > Overview > Sync). We’ve recently improved how Intune reports compliance states which minimizes the occurence of the Syncml 500 error. However, this error can still occur, and it’s important to understand that the error is expected if the MDM service starts up before the firewall and antivirus services initialize. In summary, the Syncml(500) error won’t impact the device compliance status during the 7 day grace period. If the device is immediately switched off after the error occurs and left for seven days, then this will impact the device compliance state. To resolve a non-compliant device in this scenario simply turn the device back on and sync once the user is logged on. If you have any questions for the team, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn: aka.ms/IntuneLinked.
