deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-13 05:47:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'refs/remotes/origin/rs2' into jdrs2icd

Browse Source
This commit is contained in:
jdeckerMS 2017-03-08 11:48:00 -08:00
commit 275165a501
7 changed files with 141 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
devices/surface-hub/manage-windows-updates-for-surface-hub.md
View File

@ -17,7 +17,7 @@ New releases of the Surface Hub operating system are published through Windows U
- **Windows Update for Business** - New in Windows 10, Windows Update for Business is a set of features designed to provide enterprises additional control over how and when Windows Update installs releases, while reducing device management costs. Using this method, Surface Hubs are directly connected to Microsoft’s Windows Update service.
- **Windows Server Update Services (WSUS)** - Set of services that enable IT administrators to obtain the updates that Windows Update determines are applicable to the devices in their enterprise, perform additional testing and evaluation on the updates, and select the updates they want to install. Using this method, Surface Hubs will receive updates from WSUS rather than Windows Update.
You can also configure Surface Hub to receive updates from both Windows Update for Business and WSUS. See [Integrate Windows Update for Business with Windows Server Update Services](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-integrate-wufb#integrate-windows-update-for-business-with-windows-server-update-services) for details.
You can also configure Surface Hub to receive updates from both Windows Update for Business and WSUS. See [Integrate Windows Update for Business with Windows Server Update Services](https://technet.microsoft.com/itpro/windows/manage/waas-integrate-wufb#integrate-windows-update-for-business-with-windows-server-update-services) for details.
| Capabilities | Windows Update for Business | Windows Server Update Services (WSUS) |
| ------------ | --------------------------- | ------------------------------------- |
@ -27,7 +27,7 @@ You can also configure Surface Hub to receive updates from both Windows Update f
| Define maintenance windows for installing updates. | Yes | Yes |
> [!TIP]
> Use peer-to-peer content sharing to reduce bandwidth issues during updates. See [Optimize update delivery for Windows 10 updates](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-optimize-windows-10-updates) for details.
> Use peer-to-peer content sharing to reduce bandwidth issues during updates. See [Optimize update delivery for Windows 10 updates](https://technet.microsoft.com/itpro/windows/manage/waas-optimize-windows-10-updates) for details.
> [!NOTE]
> Surface Hub does not currently support rolling back updates.
@ -45,11 +45,11 @@ In order to improve release quality and simplify deployments, all new releases t
The Surface Hub operating system is available on **Current Branch (CB)** and **Current Branch for Business (CBB)**. Like other editions of Windows 10, the servicing lifetime of CB or CBB is finite. You must install new feature updates on machines running these branches in order to continue receiving quality updates.
For more information on Windows as a Service, see [Overview of Windows as a service](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-overview).
For more information on Windows as a Service, see [Overview of Windows as a service](https://technet.microsoft.com/itpro/windows/manage/waas-overview).
## Use Windows Update for Business
Surface Hubs, like all Windows 10 devices, include **Windows Update for Business (WUfB)** to enable you to control how your devices are being updated. Windows Update for Business helps reduce device management costs, provide controls over update deployment, offer quicker access to security updates, as well as provide access to the latest innovations from Microsoft on an ongoing basis. For more information, see [Manage updates using Windows Update for Business](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-manage-updates-wufb).
Surface Hubs, like all Windows 10 devices, include **Windows Update for Business (WUfB)** to enable you to control how your devices are being updated. Windows Update for Business helps reduce device management costs, provide controls over update deployment, offer quicker access to security updates, as well as provide access to the latest innovations from Microsoft on an ongoing basis. For more information, see [Manage updates using Windows Update for Business](https://technet.microsoft.com/itpro/windows/manage/waas-manage-updates-wufb).
**To set up Windows Update for Business:**
1. [Group Surface Hub into deployment rings](#group-surface-hub-into-deployment-rings)
@ -58,11 +58,11 @@ Surface Hubs, like all Windows 10 devices, include **Windows Update for Business
> [!NOTE]
> You can use Microsoft Intune, System Center Configuration Manager, or a supported third-party MDM provider to set up WUfB. [Walkthrough: use Microsoft Intune to configure Windows Update for Business.](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-wufb-intune)
> You can use Microsoft Intune, System Center Configuration Manager, or a supported third-party MDM provider to set up WUfB. [Walkthrough: use Microsoft Intune to configure Windows Update for Business.](https://technet.microsoft.com/itpro/windows/manage/waas-wufb-intune)
### Group Surface Hub into deployment rings
Use deployment rings to control when updates roll out to your Surface Hubs, giving you time to validate them. For example, you can update a small pool of devices first to verify quality before a broader roll-out to your organization. Depending on who manages Surface Hub in your organization, consider incorporating Surface Hub into the deployment rings that you've built for your other Windows 10 devices. For more information about deployment rings, see [Build deployment rings for Windows 10 updates](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-deployment-rings-windows-10-updates).
Use deployment rings to control when updates roll out to your Surface Hubs, giving you time to validate them. For example, you can update a small pool of devices first to verify quality before a broader roll-out to your organization. Depending on who manages Surface Hub in your organization, consider incorporating Surface Hub into the deployment rings that you've built for your other Windows 10 devices. For more information about deployment rings, see [Build deployment rings for Windows 10 updates](https://technet.microsoft.com/itpro/windows/manage/waas-deployment-rings-windows-10-updates).
This table gives examples of deployment rings.
@ -75,22 +75,22 @@ This table gives examples of deployment rings.
### Configure Surface Hub to use Current Branch or Current Branch for Business
By default, Surface Hubs are configured to receive updates from Current Branch (CB). CB receives feature updates as soon as they are released by Microsoft. Current Branch for Business (CBB), on the other hand, receives feature updates at least four months after they have been initially offered to CB devices, and includes all of the quality updates that have been released in the interim. For more information on the differences between CB and CBB, see [Servicing branches](https://technet.microsoft.com/en-us/itpro/windows/manage/waas-overview#servicing-branches).
By default, Surface Hubs are configured to receive updates from Current Branch (CB). CB receives feature updates as soon as they are released by Microsoft. Current Branch for Business (CBB), on the other hand, receives feature updates at least four months after they have been initially offered to CB devices, and includes all of the quality updates that have been released in the interim. For more information on the differences between CB and CBB, see [Servicing branches](https://technet.microsoft.com/itpro/windows/manage/waas-overview#servicing-branches).
**To manually configure Surface Hub to use CB or CBB:**
1. Open **Settings** > **Update & Security** > **Windows Update**, and then select **Advanced Options**.
2. Select **Defer feature updates**.
To configure Surface Hub to use CB or CBB remotely using MDM, set an appropriate [Update/BranchReadinessLevel](https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962.aspx#Update_BranchReadinessLevel) policy.
To configure Surface Hub to use CB or CBB remotely using MDM, set an appropriate [Update/BranchReadinessLevel](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_BranchReadinessLevel) policy.
### Configure when Surface Hub receives updates
Once you've determined deployment rings for your Surface Hubs, configure update deferral policies for each ring:
- To defer feature updates, set an appropriate [Update/DeferFeatureUpdatesPeriodInDays](https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962.aspx#Update_DeferFeatureUpdatesPeriodInDays) policy for each ring.
- To defer quality updates, set an appropriate [Update/DeferQualityUpdatesPeriodInDays](https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962.aspx#Update_DeferQualityUpdatesPeriodInDays) policy for each ring.
- To defer feature updates, set an appropriate [Update/DeferFeatureUpdatesPeriodInDays](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_DeferFeatureUpdatesPeriodInDays) policy for each ring.
- To defer quality updates, set an appropriate [Update/DeferQualityUpdatesPeriodInDays](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_DeferQualityUpdatesPeriodInDays) policy for each ring.
> [!NOTE]
> If you encounter issues during the update rollout, you can pause updates using [Update/PauseFeatureUpdates](https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962.aspx#Update_PauseFeatureUpdates) and [Update/PauseQualityUpdates](https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962.aspx#Update_PauseQualityUpdates).
> If you encounter issues during the update rollout, you can pause updates using [Update/PauseFeatureUpdates](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_PauseFeatureUpdates) and [Update/PauseQualityUpdates](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_PauseQualityUpdates).
## Use Windows Server Update Services
@ -103,7 +103,7 @@ You can connect Surface Hub to your Windows Server Update Services (WSUS) server
3. Navigate to **Update & security** > **Windows Update** > **Advanced options** > **Configure Windows Server Update Services (WSUS) server**.
4. Click **Use WSUS Server to download updates** and type the URL of your WSUS server.
To connect Surface Hub to a WSUS server using MDM, set an appropriate [Update/UpdateServiceUrl](https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962.aspx#Update_UpdateServiceUrl) policy.
To connect Surface Hub to a WSUS server using MDM, set an appropriate [Update/UpdateServiceUrl](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#Update_UpdateServiceUrl) policy.
**If you use a proxy server or other method to block URLs**
@ -135,7 +135,7 @@ A default maintenance window is set for all new Surface Hubs:
2. Navigate to **Update & security** > **Windows Update** > **Advanced options**.
3. Under **Maintenance hours**, select **Change**.
To change the maintenance window using MDM, set the **MOMAgent** node in the [SurfaceHub configuration service provider](https://msdn.microsoft.com/en-us/library/windows/hardware/mt608323.aspx). See [Manage settings with an MDM provider](manage-settings-with-mdm-for-surface-hub.md) for more details.
To change the maintenance window using MDM, set the **MOMAgent** node in the [SurfaceHub configuration service provider](https://msdn.microsoft.com/library/windows/hardware/mt608323.aspx). See [Manage settings with an MDM provider](manage-settings-with-mdm-for-surface-hub.md) for more details.
## Related topics

12
windows/configure/configure-windows-telemetry-in-your-organization.md
View File

@ -98,17 +98,17 @@ Windows telemetry also helps Microsoft better understand how customers use (or d
### Insights into your own organization
Sharing information with Microsoft helps make Windows and other products better, but it can also help make your internal processes and user experiences better, as well. Microsoft is in the process of developing a set of analytics customized for your internal use. The first of these, called [Windows 10 Upgrade Analytics](../deploy/manage-windows-upgrades-with-upgrade-analytics.md).
Sharing information with Microsoft helps make Windows and other products better, but it can also help make your internal processes and user experiences better, as well. Microsoft is in the process of developing a set of analytics customized for your internal use. The first of these, called [Upgrade Readiness](../deploy/manage-windows-upgrades-with-upgrade-readiness.md).
#### Windows 10 Upgrade Analytics
#### Upgrade Readiness
Upgrading to new operating system versions has traditionally been a challenging, complex, and slow process for many enterprises. Discovering applications and drivers and then testing them for potential compatibility issues have been among the biggest pain points.
To better help customers through this difficult process, Microsoft developed Upgrade Analytics to give enterprises the tools to plan and manage the upgrade process end to end and allowing them to adopt new Windows releases more quickly and on an ongoing basis.
To better help customers through this difficult process, Microsoft developed Upgrade Readiness to give enterprises the tools to plan and manage the upgrade process end to end and allowing them to adopt new Windows releases more quickly and on an ongoing basis.
With Windows telemetry enabled, Microsoft collects computer, application, and driver compatibility-related information for analysis. We then identify compatibility issues that can block your upgrade and suggest fixes when they are known to Microsoft.
Use Upgrade Analytics to get:
Use Upgrade Readiness to get:
- A visual workflow that guides you from pilot to production
- Detailed computer, driver, and application inventory
@ -118,7 +118,7 @@ Use Upgrade Analytics to get:
- Application usage information, allowing targeted validation; workflow to track validation progress and decisions
- Data export to commonly used software deployment tools
The Upgrade Analytics workflow steps you through the discovery and rationalization process until you have a list of computers that are ready to be upgraded.
The Upgrade Readiness workflow steps you through the discovery and rationalization process until you have a list of computers that are ready to be upgraded.
## How is telemetry data handled by Microsoft?
@ -179,7 +179,7 @@ The levels are cumulative and are illustrated in the following diagram. Also, th
### Security level
The Security level gathers only the telemetry info that is required to keep Windows devices, Windows Server, and guests protected with the latest security updates. This level is only available on Windows Server 2016, Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile Enterprise, and Windos IoT Core editions.
The Security level gathers only the telemetry info that is required to keep Windows devices, Windows Server, and guests protected with the latest security updates. This level is only available on Windows Server 2016, Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile Enterprise, and Windows IoT Core editions.
> [!NOTE]
> If your organization relies on Windows Update for updates, you shouldn’t use the **Security** level. Because no Windows Update information is gathered at this level, important information about update failures is not sent. Microsoft uses this information to fix the causes of those failures and improve the quality of our updates.

106
windows/configure/provisioning-multivariant.md
View File

@ -1,6 +1,6 @@
---
title: Create a provisioning package with multivariant settings (Windows 10)
description: Create a provisioning package with multivariant settings to customize the provisioned settings.
description: Create a provisioning package with multivariant settings to customize the provisioned settings for defined conditions.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
@ -16,37 +16,31 @@ localizationpriority: high
- Windows 10
- Windows 10 Mobile
Multivariant provisioning packages enable you to create a single provisioning package that can work for multiple locales.
To provision multivariant settings, you must create a provisioning package with defined **Conditions** and **Settings** that are tied to these conditions. When you install this package on a Windows 10 device, the provisioning engine applies the matching condition settings at every event and triggers provisioning.
In your organization, you might have different configuration requirements for devices that you manage. You can create separate provisioning packages for each group of devices in your organization that have different requirements. Or, you can create a multivariant provisioning package, a single provisioning package that can work for multiple conditions. For example, in a single provisioning package, you can define one set of customization settings that will apply to devices set up for French and a different set of customization settings for devices set up for Japanese.
The following events trigger provisioning on Windows 10 devices:
To provision multivariant settings, you use Windows Imaging and Configuration Designer (ICD) to create a provisioning package that contains all of the customization settings that you want to apply to any of your devices. Next, you manually edit the .XML file for that project to define each set of devices (a **Target**). For each **Target**, you specify at least one **Condition** with a value, which identifies the devices to receive the configuration. Finally, for each **Target**, you provide the customization settings to be applied to those devices.
| Event | Windows 10 Mobile | Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) |
| --- | --- | --- |
| System boot | Supported | Supported |
| Operating system update | Supported | Planned |
| Package installation during device first run experience | Supported | Supported |
| Detection of SIM presence or update | Supported | Not supported |
| Package installation at runtime | Supported | Supported |
| Roaming detected | Supported | Not supported |
Let's begin by learning how to define a **Target**.
## Target, TargetState, Condition, and priorities
Targets describe keying for a variant and must be described or pre-declared before being referenced by the variant.
## Define a target
- You can define multiple **Target** child elements for each **Id** that you need for the customization setting.
In the XML file, you provide an **Id**, or friendly name, for each **Target**. Each **Target** is defined by at least one **TargetState** which contains at least one **Condition**. A **Condition** element defines the matching type between the condition and the specified value.
- Within a **Target** you can define multiple **TargetState** elements.
A **Target** can have more than one **TargetState**, and a **TargetState** can have more than one **Condition**.
- Within a **TargetState** element you can create multiple **Condition** elements.
![Target with multiple target states and conditions](images/multi-target.png)
- A **Condition** element defines the matching type between the condition and the specified value.
The following table describes the logic for the target definition.
The following table shows the conditions supported in Windows 10 provisioning:
<table><tr><td>When all **Condition** elements are TRUE, **TargetState** is TRUE.</td><td>![Target state is true when all conditions are true](images/icd-multi-targetstate-true.png)</td></tr>
<tr><td>If any of the **TargetState** elements is TRUE, **Target** is TRUE, and the **Id** can be used for setting customizations.</td><td>![Target is true if any target state is true](images/icd-multi-target-true.png)</td></tr></table>
### Conditions
The following table shows the conditions supported in Windows 10 provisioning for a **TargetState**:
>[!NOTE]
>You can use any of these supported conditions when defining your **TargetState**.
| Condition Name | Condition priority | Windows 10 Mobile | Windows 10 for desktop editions | Value type | Value description |
| --- | --- | --- | --- | --- | --- |
@ -57,54 +51,47 @@ The following table shows the conditions supported in Windows 10 provisioning:
| GID1 | P0 | Supported | N/A | Digit string | Use to target settings based on the Group Identifier (level 1) value. |
| ICCID | P0 | Supported | N/A | Digit string | Use to target settings based on the Integrated Circuit Card Identifier (ICCID) value. |
| Roaming | P0 | Supported | N/A | Boolean | Use to specify roaming. Set the value to **1** (roaming) or **0** (non-roaming). |
| UICC | P0 | Supported | N/A | Enumeration | Use to specify the UICC state. Set the value to one of the following:</br></br></br>- 0 - Empty</br>- 1 - Ready</br>- 2 - Locked |
| UICC | P0 | Supported | N/A | Enumeration | Use to specify the Universal Integrated Circuit Card (UICC) state. Set the value to one of the following:</br></br></br>- 0 - Empty</br>- 1 - Ready</br>- 2 - Locked |
| UICCSLOT | P0 | Supported | N/A | Digit string | Use to specify the UICC slot. Set the value one of the following:</br></br></br>- 0 - Slot 0</br>- 1 - Slot 1 |
| ProcessorType | P1 | Supported | Supported | String | Use to target settings based on the processor type. |
| ProcessorName | P1 | Supported | Supported | String | Use to target settings based on the processor name. |
| AoAc | P1 | Supported | Supported | Boolean | Set the value to 0 or 1. |
| PowerPlatformRole | P1 | Supported | Supported | Enumeration | Indicates the preferred power management profile. Set the value based on the POWER_PLATFORM_ROLE enumeration. |
| AoAc ("Always On, Always Connected") | P1 | Supported | Supported | Boolean | Set the value to **0** (false) or **1** (true). If this condition is TRUE, the system supports the S0 low power idle model. |
| PowerPlatformRole | P1 | Supported | Supported | Enumeration | Indicates the preferred power management profile. Set the value based on the [POWER_PLATFORM_ROLE enumeration](https://msdn.microsoft.com/library/windows/desktop/aa373174.aspx). |
| Architecture | P1 | Supported | Supported | String | Matches the PROCESSOR_ARCHITECTURE environment variable. |
| Server | P1 | Supported | Supported | Boolean | Set the value to 0 or 1. |
| Region | P1 | Supported | Supported | Enumeration | Use to target settings based on country/region. |
| Lang | P1 | Supported | Supported | Enumeration | Use to target settings based on language code. |
| ROMLANG | P1 | Supported | N/A | Digit string | Use to specify the PhoneROMLanguage that's set for DeviceTargeting. This condition is used primarily to detect variants for China. For example, you can use this condition and set the value to "0804". |
| Server | P1 | Supported | Supported | Boolean | Set the value to **0** (false) or **1** (true) to identify a server. |
| Region | P1 | Supported | Supported | Enumeration | Use to target settings based on country/region, using the 2-digit alpha ISO code per [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2). |
| Lang | P1 | Supported | Supported | Enumeration | Use to target settings based on language code, using the 2-digit [ISO 639 alpha-2 code](https://en.wikipedia.org/wiki/ISO_639). |
The matching types supported in Windows 10 are:
| Matching type | Syntax | Example |
| --- | --- | --- |
| Straight match | Matching type is specified as-is | &lt;Condition Name="ProcessorName" Value="Barton" /&gt; |
| Regex match | Matching type is prefixed by "Pattern:" | &lt;Condition Name="ProcessorName" Value="Pattern:.*Celeron.*" /&gt; |
| Regular expression (Regex) match | Matching type is prefixed by "Pattern:" | &lt;Condition Name="ProcessorName" Value="Pattern:.*Celeron.*" /&gt; |
| Numeric range match | Matching type is prefixed by "!Range:" | &lt;Condition Name="MNC" Value="!Range:400, 550" /&gt; |
- When all **Condition** elements are TRUE, **TargetState** is TRUE (**AND** logic).
### TargetState priorities
- If any of the **TargetState** elements is TRUE, **Target** is TRUE (**OR** logic), and **Id** can be used for the setting customization.
You can define more than one **TargetState** within a provisioning package to apply settings to devices that match device conditions. When the provisioning engine evalues each **TargetState**, more than one **TargetState** may fit current device conditions. To determine the order in which the settings are applied, the system assigns a priority to every **TargetState**.
A setting that matches a **TargetState** with a lower priority is applied before the setting that matches a **TargetState** with a higher priority. This means that a setting for the **TargetState** with the higher priority can overwrite a setting for the **TargetState** with the lower priority.
You can define more than one **TargetState** within a provisioning package to apply variant settings that match device conditions. When the provisioning engine evalues each **TargetState**, more than one **TargetState** may fit current device conditions. To determine the order in which the variant settings are applied, the system assigns a priority to every **TargetState**.
Settings that match more than one **TargetState** with equal priority are applied according to the order that each **TargetState** is defined in the provisioning package.
A variant setting that matches a **TargetState** with a lower priority is applied before the variant that matches a **TargetState** with a higher priority. Variant settings that match more than one **TargetState** with equal priority are applied according to the order that each **TargetState** is defined in the provisioning package.
The **TargetState** priority is assigned based on the condition's priority (see the [Conditions table](#conditions) for priorities). The priority evaluation rules are as followed:
The **TargetState** priority is assigned based on the conditions priority and the priority evaluation rules are as followed:
1. A **TargetState** with P0 conditions is higher than a **TargetState** without P0 conditions.
1. **TargetState** with P0 conditions is higher than **TargetState** without P0 conditions.
2. A **TargetState** with both P0 and P1 conditions is higher than a **TargetState** with only P0 conditions.
2. A **TargetState** with a greater number of matched P0 conditions is higher than **TargetState** with fewer matched P0 conditions, regardless of the number of P1 conditions matched.
2. **TargetState** with P1 conditions is higher than **TargetState** without P0 and P1 conditions.
2. If the number of P0 conditions matched are equivalent, then the **TargetState** with the most matched P1 conditions has higher priority.
3. If both P0 and P1 conditions are equally matched, then the **TargetState** with the greatest total number of matched conditions has highest priority.
3. If N₁>N₂>0, the **TargetState** priority with N₁ P0 conditions is higher than the **TargetState** with N₂ P1 conditions.
4. For **TargetState** without P0 conditions, if N₁>N₂>0 **TargetState** with N₁ P1 conditions is higher than the **TargetState** with N₂ P1 conditions.
5. For **TargetState** without P0 and P1 conditions, if N₁>N₂>0 **TargetState** priority with N₁ P2 conditions is higher than the **TargetState** with N₂ P2 conditions.
6. For rules 3, 4, and 5, if N₁=N₂, **TargetState** priorities are considered equal.
## Create a provisioning package with multivariant settings
@ -112,17 +99,15 @@ The **TargetState** priority is assigned based on the conditions priority and th
Follow these steps to create a provisioning package with multivariant capabilities.
1. Build a provisioning package and configure the customizations you need to apply during certain conditions. For more information, see [Create a provisioning package](provisioning-create-package.md).
1. Build a provisioning package and configure the customizations you want to apply during certain conditions. For more information, see [Create a provisioning package](provisioning-create-package.md).
2. After you've [configured the settings](provisioning-create-package.md#configure-settings), save the project.
3. Open the project folder and copy the customizations.xml file.
3. Open the project folder and copy the customizations.xml file to any local location.
4. Use an XML or text editor to open the customizations.xml file.
The customizations.xml file holds the package metadata (including the package owner and rank) and the settings that you configured when you created your provisioning package. The Customizations node contains a Common section, which contains the customization settings.
The customizations.xml file holds the package metadata (including the package owner and rank) and the settings that you configured when you created your provisioning package. The **Customizations** node of the file contains a **Common** section, which contains the customization settings.
The following example shows the contents of a sample customizations.xml file.
@ -153,7 +138,7 @@ Follow these steps to create a provisioning package with multivariant capabiliti
</WindowsCustomizatons>
```
4. Edit the customizations.xml file and create a **Targets** section to describe the conditions that will handle your multivariant settings.
4. Edit the customizations.xml file to create a **Targets** section to describe the conditions that will handle your multivariant settings.
The following example shows the customizations.xml, which has been modified to include several conditions including **ProcessorName**, **ProcessorType**, **MCC**, and **MNC**.
@ -210,10 +195,10 @@ Follow these steps to create a provisioning package with multivariant capabiliti
c. Move compliant settings from the **Common** section to the **Variant** section.
If any of the TargetRef elements matches the Target, all settings in the Variant are applied (OR logic).
If any of the **TargetRef** elements matches the **Target**, all settings in the **Variant** are applied.
>[!NOTE]
>You can define multiple Variant sections. Settings that reside in the **Common** section are applied unconditionally on every triggering event.
>You can define multiple **Variant** sections. Settings that reside in the **Common** section are applied unconditionally on every triggering event.
The following example shows the customizations.xml updated to include a **Variant** section and the moved settings that will be applied if the conditions for the variant are met.
@ -289,7 +274,20 @@ In this example, the **StoreFile** corresponds to the location of the settings s
## Events that trigger provisioning
When you install the multivariant provisioning package on a Windows 10 device, the provisioning engine applies the matching condition settings at every event and triggers provisioning.
The following events trigger provisioning on Windows 10 devices:
| Event | Windows 10 Mobile | Windows 10 for desktop editions |
| --- | --- | --- |
| System boot | Supported | Supported |
| Operating system update | Supported | Planned |
| Package installation during device first run experience | Supported | Supported |
| Detection of SIM presence or update | Supported | Supported |
| Package installation at runtime | Supported | Supported |
| Roaming detected | Supported | Not supported |

9
windows/keep-secure/change-history-for-keep-windows-10-secure.md
View File

@ -13,12 +13,21 @@ author: brianlic-msft
This topic lists new and updated topics in the [Keep Windows 10 secure](index.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
## March 2017
|New or changed topic |Description |
|---------------------|------------|
|[Protect derived domain credentials with Credential Guard](credential-guard.md) |Updated to include additional security qualifications starting with Window 10, version 1703.|
|[Requirements and deployment planning guidelines for Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md) |Updated to include additional security qualifications starting with Window 10, version 1703.|
## February 2017
|New or changed topic |Description |
|---------------------|------------|
|[Overview of threat mitigations in Windows 10](overview-of-threat-mitigations-in-windows-10.md) | Reorganized from existing content, to provide a better overview of threat mitigations. Added information that maps the Enhanced Mitigation Experience Toolkit (EMET) to Windows 10 features. |
## January 2017
|New or changed topic |Description |
|---------------------|------------|

BIN
windows/keep-secure/images/privacy-setting-in-sign-in-options.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.9 KiB

73
windows/keep-secure/interactive-logon-display-user-information-when-the-session-is-locked.md
View File

@ -17,31 +17,80 @@ author: brianlic-msft
Describes the best practices, location, values, and security considerations for the **Interactive logon: Display user information when the session is locked** security policy setting.
## Reference
When a session is locked in a Windows operating system (meaning the user at the computer pressed CTRL+ALT+DEL and the Secure Desktop is displayed), user information is displayed. By default, this information is in the form of **&lt;user name&gt; is logged on**. The displayed user name is the user’s full name as set on the Properties page for that user. These settings do not apply to the logon tiles, which are displayed on the desktop after using the **Switch User** feature. The information that is displayed can be changed to meet your security requirements using the following possible values.
This setting controls whether details such as email address or domain\username appear with the username on the sign-in screen.
For clients that run Windows 10 version 1511 and 1507 (RTM), this setting works similarly to previous versions of Windows.
Due to a new **Privacy** setting in Windows 10 version 1607, this setting affects those clients differently.
### Possible values
### Changes in Windows 10 version 1607
Beginning with Windows 10 version 1607, new functionality was added to Windows 10 to hide username details such as email address by default, with the ability to change the default to show the details.
This functionality is controlled by a new **Privacy** setting in **Settings** > **Accounts** > **Sign-in options**.
The Privacy setting is off by default, which hides the details.
![Privacy setting](images\privacy-setting-in-sign-in-options.png)
The **Interactive logon: Display user information when the session is locked** Group Policy setting controls the same functionality.
This setting has these possible values:
- **User display name, domain and user names**
If this is a local logon, the user’s full name is displayed on the Secure Desktop. If it is a domain logon, the user’s domain and user’s account name is displayed.
For a local logon, the user's full name is displayed.
If the user signed in using a Microsoft Account, the user's email address is displayed.
For a domain logon, the domain\username is displayed.
This has the same effect as turning on the **Privacy** setting.
- **User display name only**
The name of the user who locked the session is displayed on the Secure Desktop as the user’s full name.
The full name of the user who locked the session is displayed.
This has the same effect as turning off the **Privacy** setting.
- **Do not display user information**
No names are displayed on the Secure Desktop, but user’s full names will be displayed on the **Switch user** desktop.
No names are displayed.
Beginning with Windows 10 version 1607, this option is not supported.
If this option is chosen, the full name of the user who locked the session is displayed instead.
This change makes this setting consistent with the functionality of the new **Privacy** setting.
To have no user information displayed, enable the Group Policy setting **Interactive logon: Don't display last signed-in**.
- Blank.
Default setting. This translates to “Not defined,” but it will display the user’s full name in the same manner as the **User display name** option. When an option is set, you cannot reset this policy to blank, or not defined.
Default setting.
This translates to “Not defined,” but it will display the user’s full name in the same manner as the option **User display name only**.
When an option is set, you cannot reset this policy to blank, or not defined.
### Hotfix for Windows 10 version 1607
Clients that run Windows 10 version 1607 will not show details on the sign-in screen even if the **User display name, domain and user names** option is chosen because the **Privacy** setting is off.
If the **Privacy** setting is turned on, details will show.
The **Privacy** setting cannot be changed for clients in bulk.
Instead, apply KB 4013429 to clients that run Windows 10 version 1607 so they behave similarly to previous versions of Windows.
There are related Group Policy settings:
- **Computer Configuration\Policies\Administrative Templates\System\Logon\Block user from showing account details on sign-in** prevents users from showing account details on the sign-in screen.
- **Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Don’t display last signed-in** prevents the username of the last user to sign in from being shown.
- **Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Don’t display user name at sign in** prevents the username from being shown at Windows sign-in and immediately after credentials are entered and before the desktop appears.
### Interaction with related Group Policy settings
For all versions of Windows 10, only the user display name is shown by default.
If **Block user from showing account details on sign-in** is enabled, then only the user display name is shown regardless of any other Group Policy settings.
Users will not be able to show details.
If **Block user from showing account details on sign-in** is not enabled, then you can set **Interactive logon: Display user information when the session is locked** to **User display name, domain and user names** to show additional details such as domain\username.
In this case, clients that run Windows 10 version 1607 need KB 4013429 applied.
Users will not be able to hide additional details.
If **Block user from showing account details on sign-in** is not enabled and **Don’t display last signed-in** is enabled, the username will not be shown.
### Best practices
Your implementation of this policy depends on your security requirements for displayed logon information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have computers with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
Your implementation of this policy depends on your security requirements for displayed logon information. If you run computers that store sensitive data, with monitors displayed in unsecured locations, or if you have computers with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
Depending on your security policy, you might also want to enable the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to logon.
Depending on your security policy, you might also want to enable the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy.
### Location
@ -86,13 +135,7 @@ When a computer displays the Secure Desktop in an unsecured area, certain user i
Enabling this policy setting allows the operating system to hide certain user information from being displayed on the Secure Desktop (after the device has been booted or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the **Switch user** feature is used so that the logon tiles are displayed for each logged on user.
You might also want to enable the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to logon.
### Potential impact
If you do not enable this policy, the effect will be the same as enabling the policy and selecting the **User display name, domain and user names** option.
If the policy is enabled and set to **Do not display user information**, an observer cannot see who is logged onto the Secure Desktop, but the logon tile is still present if the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy is not enabled. Depending on how the logon tiles are configured, they could provide visual clues as to who is logged on. In addition, if the Interactive logon: Do not display last user name policy is not enabled, then the **Switch user** feature will show user information.
You might also want to enable the [Interactive logon: Do not display last signed-in](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to logon.
## Related topics

6
windows/keep-secure/interactive-logon-do-not-display-last-user-name.md
View File

@ -1,5 +1,5 @@
---
title: Interactive logon Do not display last user name (Windows 10)
title: Interactive logon Don't display last signed-in (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Interactive logon Do not display last user name security policy setting.
ms.assetid: 98b24b03-95fe-4edc-8e97-cbdaa8e314fd
ms.prod: w10
@ -9,12 +9,12 @@ ms.pagetype: security
author: brianlic-msft
---
# Interactive logon: Do not display last user name
# Interactive logon: Don't display last signed-in
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not display last user name** security policy setting.
Describes the best practices, location, values, and security considerations for the **Interactive logon: Don't display last signed-in** security policy setting. Before Windows 10 version 1703, this policy setting was named **Interactive logon:Do not display last user name.**
## Reference