From 91345fac6f052b0894d5c4ba9827658b9397eb44 Mon Sep 17 00:00:00 2001 From: rogersoMS <44718379+rogersoMS@users.noreply.github.com> Date: Wed, 25 Nov 2020 17:18:01 +1100 Subject: [PATCH 1/4] Removing Intune/MEM specific details (not within scope of CSP docs) Adding clarification on examples regarding Azure AD. Removing Intune specific reporting issues as CSP documentation should be generic. --- windows/client-management/mdm/policy-csp-userrights.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/windows/client-management/mdm/policy-csp-userrights.md b/windows/client-management/mdm/policy-csp-userrights.md index b6f2c4f536..b1a0a67245 100644 --- a/windows/client-management/mdm/policy-csp-userrights.md +++ b/windows/client-management/mdm/policy-csp-userrights.md @@ -75,9 +75,6 @@ Here are examples of data fields. The encoded 0xF000 is the standard delimiter/s If you use Intune custom profiles to assign UserRights policies, you must use the CDATA tag (``) to wrap the data fields. You can specify one or more user groups within the CDATA tag by using 0xF000 as the delimiter/separator. -> [!NOTE] -> There is currently a reporting issue in the Microsoft Endpoint Manager (MEM) console which results in the setting reporting back a 'Remediation failed' (0x87d1fde8) error, even when the setting is successfully applied. To verify whether the setting has applied successfully, check the local Windows 10 device: Event Viewer>Applications and Services LogsWindows>DeviceManagement-Enterprise-Diagnostics-Provider>Admin>Event ID 814. This issue is the result of the use of the CDATA tags, which are neccesary when more than a single entry is required. If there is only a single entry, the CDATA tags can be omitted - which will resolve the reporting false positive. - > [!NOTE] > `` is the entity encoding of 0xF000. @@ -87,7 +84,7 @@ For example, the following syntax grants user rights to Authenticated Users and ``` -For example, the following syntax grants user rights to two specific users from Contoso, user1 and user2: +For example, the following syntax grants user rights to two specific Azure Active Directory (AAD) users from Contoso, user1 and user2: ```xml From 8a7931d2561dad5f7ffa2ec61008a9b7377e9f20 Mon Sep 17 00:00:00 2001 From: "Trond B. Krokli" <38162891+illfated@users.noreply.github.com> Date: Thu, 26 Nov 2020 22:08:59 +0100 Subject: [PATCH 2/4] Client Management/MDM: URL & text correction As outlined in issue ticket #8682 (3rd bullet point in Requirements section is confusing, and linked page is unrelated to the link's text), "The linked page contains basically no information about registering your "enterprise AD" with Azure AD. Instead, that page is a somewhat convoluted set of sections that are sort of unrelated to anything specific." Thanks to Jeremy T. Bradshaw (JeremyTBradshaw) for identifying and reporting this issue. Changes proposed: - change the MDM page link URL to a more precise Azure AD page link - change the 3rd bullet point text to refer to the new page link Whitespace changes: - remove end-of-line redundant whitespace (blanks) Closes #8682 --- ...device-automatically-using-group-policy.md | 78 +++++++++---------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md b/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md index cb162899d3..0d225aa26a 100644 --- a/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md +++ b/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md @@ -7,20 +7,20 @@ ms.prod: w10 ms.technology: windows author: manikadhiman ms.date: -ms.reviewer: +ms.reviewer: manager: dansimp --- # Enroll a Windows 10 device automatically using Group Policy -Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain-joined devices. +Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain-joined devices. The enrollment into Intune is triggered by a group policy created on your local AD and happens without any user interaction. This means you can automatically mass-enroll a large number of domain-joined corporate devices into Microsoft Intune. The enrollment process starts in the background once you sign in to the device with your Azure AD account. Requirements: - AD-joined PC running Windows 10, version 1709 or later -- The enterprise has configured a mobile device management (MDM) service -- The enterprise AD must be [registered with Azure Active Directory (Azure AD)](azure-active-directory-integration-with-mdm.md) +- The enterprise has configured a mobile device management (MDM) service +- The on-premises AD must be [integrated with Azure AD (via Azure AD Connect)](https://docs.microsoft.com/azure/architecture/reference-architectures/identity/azure-ad) - The device should not already be enrolled in Intune using the classic agents (devices managed using agents will fail enrollment with `error 0x80180026`) - The minimum Windows Server version requirement is based on the Hybrid Azure AD join requirement. See [How to plan your hybrid Azure Active Directory join implementation](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan) for more information. @@ -33,7 +33,7 @@ Requirements: The auto-enrollment relies on the presence of an MDM service and the Azure Active Directory registration for the PC. Starting in Windows 10, version 1607, once the enterprise has registered its AD with Azure AD, a Windows PC that is domain joined is automatically Azure AD–registered. > [!NOTE] -> In Windows 10, version 1709, the enrollment protocol was updated to check whether the device is domain-joined. For details, see [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](https://msdn.microsoft.com/library/mt221945.aspx). For examples, see section 4.3.1 RequestSecurityToken of the MS-MDE2 protocol documentation. +> In Windows 10, version 1709, the enrollment protocol was updated to check whether the device is domain-joined. For details, see [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](https://msdn.microsoft.com/library/mt221945.aspx). For examples, see section 4.3.1 RequestSecurityToken of the MS-MDE2 protocol documentation. When the auto-enrollment Group Policy is enabled, a task is created in the background that initiates the MDM enrollment. The task will use the existing MDM service configuration from the Azure Active Directory information of the user. If multi-factor authentication is required, the user will get a prompt to complete the authentication. Once the enrollment is configured, the user can check the status in the Settings page. @@ -42,13 +42,13 @@ In Windows 10, version 1709 or later, when the same policy is configured in GP a For this policy to work, you must verify that the MDM service provider allows the GP triggered MDM enrollment for domain joined devices. ## Verify auto-enrollment requirements and settings -To ensure that the auto-enrollment feature is working as expected, you must verify that various requirements and settings are configured correctly. +To ensure that the auto-enrollment feature is working as expected, you must verify that various requirements and settings are configured correctly. The following steps demonstrate required settings using the Intune service: 1. Verify that the user who is going to enroll the device has a valid Intune license. ![Intune license verification](images/auto-enrollment-intune-license-verification.png) -2. Verify that auto-enrollment is activated for those users who are going to enroll the devices into Intune. For additional details, see [Azure AD and Microsoft Intune: Automatic MDM enrollment in the new Portal](https://docs.microsoft.com/windows/client-management/mdm/azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal). +2. Verify that auto-enrollment is activated for those users who are going to enroll the devices into Intune. For additional details, see [Azure AD and Microsoft Intune: Automatic MDM enrollment in the new Portal](https://docs.microsoft.com/windows/client-management/mdm/azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal). ![Auto-enrollment activation verification](images/auto-enrollment-activation-verification.png) @@ -80,7 +80,7 @@ The following steps demonstrate required settings using the Intune service: ![Mobility setting MDM intune](images/auto-enrollment-microsoft-intune-setting.png) -7. Verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is properly deployed to all devices which should be enrolled into Intune. +7. Verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is properly deployed to all devices which should be enrolled into Intune. You may contact your domain administrators to verify if the group policy has been deployed successfully. 8. Verify that the device is not enrolled with the old Intune client used on the Intune Silverlight Portal (this is the Intune portal used before the Azure portal). @@ -95,12 +95,12 @@ This procedure is only for illustration purposes to show how the new auto-enroll Requirements: - AD-joined PC running Windows 10, version 1709 or later -- Enterprise has MDM service already configured +- Enterprise has MDM service already configured - Enterprise AD must be registered with Azure AD 1. Run GPEdit.msc - Click Start, then in the text box type gpedit. + Click Start, then in the text box type gpedit. ![GPEdit desktop app search result](images/autoenrollment-gpedit.png) @@ -110,7 +110,7 @@ Requirements: ![MDM policies](images/autoenrollment-mdm-policies.png) -4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the Selected Credential Type to use. +4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the Selected Credential Type to use. > [!NOTE] > **Device Credential** Credential Type will also work, however, it is not yet supported for MDM solutions (including Intune). We don't recommend using this option until support is announced. @@ -120,11 +120,11 @@ Requirements: 5. Click **Enable**, and select **User Credential** from the dropdown **Select Credential Type to Use**, then click **OK**. > [!NOTE] - > In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later. - > The default behavior for older releases is to revert to **User Credential**. - > **Device Credential** is not supported for enrollment type when you have a ConfigMgr Agent on your device. + > In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later. + > The default behavior for older releases is to revert to **User Credential**. + > **Device Credential** is not supported for enrollment type when you have a ConfigMgr Agent on your device. - When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called " Schedule created by enrollment client for automatically enrolling in MDM from AAD." + When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called " Schedule created by enrollment client for automatically enrolling in MDM from AAD." To see the scheduled task, launch the [Task Scheduler app](#task-scheduler-app). @@ -153,11 +153,11 @@ Requirements: 2. Under **Best match**, click **Task Scheduler** to launch it. -3. In **Task Scheduler Library**, open **Microsoft > Windows** , then click **EnterpriseMgmt**. +3. In **Task Scheduler Library**, open **Microsoft > Windows** , then click **EnterpriseMgmt**. ![Auto-enrollment scheduled task](images/autoenrollment-scheduled-task.png) - To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED). You can see the logs in the **History** tab. + To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED). You can see the logs in the **History** tab. If the device enrollment is blocked, your IT admin may have enabled the **Disable MDM Enrollment** policy. Note that the GPEdit console does not reflect the status of policies set by your IT admin on your device. It is only used by the user to set policies. @@ -172,39 +172,39 @@ Requirements: > [!IMPORTANT] > If you do not see the policy, it may be because you don't have the ADMX for Windows 10, version 1803, version 1809, or version 1903 installed. To fix the issue, use the following procedures. Note that the latest MDM.admx is backwards compatible. -1. Download: - +1. Download: + - 1803 --> [Administrative Templates (.admx) for Windows 10 April 2018 Update (1803)](https://www.microsoft.com/download/details.aspx?id=56880) - + - 1809 --> [Administrative Templates (.admx) for Windows 10 October 2018 Update (1809)](https://www.microsoft.com/download/details.aspx?id=57576) - + - 1903 --> [Administrative Templates (.admx) for Windows 10 May 2019 Update (1903)](https://www.microsoft.com/download/details.aspx?id=58495) - + - 1909 --> [Administrative Templates (.admx) for Windows 10 November 2019 Update (1909)]( https://www.microsoft.com/download/confirmation.aspx?id=1005915) - + - 2004 --> [Administrative Templates (.admx) for Windows 10 May 2020 Update (2004)](https://www.microsoft.com/download/confirmation.aspx?id=101445) - + 2. Install the package on the Domain Controller. - + 3. Navigate, depending on the version to the folder: - + - 1803 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 April 2018 Update (1803) v2** - + - 1809 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 October 2018 Update (1809) v2** - + - 1903 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2019 Update (1903) v3** - + - 1909 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2019 Update (1909)** - - - 2004 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2020 Update (2004)** - + + - 2004 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2020 Update (2004)** + 4. Rename the extracted Policy Definitions folder to **PolicyDefinitions**. - -5. Copy PolicyDefinitions folder to **C:\Windows\SYSVOL\domain\Policies**. - + +5. Copy PolicyDefinitions folder to **C:\Windows\SYSVOL\domain\Policies**. + If this folder does not exist, then be aware that you will be switching to a [central policy store](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) for your entire domain. - + 6. Restart the Domain Controller for the policy to be available. This procedure will work for any future version as well. @@ -218,7 +218,7 @@ This procedure will work for any future version as well. 4. Filter using Security Groups. ## Troubleshoot auto-enrollment of devices -Investigate the log file if you have issues even after performing all the mandatory verification steps. The first log file to investigate is the event log on the target Windows 10 device. +Investigate the log file if you have issues even after performing all the mandatory verification steps. The first log file to investigate is the event log on the target Windows 10 device. To collect Event Viewer logs: @@ -254,12 +254,12 @@ To collect Event Viewer logs: Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. This means that the task scheduler log is only useful to confirm if the auto-enrollment task is triggered or not. It does not indicate the success or failure of auto-enrollment. - If you cannot see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from AAD is initiated, there is possibly issue with the group policy. Immediately run the command `gpupdate /force` in command prompt to get the GPO applied. If this still does not help, further troubleshooting on the Active Directory is required. + If you cannot see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from AAD is initiated, there is possibly issue with the group policy. Immediately run the command `gpupdate /force` in command prompt to get the GPO applied. If this still does not help, further troubleshooting on the Active Directory is required. One frequently seen error is related to some outdated enrollment entries in the registry on the target client device (**HKLM > Software > Microsoft > Enrollments**). If a device has been enrolled (can be any MDM solution and not only Intune), some enrollment information added into the registry is seen: ![Outdated enrollment entries](images/auto-enrollment-outdated-enrollment-entries.png) - By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational** event log file under event ID 7016. + By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational** event log file under event ID 7016. A resolution to this issue is to remove the registry key manually. If you do not know which registry key to remove, go for the key which displays most entries as the screenshot above. All other keys will display fewer entries as shown in the following screenshot: ![Manually deleted entries](images/auto-enrollment-activation-verification-less-entries.png) From b5d0b41e62fbbcbead877dbcd5385a7ae8533cdd Mon Sep 17 00:00:00 2001 From: Ben M Schorr <43045782+Beschorr@users.noreply.github.com> Date: Mon, 30 Nov 2020 16:37:54 -0800 Subject: [PATCH 3/4] Update respond-file-alerts.md Text says "Cloud-based protection..." but the in-product UI and other docs refer to it as "Cloud-delivered protection...". Updating text to standardize. --- .../microsoft-defender-atp/respond-file-alerts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/threat-protection/microsoft-defender-atp/respond-file-alerts.md b/windows/security/threat-protection/microsoft-defender-atp/respond-file-alerts.md index 336099ffa7..691d1f29c5 100644 --- a/windows/security/threat-protection/microsoft-defender-atp/respond-file-alerts.md +++ b/windows/security/threat-protection/microsoft-defender-atp/respond-file-alerts.md @@ -139,7 +139,7 @@ You can prevent further propagation of an attack in your organization by banning >[!IMPORTANT] > ->- This feature is available if your organization uses Microsoft Defender Antivirus and Cloud–based protection is enabled. For more information, see [Manage cloud–based protection](../microsoft-defender-antivirus/deploy-manage-report-microsoft-defender-antivirus.md). +>- This feature is available if your organization uses Microsoft Defender Antivirus and Cloud–delivered protection is enabled. For more information, see [Manage cloud–delivered protection](../microsoft-defender-antivirus/deploy-manage-report-microsoft-defender-antivirus.md). > >- The Antimalware client version must be 4.18.1901.x or later. >- This feature is designed to prevent suspected malware (or potentially malicious files) from being downloaded from the web. It currently supports portable executable (PE) files, including _.exe_ and _.dll_ files. The coverage will be extended over time. From f56a7dd035017370ef5ff97c8ad8a265ebe7fa65 Mon Sep 17 00:00:00 2001 From: Alekhya Jupudi Date: Tue, 1 Dec 2020 12:41:16 +0530 Subject: [PATCH 4/4] Add DISM command to 2 more migration articles as per PR #8700 Added DISM command in these two articles as per: https://github.com/MicrosoftDocs/windows-itpro-docs/pull/8700#pullrequestreview-541269350 (The two articles are this one: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/mcafee-to-microsoft-defender-setup and this one: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/switch-to-microsoft-defender-setup) --- .../mcafee-to-microsoft-defender-setup.md | 6 ++++++ .../switch-to-microsoft-defender-setup.md | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/windows/security/threat-protection/microsoft-defender-atp/mcafee-to-microsoft-defender-setup.md b/windows/security/threat-protection/microsoft-defender-atp/mcafee-to-microsoft-defender-setup.md index 858c7f0d06..6e55918615 100644 --- a/windows/security/threat-protection/microsoft-defender-atp/mcafee-to-microsoft-defender-setup.md +++ b/windows/security/threat-protection/microsoft-defender-atp/mcafee-to-microsoft-defender-setup.md @@ -91,6 +91,12 @@ The [DisableAntiSpyware](https://docs.microsoft.com/windows-hardware/customize/d `Dism /online /Get-FeatureInfo /FeatureName:Windows-Defender`
+> [!NOTE] +> When using the DISM command within a task sequence running PS, the following path to cmd.exe is required. +> Example:
+> `c:\windows\sysnative\cmd.exe /c Dism /online /Get-FeatureInfo /FeatureName:Windows-Defender-Features`
+> `c:\windows\sysnative\cmd.exe /c Dism /online /Get-FeatureInfo /FeatureName:Windows-Defender`
+ 3. To verify Microsoft Defender Antivirus is running, use the following PowerShell cmdlet:
`Get-Service -Name windefend` diff --git a/windows/security/threat-protection/microsoft-defender-atp/switch-to-microsoft-defender-setup.md b/windows/security/threat-protection/microsoft-defender-atp/switch-to-microsoft-defender-setup.md index b8c66898af..28403de16e 100644 --- a/windows/security/threat-protection/microsoft-defender-atp/switch-to-microsoft-defender-setup.md +++ b/windows/security/threat-protection/microsoft-defender-atp/switch-to-microsoft-defender-setup.md @@ -87,6 +87,12 @@ The [DisableAntiSpyware](https://docs.microsoft.com/windows-hardware/customize/d `Dism /online /Get-FeatureInfo /FeatureName:Windows-Defender`
+> [!NOTE] +> When using the DISM command within a task sequence running PS, the following path to cmd.exe is required. +> Example:
+> `c:\windows\sysnative\cmd.exe /c Dism /online /Get-FeatureInfo /FeatureName:Windows-Defender-Features`
+> `c:\windows\sysnative\cmd.exe /c Dism /online /Get-FeatureInfo /FeatureName:Windows-Defender`
+ 3. To verify Microsoft Defender Antivirus is running, use the following PowerShell cmdlet:
`Get-Service -Name windefend`