Microsoft Intune Connector for Active Directory security update
As part of Microsoft’s Secure Future Initiative, we’re making an important security change which will impact customers deploying Microsoft Entra hybrid joined devices with Windows Autopilot and provide guidance on how to prepare. New capabilities or improvements aren’t planned as part of this security change. Review Microsoft’s recommendations based on your organization’s needs. Updated connector Today, Windows Autopilot uses the Intune Connector for Active Directory to deploy devices that are Microsoft Entra hybrid joined. To strengthen security in our customers’ environments, we’ve updated the Intune Connector for Active Directory to use a Managed Service Account (MSA) instead of a SYSTEM account. The old connector which uses the local SYSTEM account will no longer be available for download in Intune and will stop being supported in late May 2025. At that point, we’ll stop accepting enrollments from the old connector build. Follow the guidance provided below to update your environment to the new connector. The old connector build will continue to work for existing customers who already have it installed until the end of support date and is available for download in the Microsoft Download Center if needed. What is a Managed Service Account (MSA)? MSAs are managed domain accounts that have automatic password management and are generally granted just enough permissions and privileges to perform their duties. Standalone MSAs can only be used on a single domain joined machine and can only access resources within that domain. An MSA can run services on a computer in a secure and easy to maintain manner, while maintaining the capability to connect to network resources as a specific user principal. All these reasons make them a better fit for the Intune Connector for Active Directory than the current SYSTEM account option. Comparing the account permissions required between the new and old connector Old Connector New Connector Logged on account SYSTEM Domain\MSA Password management Set by user, subject to domain rules Managed by domain only – automatically reset Privilege set size (see notes for more details) MAX 5 Privileges: SeMachineAccountPrivilege - Disabled default SeChangeNotifyPrivilege - Enabled Default SeImpersonatePrivilege - Enabled Default SeCreateGlobalPrivilege - Enabled Default SeIncreaseWorkingSetPrivilege – Disabled default Registry access rights Full, implicit Read write, explicit Enrollment certificate rights Full, implicit Full, explicit Create computer object rights (required for hybrid Autopilot scenario) If connector is on the same machine as domain controller, unlimited If connector is not on the domain controller, delegation required Explicit delegation required Setting up the connector Before you begin First, you need to uninstall the existing connector by: Uninstalling from the Settings app on Windows Then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). To install and set up the new connector, you need the following minimum requirements: Downloading the connector build from Intune: Microsoft Entra account with Intune Service Administrator permissions Installation: .Net 4.7.2 Windows Server with 2008 R2 functional level Local administrator permissions Setting up the connector: Microsoft Entra account with an Intune license assigned and Intune Service Administrator permission Domain account with local administrator privileges Domain account should have permission to create msDS-ManagedServiceAccount objects Downloading the connector You can download the new connector from the Intune admin center and install in your environment. To set it up, launch the connector wizard and choose Sign In and sign in with a Microsoft Entra account with Intune service admin permissions and you’ll notice a new Configure Managed Service Account option. After signing in, the connector will enroll and only the Configure Managed Service Account option will be available. The account with Intune admin permissions should select that option to complete set up. For more detailed steps on installing the connector, review: Install the Intune Connector. irectory installation shows the MSA has been configured. Configuring organizational units (OUs) for domain join By default, MSAs don’t have access to create computer objects in any OU. If you wish to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. This can be done at any time (either before enrollment, or after the connector is enrolled): Update ODJConnectorEnrollmentWizard.exe.config: Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard” Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin OU name should be the distinguished name (see Additional information section) Note that the MSA is only granted access to the OUs configured in this file (and the default Computers container). If any OUs are removed from this list, completing the rest of the steps will revoke access. Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button. Success! – A pop up will appear showing success. Using the Intune Connector with multiple domains Customers who are already using the connector with more than one domain will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain. Configuring the connector The Intune Connector for Active Directory needs to be installed on each domain that you plan to use for domain join. If you need to have a second account redundancy, you will need to install the connector on a different server (in the same domain). Follow the steps above to ensure the connector is configured correctly, and that the MSA has appropriate permissions on the desired OUs. Ensure that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5: A list of Intune Connectors for Active Directory and their version in the Microsoft Intune admin center. Configure Domain Join profile: Follow the steps for configuring a domain join profile: Create a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot. Target the domain join profile to the appropriate device groups. Example of 2 domain join profiles targeted to different groups, with different domain names configured: Expected result: Connector in domain F11.F1.com will only join domain F11.F1.com. Connector in domain F12.F1.com will only join domain F12.F1.com. Additional information Retrieving Organizational Unit Distinguished Name If you need to customize the OUs that the MSA has access to, here are two easy methods to retrieve the distinguished name for these OUs: Let’s assume we have the following structure: Powershell Get-ADOrganizationalUnit (ActiveDirectory) | Microsoft Learn Get “=TestOUWithSpecialChars=”: PS Cmd: Get-ADOrganizationalUnit -Filter 'Name -like "*TestOUWithSpecialChar*"' | Format-Table Name, DistinguishedName Output: “OU=\=TestOUWithSpecialChars\=,DC=modesh2,DC=nttest,DC=microsoft,DC=com” Note, ‘=’ is escaped Get “NestedOU” PS Cmd: Get-ADOrganizationalUnit -Filter 'Name -like "NestedOU"' | Format-Table Name, DistinguishedName Output: “OU=NestedOU,OU=\=TestOUWithSpecialChars\=,DC=modesh2,DC=nttest,DC=microsoft,DC=com” Note, ‘=’ is still escaped Active Directory Users and Computers Select “View” from the menu, and enable “Advanced Features” Right click on the specific OU and click “Properties” Navigate to the “Attribute Editor” tab Select “distinguishedName” attribute and click “View” Summary The new connector aims to enhance security by reducing unnecessary privileges and permissions associated with the local SYSTEM account. This blog describes how to set up the new connector and configure it for your organization. Make sure to install the new connector by late May 2025 before the old connector becomes unsupported. If you have any questions, leave a comment on this post or reach out to us on X @IntuneSuppTeam.Using filters and APP conditional launch to control the OS version with Microsoft Intune
By: Wayne Bennett – Sr. Program Manager | Microsoft Intune Microsoft Intune app protection policies (APP) enables organizations to protect corporate data. APPs include conditional launch actions which control access to corporate data if the required device or app conditions aren’t met. Although we’ve documented the steps to selectively wipe app data using conditional launch, this blog expands on the existing information to provide details on how to use filters to require multiple minimum operating system (OS) versions. Background The increase of security improvements and the introduction of new functionality has resulted in more frequent OS updates. Thus, you may want to ensure devices accessing corporate resources have the latest updates installed. In Intune, for enrolled devices, you can use compliance policies to enforce a minimum OS version. Or, regardless of enrollment, you can use a single policy type to enforce minimum OS requirements by configuring APP conditional launch requirements. Then, users won’t be able to access protected resources if the minimum OS requirements aren’t met. How conditional launch and filters work together In APP, you can only configure one minimum OS version in the conditional launch settings but you could create multiple APPs with different minimum OS values. However, because APPs are assigned to user groups, this means a user with multiple devices that are running different OS versions could face conflicting OS requirements when accessing protected resources. To allow multiple APPs with different OS requirements to be targeted to the same user, you can create filters which target the APP to a specific OS version. There are two types of filters for Intune: Managed devices and Managed apps. APP only supports Managed apps filters. Creating filters To use filters with APPs, you must create a filter for each specific OS version you want to target: Navigate to the Microsoft Intune admin center. Select Tenant administration > Filters > Create > Managed apps. On the Basics page, enter a name for the filter which makes it easily identifiable and select the platform you want to target, in this example, iOS/iPadOS. On the Rules page, create a filter for the major OS release you wish target, for example, Property=osVersion(OS version), Operator=StartsWith, Value=18. Optional: You can use the Preview button to check the device, user, and app which match the specified filter. On the Review and create page, save the filter by selecting Create. Repeat these steps to create additional filters for each platform and major OS version you want to target, such as iOS 16 and 17. Create and target APP with a filter Navigate to the Microsoft Intune admin center. Select Apps > App protection policies > Create policy > Choose the platform you want to target with the APP, such as iOS/iPadOS. On the Basics page, enter a name for the policy which makes it easily identifiable. Complete the Apps, Data protection and Access requirements pages with the iOS, Android or Windows app protection policy settings which meet the requirements for your organization. Within the Device conditions section on the Conditional launch page (or Health Checks page for Windows APP), configure the OS minor or patch release you wish to set as the minimum version. For example: Setting=Min OS version Value=18.2.1 Action=Block access/Wipe data/Warn, (as per the action required for your organization). On the Assignments page, use the previously created filter to scope the policy assignment to the correct major OS version. On the Review and create page, save the policy by selecting Create. In the example shown, the filter will target devices running iOS 18 and the APP conditional launch settings will require 18.2.1, ensuring that the APP does not apply to devices running on other major versions of iOS. Create additional APPs for each OS version, for instance: Second policy for iOS 16: Conditional launch, Device conditions, Min OS version=16.7.10, filter, OS version, StartsWith=16. Third policy for iOS 17: Conditional launch, Device conditions, Min OS version=17.7.2, filter OS version, StartsWith=17. Conclusion Using the examples in this blog, you can create multiple APPs that require different minimum OS versions. You can then filter the assignment of these APPs to only apply to each major OS version. As the OS vendors release new minor OS updates or patches, you can also update each APP with the new minimum OS ensuring your organization remains secure. Let us know if you have any questions by leaving a comment on this post or reaching out on X @IntuneSuppTeam.Blocking and removing apps on Intune managed devices (Windows, iOS/iPadOS, Android and macOS)
By: Michael Dineen - Sr. Product Manager | Microsoft Intune This blog was written to provide guidance to Microsoft Intune admins that need to block or remove apps on their managed endpoints. This includes blocking the DeepSeek – AI Assistant app in accordance with government and company guidelines across the world (e.g. the Australian Government’s Department of Home Affairs Protective Policy Framework (PSPF) Direction 001-2025, Italy, South Korea). Guidance provided in this blog uses the DeepSeek – AI Assistant and associated website as an example, but you can use the provided guidance for other apps and websites as well. The information provided in this guidance is supplemental to previously provided guidance which is more exhaustive in the steps administrators need to take to identify, report on, and block prohibited apps across their managed and unmanaged mobile devices: Support tip: Removing and preventing the use of applications on iOS/iPadOS and Android devices. iOS/iPadOS devices For ease of reference, the below information is required to block the DeepSeek – AI Assistant app: App name: DeepSeek – AI Assistant Bundle ID: com.deepseek.chat Link to Apple app store page: DeepSeek – AI Assistant Publisher: 杭州深度求索人工智能基础技术研究有限公司 Corporate devices (Supervised) Hide and prevent the launch of the DeepSeek – AI Assistant app The most effective way to block an app on supervised iOS/iPadOS devices is to block the app from being shown or being launchable. Create a new device configuration profile and select Settings Catalog for the profile type. (Devices > iOS/iPadOS > Configuration profiles). On the Configuration settings tab, select Add settings and search for Blocked App Bundle IDs. Select the Restrictionscategory and then select the checkbox next to the Blocked App Bundle IDs setting. Enter the Bundle ID: com.deepseek.chat Assign the policy to either a device or user group. Note: The ability to hide and prevent the launch of specific apps is only available on supervised iOS/iPadOS devices. Unsupervised devices, including personal devices, can’t use this option. Uninstall the DeepSeek – AI Assistant app If a user has already installed the app via the Apple App Store, even though they will be unable to launch it when the previously described policy is configured, it’ll persist on the device. Use the steps below to automatically uninstall the app on devices that have it installed. This policy will also uninstall the app if it somehow gets installed at any point in the future, while the policy remains assigned. Navigate to Apps > iOS/iPadOS apps. Select + Add and choose iOS store app from the list. Search for DeepSeek – AI Assistant and Select. Accept the default settings, then Next. Modify the Scope tags as required. On the Assignments tab, under the Uninstall section, select + Add group or select + Add all users or + Add all devices, depending on your organization’s needs. Click the Create button on the Review + create tab to complete the setup. Monitor the status of the uninstall by navigating to Apps > iOS/iPadOS, selecting the app, and then selecting Device install status or User install status. The status will change to Not installed. Personal Devices – Bring your own device (BYOD) Admins have fewer options to manage settings and apps on personal devices. Apple provides no facility on unsupervised (including personal) iOS/iPadOS devices to hide or block access to specified apps. Instead, admins have the following options: Use an Intune compliance policy to prevent access to corporate data via Microsoft Entra Conditional Access (simplest and quickest to implement). Use a report to identify personal devices with specific apps installed. Takeover the app with the user’s consent. Uninstall the app. This guide will focus on option 1. For further guidance on the other options refer to: Support tip: Removing and preventing the use of applications on iOS/iPadOS and Android devices. Identify personal devices that have DeepSeek – AI Assistant installed and prevent access to corporate resources You can use compliance policies in Intune to mark a device as either “compliant” or “not compliant” based on several properties, such as whether a specific app is installed. Combined with Conditional Access, you can now prevent the user from accessing protected company resources when using a non-compliant device. Create an iOS/iPadOS compliance policy, by navigating to Devices > iOS/iPadOS > Compliance policies > Create policy. On the Compliance settings tab, under System Security > Restricted apps, enter the name and app Bundle ID and select Next. Name: DeepSeek – AI Assistant Bundle ID: com.deepseek.chat Under Actions for noncompliance, leave the default action Mark device noncompliant configured to Immediately and then select Next. Assign any Scope tags as required and select Next. Assign the policy to a user or device group and select Next. Review the policy and select Create. Devices that have the DeepSeek – AI Assistant app installed are shown in the Monitor section of the compliance policy. Navigate to the compliance policy and select Device status, under Monitor > View report. Devices that have the restricted app installed are shown in the report and marked as “Not compliant”. When combined with the Require device to be marked as compliant grant control, Conditional Access blocks access to protected corporate resources on devices that have the specified app installed. Android devices Android Enterprise corporate owned, fully managed devices Admins can optionally choose to allow only designated apps to be installed on corporate owned fully managed devices by configuring Allow access to all apps in Google Play store in a device restrictions policy. If this setting has been configured as Block or Not configured (the default), no additional configuration is required as users are only able to install apps allowed by the administrator. Uninstall DeepSeek To uninstall the app, and prevent it from being installed via the Google Play Store perform the following steps: Add a Managed Google Play app in the Microsoft Intune admin center by navigating to Apps > Android > Add, then select Managed Google Play app from the drop-down menu. r DeepSeek – AI Assistant in the Search bar, select the app in the results and click Select and then Sync. Navigate to Apps > Android and select DeepSeek – AI Assistant > Properties > Edit next to Assignments. Under the Uninstall section, add a user or device group and select Review + save and then Save. After the next sync, Google Play will uninstall the app, and the user will receive a notification on their managed device that the app was “deleted by your admin”: The Google Play Store will no longer display the app. If the user attempts to install or access the app directly via a link, the example error below is displayed on the user’s managed device: Android Enterprise personally owned devices with work profile For Android Enterprise personally owned devices with a work profile, use the same settings as described in the Android Enterprise corporate owned, fully managed devices section to uninstall and prevent the installation of restricted apps in the work profile. Note: Apps installed outside of the work profile can’t be managed by design. Windows devices You can block users from accessing the DeepSeek website on Windows devices that are enrolled into Microsoft Defender for Endpoint. Blocking users’ access to the website will also prevent them from adding DeepSeek as a progressive web app (PWA). This guidance assumes that devices are already enrolled into Microsoft Defender for Endpoint. Using Microsoft Defender for Endpoint to block access to websites in Microsoft Edge First, Custom Network Indicators needs to be enabled. Note: After configuring this setting, it may take up to 48 hours after a policy is created for a URL or IP Address to be blocked on a device. Access the Microsoft Defender admin center and navigate to Settings > Endpoints > Advanced features and enable Custom Network Indicators by selecting the corresponding radio button. Select Save preferences. Next, create a Custom Network Indicator. Navigate to Settings > Endpoints > Indicators and select URLs/Domains and click Add Item. Enter the following, and then click Next: URL/Domain: https://deepseek.com Title: DeepSeek Description: Block network access to DeepSeek Expires on (UTC): Never You can optionally generate an alert when a website is blocked by network protection by configuring the following and click Next: Generate alert: Ticked Severity: Informational Category: Unwanted software Note: Change the above settings according to your organization’s requirements. Select Block execution as the Action and click Next, review the Organizational scope and click Next. Review the summary and click Submit. Note: After configuring the Custom Network Indicator, it can take up to 48 hours for the URL to be blocked on a device. Once the Custom Network Indicator becomes active, the user will experience the following when attempting to access the DeepSeek website via Microsoft Edge: Using Defender for Endpoint to block websites in other browsers After configuring the above steps to block access to DeepSeek in Microsoft Edge, admins can leverage Network Protection to block access to DeepSeek in other browsers. Create a new Settings Catalog policy by navigating to Devices > Windows > Configuration > + Create > New Policy and selecting the following then click Create: Platform: Windows 10 and later Profile type: Settings Catalog Enter a name and description and click Next. Click + Add settings and in the search field, type Network Protection and click Search. Select the Defender category and select the checkbox next to Enable Network Protection. Close the settings picker and change the drop-down selection to Enabled (block mode) and click Next. Assign Scope Tags as required and click Next. Assign the policy to a user or device group and click Next. Review the policy and click Create. When users attempt to access the website in other browsers, they will experience an error that the content is blocked by their admin. macOS macOS devices that are onboarded to Defender for Endpoint and have Network Protection enabled are also unable to access the DeepSeek website in any browser as the same Custom Network Indicator works across both Windows and macOS. Ensure that you have configured the Custom Network Indicator as described earlier in the guidance. Enable Network Protection Enable Network Protection on macOS devices by performing the following in the Microsoft Intune admin center: Create a new configuration profile by navigating to Devices > macOS > Configuration > + Create > New Policy > Settings Catalog and select Create. Enter an appropriate name and description and select Next. Click + Add settings and in the search bar, enter Network Protection and select Search. Select the Microsoft Defender Network protection category and select the checkbox next to Enforcement Level and close the Settings Picker window. In the dropdown menu next to Enforcement Level, select Block and select Next. Add Scope Tags as required and select Next. Assign the policy to a user or devices group and select Next. Review the policy and select Create. The user when attempting to access the website will experience the following: Conclusion This blog serves as a quick guide for admins needing to block and remove specific applications on their Intune managed endpoints in regulated organizations. Additional guidance for other mobile device enrollment methods can be found here: Support tip: Removing and preventing the use of applications on iOS/iPadOS and Android devices. Additional resources For further control and management of user access to unapproved DeepSeek services, consider utilizing the following resources. This article provides insights into monitoring and gaining visibility into DeepSeek usage within your organization using Microsoft Defender XDR. Additionally, our Microsoft Purview guide offers valuable information on managing AI services and ensuring compliance with organizational policies. These resources can help enhance your security posture and ensure that only approved applications are accessible to users. Let us know if you have any questions by leaving a comment on this post or reaching out on X @IntuneSuppTeam.Updates to Beta APIs for Windows Endpoint security and Administrative templates
By: Julia Idaewor – Product Manager II | Microsoft Intune In 2023, when we began the migration for older Endpoint security policies, we recommended customers to take action to update their automation and scripts for Endpoint security policy creation. You can learn more about the migration in the blog: Endpoint security policies migrating to the unified settings platform in Microsoft Intune. Starting late March 2025, the Microsoft Graph Beta APIs deviceManagement/templates and deviceManagement/intents will no longer support the creation and management of Endpoint security policies for Windows devices. Additionally, the following Beta APIs will no longer work for managing Administrative templates: deviceManagement/groupPolicyCategories deviceManagement/groupPolicyConfigurations deviceManagement/groupPolicyDefinitions The old APIs used in the following policies will be replaced with the newer API deviceManagement/configurationPolicies. The new APIs leverage the newer policy infrastructure to improve accuracy and consistency. See a list of affected policies below: Antivirus Identity Protection Disk Encryption AV Exclusions Application Control Web Protection Endpoint Detection and Response Attack Surface Reduction Device Control Exploit Protection Firewall Rules Firewall Windows Security App Browser Administrative templates Note: Security baselines will not be affected by this API change as they can still be created using the deviceManagement/intents endpoint. If you're impacted by this change, look for MC955748 in the Message Center. If you’re interacting with Endpoint security policies or Administrative templates via the APIs listed above or, using automation or scripts to create and retrieve policies from these APIs, switch to the new graph endpoint: 'deviceManagement/configurationPolicies' API for policy creation by making POST requests to the corresponding endpoint for each policy. Examples Create Policy: Request Method: POST Request URL: https://graph.microsoft.com/beta/deviceManagement/configurationPolicies { "name": "ASR Rules", "description": "", "settings": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationGroupSettingCollectionInstance", "groupSettingCollectionValue": [ { "children": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "choiceSettingValue": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue", "children": [], "settingValueTemplateReference": { "settingValueTemplateId": "8b17ebce-496f-4b58-9d89-dd1c3861de39" }, "value": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts_block" }, "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts", "settingInstanceTemplateReference": { "settingInstanceTemplateId": "e416083e-05e3-4237-b8ec-a6ad49c4571e" } } ] } ], "settingInstanceTemplateReference": { "settingInstanceTemplateId": "19600663-e264-4c02-8f55-f2983216d6d7" }, "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules" } } ], "roleScopeTagIds": [ "0" ], "platforms": "windows10", "technologies": "mdm,microsoftSense", "templateReference": { "templateId": "e8c053d6-9f95-42b1-a7f1-ebfd71c67a4b_1" } } Get Policy: Request Method: GET Request URL: https://graph.microsoft.com/beta/deviceManagement/configurationPolicies('ec100030-eee3-4d13-9073-019affc599eb') Update Policy: Request Method: PUT Request URL: https://graph.microsoft.com/beta/deviceManagement/configurationPolicies('ec100030-eee3-4d13-9073-019affc599eb') Body: { "name": "ASR Rules", "description": "", "creationSource": null, "settings": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationSetting", "settingInstance": { "@odata.type": "#microsoft.graph.deviceManagementConfigurationGroupSettingCollectionInstance", "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules", "settingInstanceTemplateReference": { "settingInstanceTemplateId": "19600663-e264-4c02-8f55-f2983216d6d7" }, "groupSettingCollectionValue": [ { "settingValueTemplateReference": null, "children": [ { "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance", "settingDefinitionId": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts", "settingInstanceTemplateReference": { "settingInstanceTemplateId": "e416083e-05e3-4237-b8ec-a6ad49c4571e" }, "choiceSettingValue": { "value": "device_vendor_msft_policy_config_defender_attacksurfacereductionrules_blockexecutionofpotentiallyobfuscatedscripts_warn", "settingValueTemplateReference": { "settingValueTemplateId": "8b17ebce-496f-4b58-9d89-dd1c3861de39", "useTemplateDefault": false }, "children": [] } } ] } ] } } ], "roleScopeTagIds": [ "0" ], "platforms": "windows10", "technologies": "mdm,microsoftSense", "templateReference": { "templateId": "e8c053d6-9f95-42b1-a7f1-ebfd71c67a4b_1" } } If you have any questions, leave a comment below or reach out on X @IntuneSuppTeam.Cloud-native Windows endpoints: Begin by beginning
By: Jason Sandys – Principal Product Manager | Microsoft Intune Cloud-native is Microsoft’s goal for all commercial Windows endpoints. By definition, a cloud-native Windows endpoint is joined to Microsoft Entra ID and enrolled in Microsoft Intune. It represents and involves a clean break from on-premises related systems, limitations, and dependencies for device identity and management. This clean break from on-premises dependencies might align with larger organizational goals to reduce or eliminate on-premises infrastructure but doesn’t prevent users from accessing or using existing on-premises resources like file shares, printers, or applications. Cloud-native for Windows endpoints is a large change in thinking for most organizations and thus poses an initial challenge of how to even begin on this journey. This article provides you with guidance on how to begin and how to embrace this new model. For additional guidance that includes a higher-level discussion of what to do with existing endpoints, see: Best practices in moving to cloud native endpoint management | Microsoft 365 Blog to learn more. Proof of concept The first step is to begin with a proof of concept (POC). For any new technology, methodology, or solution, POCs offer numerous advantages. Specifically, they enable you to evaluate the new “thing” with minimal risk while building your skills and gaining stakeholder buy-in. Because the exact end state of Windows endpoints is highly variable among organizations and even within an organization, a POC for cloud-native Windows enables you to take an iterative approach for defining and deploying these endpoints. This iterative approach involves smaller waves of users and endpoints within your organization. It’s ultimately up to you to define which endpoints or users should be in each wave, but you should align this to your endpoint lifecycle and refresh plan. Aligning to your endpoint lifecycle allows you to minimize impact to your users by consolidating the delivery of new endpoints with the changeover from hybrid join to Microsoft Entra join, which requires a Windows reset or fresh Windows instance. Additional significant criteria to consider for which users and endpoints to include in each wave are the organizational user personas and endpoint roles. An iterative POC enables you to break work effort and challenges into more manageable pieces and address them individually or sequentially. This is important since some (often many) challenges related to adopting cloud-native Windows endpoints are isolated or not applicable to all endpoints or users in the organization. Some challenges may even remain unknown until they arise, and the only way to learn about them is by conducting actual production testing and evaluation. You don’t need to address or solve every challenge to successfully begin your journey to cloud-native Windows endpoints. An easy example for this is users that exclusively use SaaS applications: these users’ endpoints already have limited (if any) true on-premises service or application dependencies, and they likely face few, if any, challenges in moving to cloud-native Windows endpoints. Initial cloud-native Windows configuration There are some common activities that need to occur before you deploy your first cloud-native Windows endpoints. Keep in mind that this list is simply the steps to begin the iterative process, it’s not all-inclusive or representative of the final state. For a detailed walkthrough on configuring these items (and more), see the following detailed tutorial: Get started with cloud-native Windows endpoints. Identify the user personas and endpoint types within your organization. These typically vary among organizations, so there’s no standard template to follow. However, you should align your POC to these personas and endpoint types to limit each wave’s impact and scope of necessary change. Configure your baseline policies. Implement a minimum viable set of policies within Intune to deploy to all endpoints. Base these policies on your organizational requirements rather than what has been previously implemented in group policy (or elsewhere). We strongly suggest starting as cleanly as possible with this activity and initially including only what is necessary to meet the security requirements of your organization. Configure Windows Autopatch. Keeping Windows up to date is critical, and Windows Autopatch offers the best path to doing this (whether a Windows endpoint is cloud-native or not). Configure Windows applications. As with policies, this should be a minimal set of applications to deploy to your POC endpoints and can include Win32 based and Microsoft Store based applications. Configure Windows Autopilot. Windows Autopilot enables quick and seamless Windows provisioning without the overhead of classic on-premises OS deployment methods. With Windows Autopilot, the provisioning process for cloud-native Windows endpoints is quick and easy. Configure Delivery Optimization. Windows uses Delivery Optimization for downloading most items from the cloud. By default, Delivery Optimization leverages peers to cache and download content locally. Edit the default configuration to define which managed endpoints are peers or to disable peer content sharing. Enable Windows Hello for Business and enforce multi-factor authentication (MFA) using Conditional Access. Enable Cloud Kerberos Trust for Windows Hello for Business to enable seamless access to on-premises resources. These items significantly increase your organization’s security posture and place your organization well on the Zero Trust path. As the iterative POC process evolves to include more user personas and endpoint roles, you can add more functional policy requirements and applications. This will involve some discovery as you learn about the actual needs of these various personas and roles. Since you aren’t targeting everything from day one, you don’t need to have all requirements defined up front or solutions for every potential issue. Additional suggestions, tips, and guidance Don’t assume something does or doesn’t work on cloud-native Windows endpoints. The POC process enables you to iteratively test and evaluate applications, services, resources, and everything else in your environment – most of which isn’t typically documented. It might simply be part of the tacit or tribal knowledge within your organization. In general, you’ll find that nearly everything works just as it did before Windows cloud-native. Document everything. As you implement, document the “what” as well as the “why” for everything you configure. This allows you and your colleagues to come back at any time and understand or refresh your memory for your cloud-native Windows implementation, as well as many other things in the environment. Microsoft doesn’t expect organizations to rapidly convert their entire estate of Windows endpoints to cloud-native. Instead, we recommend taking it slow, being deliberate, and using the iterative approach outlined above by aligning to your hardware refresh cycle to minimize impact on users. This also provides you with time to prove the solution, address gaps, and overcome challenges as you discover them without disrupting productivity. Use the built-in Conditional Access policy templates to quickly get started with MFA and other Conditional Access capabilities. The templates enable you to implement Conditional Access policies that align with our recommendations without experimentation. Accessing on-premises resources including file shares from a cloud-native Windows endpoint works with little to no configuration. Refer to the documentation for more details: How SSO to on-premises resources works on Microsoft Entra joined devices. Call to action Begin exploring your cloud-native Windows POC today. Taking this first step now will allow your organization to start reaping the benefits of enhanced security, streamlined management, and improved user experience sooner. Every organization is unique, so there’s no blueprint for comprehensively implementing cloud-native Windows. However, you don’t need a comprehensive blueprint to be successful, you just need to begin and slowly expand adoption throughout your organization when and where it makes sense. The guidance provided above along with the getting started tutorial should give you the information, tools, and confidence to move forward with decoupling your endpoints and users from your on-premises anchors and fully embrace cloud-native Windows. For a more detailed and in-depth discussion on adopting cloud-native Windows, including planning and execution, see Learn more about cloud-native endpoints. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam. Additional Blogs 3 benefits of going cloud native | Microsoft 365 Blog How to achieve cloud-native endpoint management with Microsoft Intune | Microsoft 365 Blog Myths and misconceptions: Windows 11 and cloud native | Windows IT Pro Blog (microsoft.com)New Recovery Tool to help with CrowdStrike issue impacting Windows endpoints
Steps for how to access and use the new recovery tool Microsoft created - updated on July 31, July 23, July 22, and July 21. The tool provides two recovery options to expedite the repair process from the CrowdStrike issue impacting Windows endpoints. Please note this tool does not use Microsoft Intune, but we're sharing as a Support tip to help Windows customers.
