Merge branch 'master' into nimishasatapathy-5595104-updatepolicy

This commit is contained in:
Rebecca Agiewich
2022-01-03 16:24:24 -07:00
committed by GitHub
7 changed files with 156 additions and 13 deletions

View File

@ -6,7 +6,7 @@ ms.topic: article
ms.prod: w10
ms.technology: windows
author: dansimp
ms.date: 12/03/2021
ms.date: 01/03/2022
ms.reviewer:
manager: dansimp
ms.collection: highpri
@ -50,11 +50,11 @@ For this policy to work, you must verify that the MDM service provider allows th
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.
1. Verify that the user who is going to enroll the device has a valid Endpoint Protection Manager license.
:::image type="content" alt-text="Intune license verification." source="images/auto-enrollment-intune-license-verification.png" lightbox="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](./azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md).
2. Verify that auto-enrollment is activated for those users who are going to enroll the devices into Mobile Device Management (MDM). For additional details, see [Azure AD and Microsoft Intune: Automatic MDM enrollment in the new Portal](./azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md).
![Auto-enrollment activation verification.](images/auto-enrollment-activation-verification.png)

View File

@ -7,7 +7,7 @@ ms.topic: article
ms.prod: w10
ms.technology: windows
author: dansimp
ms.date: 12/02/2020
ms.date: 01/03/2022
ms.reviewer:
manager: dansimp
---
@ -3693,6 +3693,8 @@ ADMX Info:
<!--Description-->
This policy setting allows you to define the number of days that must pass before spyware security intelligence is considered out of date. If security intelligence is determined to be out of date, this state may trigger several additional actions, including falling back to an alternative update source or displaying a warning icon in the user interface. By default, this value is set to 14 days.
We do not recommend setting the value to less than 2 days to prevent machines from going out of date.
If you enable this setting, spyware security intelligence will be considered out of date after the number of days specified have passed without an update.
If you disable or do not configure this setting, spyware security intelligence will be considered out of date after the default number of days have passed without an update.

View File

@ -31,6 +31,9 @@ manager: dansimp
<dd>
<a href="#notifications-disallowtilenotification">Notifications/DisallowTileNotification</a>
</dd>
<dd>
<a href="#notifications-wnsendpoint">Notifications/WnsEndpoint</a>
</dd>
</dl>
@ -208,5 +211,77 @@ Validation:
<!--/Policy-->
<hr/>
<!--Policy-->
<a href="" id="notifications-wnsendpoint"></a>**Notifications/WnsEndpoint**
<!--SupportedSKUs-->
<table>
<tr>
<th>Edition</th>
<th>Windows 10</th>
<th>Windows 11</th>
</tr>
<tr>
<td>Home</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Pro</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Business</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Enterprise</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Education</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</table>
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Machine
<hr/>
<!--/Scope-->
<!--Description-->
This policy setting determines which Windows Notification Service endpoint will be used to connect for Windows Push Notifications.
If you disable or do not configure this setting, the push notifications will connect to the default endpoint of client.wns.windows.com.
Note: Ensure the proper WNS FQDNs, VIPs, IPs and Ports are also whitelisted from your firewall settings.
<!--/Description-->
<!--ADMXMapped-->
ADMX Info:
- GP Friendly name: *Required for Airgap servers that may have a unique FQDN that is different from the public endpoint*
- GP name: *WnsEndpoint*
- GP path: *Start Menu and Taskbar/Notifications*
- GP ADMX file name: *WPN.admx*
<!--/ADMXMapped-->
<!--SupportedValues-->
If the policy is not specified, we will default our connection to client.wns.windows.com.
<!--/SupportedValues-->
<!--/Policy-->
<hr/>
<!--/Policies-->

View File

@ -29,6 +29,9 @@ manager: dansimp
<dd>
<a href="#settings-allowdatetime">Settings/AllowDateTime</a>
</dd>
<dd>
<a href="#settings-alloweditdevicename">Settings/AllowEditDeviceName</a>
</dd>
<dd>
<a href="#settings-allowlanguage">Settings/AllowLanguage</a>
</dd>
@ -191,6 +194,68 @@ The following list shows the supported values:
<hr/>
<!--Policy-->
<a href="" id="settings-alloweditdevicename"></a>**Settings/AllowEditDeviceName**
<!--SupportedSKUs-->
<table>
<tr>
<th>Edition</th>
<th>Windows 10</th>
<th>Windows 11</th>
</tr>
<tr>
<td>Home</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Pro</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Business</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Enterprise</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Education</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</table>
<!--/SupportedSKUs-->
<hr/>
<!--Scope-->
[Scope](./policy-configuration-service-provider.md#policy-scope):
> [!div class = "checklist"]
> * Device
<hr/>
<!--/Scope-->
<!--Description-->
This policy disables edit device name option on Settings.
<!--/Description-->
<!--SupportedValues-->
Describes what value are supported in by this policy and meaning of each value, default value.
<!--/SupportedValues-->
<!--/Policy-->
<hr/>
<!--Policy-->
<a href="" id="settings-allowlanguage"></a>**Settings/AllowLanguage**