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

Merge branch 'master' of https://github.com/microsoftdocs/windows-itpro-docs into public-8919

Browse Source
This commit is contained in:
Liza Poggemeyer 2019-08-09 14:50:47 -07:00
commit b887daef29
216 changed files with 17150 additions and 16941 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

91
browsers/edge/includes/allow-adobe-flash-include.md
View File

@ -1,45 +1,46 @@
---
author: eavena
ms.author: eravena
ms.date: 10/02/2018
ms.reviewer:
audience: itpro manager: dansimp
ms.prod: edge
ms.topic: include
---
<!-- ## Allow Adobe Flash -->
>*Supported versions: Microsoft Edge on Windows 10*<br>
>*Default setting: Enabled or not configured (Allowed)*
[!INCLUDE [allow-adobe-flash-shortdesc](../shortdesc/allow-adobe-flash-shortdesc.md)]
### Supported values
| Group Policy | MDM | Registry | Description |
|-----------------------|:---:|:--------:|-------------|
| Disabled | 0 | 0 | Prevented |
| Enabled **(default)** | 1 | 1 | Allowed |
---
### ADMX info and settings
#### ADMX info
- **GP English name:** Allow Adobe Flash
- **GP name:** AllowFlash
- **GP path:** Windows Components/Microsoft Edge
- **GP ADMX file name:** MicrosoftEdge.admx
#### MDM settings
- **MDM name:** Browser/[AllowFlash](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-browser\#browser-allowflash)
- **Supported devices:** Desktop
- **URI full path:** ./Vendor/MSFT/Policy/Config/Browser/AllowAdobeFlash
- **Data type:** Integer
#### Registry settings
- **Path:** HKLM\Software\Policies\Microsoft\MicrosoftEdge\Addons
- **Value name:** FlashPlayerEnabled
- **Value type:** REG_DWORD
<hr>
---
author: eavena
ms.author: eravena
ms.date: 10/02/2018
ms.reviewer:
audience: itpro
manager: dansimp
ms.prod: edge
ms.topic: include
---
<!-- ## Allow Adobe Flash -->
>*Supported versions: Microsoft Edge on Windows 10*<br>
>*Default setting: Enabled or not configured (Allowed)*
[!INCLUDE [allow-adobe-flash-shortdesc](../shortdesc/allow-adobe-flash-shortdesc.md)]
### Supported values
| Group Policy | MDM | Registry | Description |
|-----------------------|:---:|:--------:|-------------|
| Disabled | 0 | 0 | Prevented |
| Enabled **(default)** | 1 | 1 | Allowed |
---
### ADMX info and settings
#### ADMX info
- **GP English name:** Allow Adobe Flash
- **GP name:** AllowFlash
- **GP path:** Windows Components/Microsoft Edge
- **GP ADMX file name:** MicrosoftEdge.admx
#### MDM settings
- **MDM name:** Browser/[AllowFlash](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-browser\#browser-allowflash)
- **Supported devices:** Desktop
- **URI full path:** ./Vendor/MSFT/Policy/Config/Browser/AllowFlash
- **Data type:** Integer
#### Registry settings
- **Path:** HKLM\Software\Policies\Microsoft\MicrosoftEdge\Addons
- **Value name:** FlashPlayerEnabled
- **Value type:** REG_DWORD
<hr>

603
browsers/internet-explorer/ie11-deploy-guide/enterprise-mode-schema-version-2-guidance.md
View File

@ -1,301 +1,302 @@
---
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.pagetype: appcompat
description: Use the Enterprise Mode Site List Manager to create and update your Enterprise Mode site list for devices running Windows 10.
author: lomayor
ms.prod: ie11
ms.assetid: 909ca359-5654-4df9-b9fb-921232fc05f5
ms.reviewer:
audience: itpro manager: dansimp
ms.author: lomayor
title: Enterprise Mode schema v.2 guidance (Internet Explorer 11 for IT Pros)
ms.sitesec: library
ms.date: 12/04/2017
---
# Enterprise Mode schema v.2 guidance
**Applies to:**
- Windows 10
- Windows 8.1
- Windows 7
Use the Enterprise Mode Site List Manager to create and update your site list for devices running Windows 7, Windows 8.1, and Windows 10, using the version 2.0 (v.2) of the Enterprise Mode schema. If you don't want to use the Enterprise Mode Site List Manager, you also have the option to update your XML schema using Notepad, or any other XML-editing app.
**Important**<br>
If you're running Windows 7 or Windows 8.1 and you've been using the version 1.0 (v.1) of the schema, you can continue to do so, but you won't get the benefits that come with the updated schema. For info about the v.1 schema, see [Enterprise Mode schema v.1 guidance](enterprise-mode-schema-version-1-guidance.md).
## Enterprise Mode schema v.2 updates
Because of the schema changes, you can't combine the old version (v.1) with the new version (v.2) of the schema. If you look at your XML file, you can tell which version you're using by:
- &lt;rules&gt;. If your schema root node includes this key, you're using the v.1 version of the schema.
- &lt;site-list&gt;. If your schema root node includes this key, you're using the v.2 version of the schema.
You can continue to use the v.1 version of the schema on Windows 10, but you won't have the benefits of the new v.2 version schema updates and new features. Additionally, saving the v.1 version of the schema in the new Enterprise Mode Site List Manager (schema v.2) automatically updates the file to use the v.2 version of the schema.
### Enterprise Mode v.2 schema example
The following is an example of the v.2 version of the Enterprise Mode schema.
**Important**<br>
Make sure that you don't specify a protocol when adding your URLs. Using a URL like `<url="contoso.com">`, automatically applies to both https://contoso.com and https://contoso.com.
``` xml
<site-list version="205">
<!--- File creation header --->
<created-by>
<tool>EnterpriseSitelistManager</tool>
<version>10240</version>
<date-created>20150728.135021</date-created>
</created-by>
<!--- Begin Site List --->
<site url="www.cpandl.com">
<compat-mode>IE8Enterprise</compat-mode>
<open-in>MSEdge</open-in>
</site>
<site url="www.woodgrovebank.com">
<compat-mode>default</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="adatum.com">
<compat-mode>IE7Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="contoso.com">
<compat-mode>default</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="relecloud.com"/>
<compat-mode>default</compat-mode>
<open-in>none</open-in>
<site url="relecloud.com/about">
<compat-mode>IE8Enterprise"</compat-mode>
</site>
<site url="contoso.com/travel">
<compat-mode>IE7</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="fabrikam.com">
<compat-mode>IE8Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="fabrikam.com/products">
<compat-mode>IE7</compat-mode>
<open-in>IE11</open-in>
</site>
</site-list>
```
### Updated schema elements
This table includes the elements used by the v.2 version of the Enterprise Mode schema.
<table>
<thead>
<tr class="header">
<th>Element</th>
<th>Description</th>
<th>Supported browser</th>
</tr>
</thead>
<tbody>
<tr>
<td>&lt;site-list&gt;</td>
<td>A new root node with this text is using the updated v.2 version of the schema. It replaces &lt;rules&gt;.
<p><b>Example</b>
<pre class="syntax">
&lt;site-list version=&quot;205&quot;&gt;
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;open-in&gt;IE11&lt;/open-in&gt;
&lt;/site&gt;
&lt;/site-list&gt;</pre></td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>&lt;site&gt;</td>
<td>A unique entry added for each site you want to put on the Enterprise Mode site list. The first &lt;site&gt; element will overrule any additional &lt;site&gt; elements that use the same value for the &lt;url&gt; element.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;compat-mode&gt;default&lt;/compat-mode&gt;
&lt;open-in&gt;none&lt;/open-in&gt;
&lt;/site&gt;</pre>
<strong>-or-</strong>
<p>For IPv4 ranges:<pre class="syntax">&lt;site url=&quot;10.122.34.99:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
<strong>-or-</strong>
<p>For IPv6 ranges:<pre class="syntax">&lt;site url=&quot;[10.122.34.99]:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
You can also use the self-closing version, &lt;url=&quot;contoso.com&quot; /&gt;, which also sets:
<ul>
<li>&lt;compat-mode&gt;default&lt;/compat-mode&gt;</li>
<li>&lt;open-in&gt;none&lt;/open-in&gt;</li>
</ul></td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>&lt;compat-mode&gt;</td>
<td>A child element that controls what compatibility setting is used for specific sites or domains. This element is only supported in IE11.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;/site&gt;</pre>
<strong>-or-</strong>
<p>For IPv4 ranges:<pre class="syntax">&lt;site url=&quot;10.122.34.99:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
<strong>-or-</strong>
<p>For IPv6 ranges:<pre class="syntax">&lt;site url=&quot;[10.122.34.99]:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
Where:
<ul>
<li><b>IE8Enterprise.</b> Loads the site in IE8 Enterprise Mode.<br>This element is required for sites included in the <b>EmIE</b> section of the v.1 schema and is needed to load in IE8 Enterprise Mode.</li><p>
<li><b>IE7Enterprise.</b> Loads the site in IE7 Enterprise Mode.<br>This element is required for sites included in the <b>EmIE</b> section of the v.1 schema and is needed to load in IE7 Enterprise Mode.<p><b>Important</b><br>This tag replaces the combination of the <code>&quot;forceCompatView&quot;=&quot;true&quot;</code> attribute and the list of sites specified in the EmIE section of the v.1 version of the schema.</li><p>
<li><b>IE<i>[x]</i>.</b> Where <i>[x]</i> is the document mode number into which the site loads.</li><p>
<li><b>Default or not specified.</b> Loads the site using the default compatibility mode for the page. In this situation, X-UA-compatible meta tags or HTTP headers are honored.</li>
</ul></td>
<td>Internet Explorer 11</td>
</tr>
<tr>
<td>&lt;open-in&gt;</td>
<td>A child element that controls what browser is used for sites. This element supports the <b>Open in IE11</b> or <b>Open in Microsoft Edge</b> experiences, for devices running Windows 10.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;open-in&gt;none&lt;/open-in&gt;
&lt;/site&gt;</pre><p>
Where:
<ul>
<li><b>IE11.</b> Opens the site in IE11, regardless of which browser is opened by the employee.</li><p>
<li><b>MSEdge.</b> Opens the site in Microsoft Edge, regardless of which browser is opened by the employee.</li><p>
<li><b>None or not specified.</b> Opens in whatever browser the employee chooses.</li>
</ul></td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
</table>
### Updated schema attributes
The &lt;url&gt; attribute, as part of the &lt;site&gt; element in the v.2 version of the schema, replaces the &lt;domain&gt; element from the v.1 version of the schema.
<table>
<thead>
<tr class="header">
<th>Attribute</th>
<th>Description</th>
<th>Supported browser</th>
</tr>
</thead>
<tbody>
<tr>
<td>allow-redirect</td>
<td>A boolean attribute of the &lt;open-in&gt; element that controls the behavior for redirected sites. Setting this attribute to &quot;true&quot; indicates that the site will open in IE11 or Microsoft Edge even if the site is navigated to as part of a HTTP or meta refresh redirection chain. Omitting the attribute is equivalent to &quot;false&quot; (sites in redirect chain will not open in another browser).
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com/travel&quot;&gt;
&lt;open-in allow-redirect=&quot;true&quot;&gt;IE11&lt;/open-in&gt;
&lt;/site&gt;</pre>
In this example, if <a href="https://contoso.com/travel" data-raw-source="https://contoso.com/travel">https://contoso.com/travel</a> is encountered in a redirect chain in Microsoft Edge, it will be opened in Internet Explorer.</td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>version</td>
<td>Specifies the version of the Enterprise Mode Site List. This attribute is supported for the &lt;site-list&gt; element.</td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>url</td>
<td>Specifies the URL (and port number using standard port conventions) to which the child elements apply. The URL can be a domain, sub-domain, or any path URL.
<br><b>Note</b><br>
Make sure that you don&#39;t specify a protocol. Using &lt;site url=&quot;contoso.com&quot;&gt; applies to both <a href="https://contoso.com" data-raw-source="https://contoso.com">https://contoso.com</a> and <a href="https://contoso.com" data-raw-source="https://contoso.com">https://contoso.com</a>.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;open-in&gt;IE11&lt;/open-in&gt;
&lt;/site&gt;</pre>
In this example, going to <a href="https://contoso.com:8080" data-raw-source="https://contoso.com:8080">https://contoso.com:8080</a> using Microsoft Edge, causes the site to open in IE11 and load in IE8 Enterprise Mode.</td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
</table>
### Deprecated attributes
These v.1 version schema attributes have been deprecated in the v.2 version of the schema:
<table>
<thead>
<tr class="header">
<th>Deprecated attribute</th>
<th>New attribute</th>
<th>Replacement example</th>
</tr>
</thead>
<tbody>
<tr>
<td>&lt;forceCompatView&gt;</td>
<td>&lt;compat-mode&gt;</td>
<td>Replace &lt;forceCompatView=&quot;true&quot;&gt; with &lt;compat-mode&gt;IE7Enterprise&lt;/compat-mode&gt;</td>
</tr>
<tr>
<td>&lt;docMode&gt;</td>
<td>&lt;compat-mode&gt;</td>
<td>Replace &lt;docMode=&quot;IE5&quot;&gt; with &lt;compat-mode&gt;IE5&lt;/compat-mode&gt;</td>
</tr>
<tr>
<td>&lt;doNotTransition&gt;</td>
<td>&lt;open-in&gt;</td>
<td>Replace &lt;doNotTransition=&quot;true&quot;&gt; with &lt;open-in&gt;none&lt;/open-in&gt;</td>
</tr>
<tr>
<td>&lt;domain&gt; and &lt;path&gt;</td>
<td>&lt;site&gt;</td>
<td>Replace:
<pre class="syntax">
&lt;emie&gt;
&lt;domain exclude=&quot;false&quot;&gt;contoso.com&lt;/domain&gt;
&lt;/emie&gt;</pre>
With:
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;/&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;/site&gt;</pre>
<b>-AND-</b><p>
Replace:
<pre class="syntax">
&lt;emie&gt;
&lt;domain exclude=&quot;true&quot;&gt;contoso.com
&lt;path exclude=&quot;false&quot; forceCompatView=&quot;true&quot;&gt;/about&lt;/path&gt;
&lt;/domain&gt;
&lt;/emie&gt;</pre>
With:
<pre class="syntax">
&lt;site url=&quot;contoso.com/about&quot;&gt;
&lt;compat-mode&gt;IE7Enterprise&lt;/compat-mode&gt;
&lt;/site&gt;</pre></td>
</tr>
</table>
While the old, replaced attributes aren't supported in the v.2 version of the schema, they'll continue to work in the v.1 version of the schema. If, however, you're using the v.2 version of the schema and these attributes are still there, the v.2 version schema takes precedence. We don’t recommend combining the two schemas, and instead recommend that you move to the v.2 version of the schema to take advantage of the new features.
**Important**<br>
Saving your v.1 version of the file using the new Enterprise Mode Site List Manager (schema v.2) automatically updates the XML to the new v.2 version of the schema.
### What not to include in your schema
We recommend that you not add any of the following items to your schema because they can make your compatibility list behave in unexpected ways:
- Don’t use protocols. For example, https://, https://, or custom protocols. They break parsing.
- Don’t use wildcards.
- Don’t use query strings, ampersands break parsing.
## Related topics
- [Use the Enterprise Mode Site List Manager](use-the-enterprise-mode-site-list-manager.md)
---
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.pagetype: appcompat
description: Use the Enterprise Mode Site List Manager to create and update your Enterprise Mode site list for devices running Windows 10.
author: lomayor
ms.prod: ie11
ms.assetid: 909ca359-5654-4df9-b9fb-921232fc05f5
ms.reviewer:
audience: itpro
manager: dansimp
ms.author: lomayor
title: Enterprise Mode schema v.2 guidance (Internet Explorer 11 for IT Pros)
ms.sitesec: library
ms.date: 12/04/2017
---
# Enterprise Mode schema v.2 guidance
**Applies to:**
- Windows 10
- Windows 8.1
- Windows 7
Use the Enterprise Mode Site List Manager to create and update your site list for devices running Windows 7, Windows 8.1, and Windows 10, using the version 2.0 (v.2) of the Enterprise Mode schema. If you don't want to use the Enterprise Mode Site List Manager, you also have the option to update your XML schema using Notepad, or any other XML-editing app.
**Important**<br>
If you're running Windows 7 or Windows 8.1 and you've been using the version 1.0 (v.1) of the schema, you can continue to do so, but you won't get the benefits that come with the updated schema. For info about the v.1 schema, see [Enterprise Mode schema v.1 guidance](enterprise-mode-schema-version-1-guidance.md).
## Enterprise Mode schema v.2 updates
Because of the schema changes, you can't combine the old version (v.1) with the new version (v.2) of the schema. If you look at your XML file, you can tell which version you're using by:
- &lt;rules&gt;. If your schema root node includes this key, you're using the v.1 version of the schema.
- &lt;site-list&gt;. If your schema root node includes this key, you're using the v.2 version of the schema.
You can continue to use the v.1 version of the schema on Windows 10, but you won't have the benefits of the new v.2 version schema updates and new features. Additionally, saving the v.1 version of the schema in the new Enterprise Mode Site List Manager (schema v.2) automatically updates the file to use the v.2 version of the schema.
### Enterprise Mode v.2 schema example
The following is an example of the v.2 version of the Enterprise Mode schema.
**Important**<br>
Make sure that you don't specify a protocol when adding your URLs. Using a URL like `<url="contoso.com">`, automatically applies to both https://contoso.com and https://contoso.com.
``` xml
<site-list version="205">
<!--- File creation header --->
<created-by>
<tool>EnterpriseSitelistManager</tool>
<version>10240</version>
<date-created>20150728.135021</date-created>
</created-by>
<!--- Begin Site List --->
<site url="www.cpandl.com">
<compat-mode>IE8Enterprise</compat-mode>
<open-in>MSEdge</open-in>
</site>
<site url="www.woodgrovebank.com">
<compat-mode>default</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="adatum.com">
<compat-mode>IE7Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="contoso.com">
<compat-mode>default</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="relecloud.com"/>
<compat-mode>default</compat-mode>
<open-in>none</open-in>
<site url="relecloud.com/about">
<compat-mode>IE8Enterprise"</compat-mode>
</site>
<site url="contoso.com/travel">
<compat-mode>IE7</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="fabrikam.com">
<compat-mode>IE8Enterprise</compat-mode>
<open-in>IE11</open-in>
</site>
<site url="fabrikam.com/products">
<compat-mode>IE7</compat-mode>
<open-in>IE11</open-in>
</site>
</site-list>
```
### Updated schema elements
This table includes the elements used by the v.2 version of the Enterprise Mode schema.
<table>
<thead>
<tr class="header">
<th>Element</th>
<th>Description</th>
<th>Supported browser</th>
</tr>
</thead>
<tbody>
<tr>
<td>&lt;site-list&gt;</td>
<td>A new root node with this text is using the updated v.2 version of the schema. It replaces &lt;rules&gt;.
<p><b>Example</b>
<pre class="syntax">
&lt;site-list version=&quot;205&quot;&gt;
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;open-in&gt;IE11&lt;/open-in&gt;
&lt;/site&gt;
&lt;/site-list&gt;</pre></td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>&lt;site&gt;</td>
<td>A unique entry added for each site you want to put on the Enterprise Mode site list. The first &lt;site&gt; element will overrule any additional &lt;site&gt; elements that use the same value for the &lt;url&gt; element.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;compat-mode&gt;default&lt;/compat-mode&gt;
&lt;open-in&gt;none&lt;/open-in&gt;
&lt;/site&gt;</pre>
<strong>-or-</strong>
<p>For IPv4 ranges:<pre class="syntax">&lt;site url=&quot;10.122.34.99:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
<strong>-or-</strong>
<p>For IPv6 ranges:<pre class="syntax">&lt;site url=&quot;[10.122.34.99]:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
You can also use the self-closing version, &lt;url=&quot;contoso.com&quot; /&gt;, which also sets:
<ul>
<li>&lt;compat-mode&gt;default&lt;/compat-mode&gt;</li>
<li>&lt;open-in&gt;none&lt;/open-in&gt;</li>
</ul></td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>&lt;compat-mode&gt;</td>
<td>A child element that controls what compatibility setting is used for specific sites or domains. This element is only supported in IE11.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;/site&gt;</pre>
<strong>-or-</strong>
<p>For IPv4 ranges:<pre class="syntax">&lt;site url=&quot;10.122.34.99:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
<strong>-or-</strong>
<p>For IPv6 ranges:<pre class="syntax">&lt;site url=&quot;[10.122.34.99]:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;site&gt;</pre><p>
Where:
<ul>
<li><b>IE8Enterprise.</b> Loads the site in IE8 Enterprise Mode.<br>This element is required for sites included in the <b>EmIE</b> section of the v.1 schema and is needed to load in IE8 Enterprise Mode.</li><p>
<li><b>IE7Enterprise.</b> Loads the site in IE7 Enterprise Mode.<br>This element is required for sites included in the <b>EmIE</b> section of the v.1 schema and is needed to load in IE7 Enterprise Mode.<p><b>Important</b><br>This tag replaces the combination of the <code>&quot;forceCompatView&quot;=&quot;true&quot;</code> attribute and the list of sites specified in the EmIE section of the v.1 version of the schema.</li><p>
<li><b>IE<i>[x]</i>.</b> Where <i>[x]</i> is the document mode number into which the site loads.</li><p>
<li><b>Default or not specified.</b> Loads the site using the default compatibility mode for the page. In this situation, X-UA-compatible meta tags or HTTP headers are honored.</li>
</ul></td>
<td>Internet Explorer 11</td>
</tr>
<tr>
<td>&lt;open-in&gt;</td>
<td>A child element that controls what browser is used for sites. This element supports the <b>Open in IE11</b> or <b>Open in Microsoft Edge</b> experiences, for devices running Windows 10.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;&gt;
&lt;open-in&gt;none&lt;/open-in&gt;
&lt;/site&gt;</pre><p>
Where:
<ul>
<li><b>IE11.</b> Opens the site in IE11, regardless of which browser is opened by the employee.</li><p>
<li><b>MSEdge.</b> Opens the site in Microsoft Edge, regardless of which browser is opened by the employee.</li><p>
<li><b>None or not specified.</b> Opens in whatever browser the employee chooses.</li>
</ul></td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
</table>
### Updated schema attributes
The &lt;url&gt; attribute, as part of the &lt;site&gt; element in the v.2 version of the schema, replaces the &lt;domain&gt; element from the v.1 version of the schema.
<table>
<thead>
<tr class="header">
<th>Attribute</th>
<th>Description</th>
<th>Supported browser</th>
</tr>
</thead>
<tbody>
<tr>
<td>allow-redirect</td>
<td>A boolean attribute of the &lt;open-in&gt; element that controls the behavior for redirected sites. Setting this attribute to &quot;true&quot; indicates that the site will open in IE11 or Microsoft Edge even if the site is navigated to as part of a HTTP or meta refresh redirection chain. Omitting the attribute is equivalent to &quot;false&quot; (sites in redirect chain will not open in another browser).
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com/travel&quot;&gt;
&lt;open-in allow-redirect=&quot;true&quot;&gt;IE11&lt;/open-in&gt;
&lt;/site&gt;</pre>
In this example, if <a href="https://contoso.com/travel" data-raw-source="https://contoso.com/travel">https://contoso.com/travel</a> is encountered in a redirect chain in Microsoft Edge, it will be opened in Internet Explorer.</td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>version</td>
<td>Specifies the version of the Enterprise Mode Site List. This attribute is supported for the &lt;site-list&gt; element.</td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
<tr>
<td>url</td>
<td>Specifies the URL (and port number using standard port conventions) to which the child elements apply. The URL can be a domain, sub-domain, or any path URL.
<br><b>Note</b><br>
Make sure that you don&#39;t specify a protocol. Using &lt;site url=&quot;contoso.com&quot;&gt; applies to both <a href="https://contoso.com" data-raw-source="https://contoso.com">https://contoso.com</a> and <a href="https://contoso.com" data-raw-source="https://contoso.com">https://contoso.com</a>.
<p><b>Example</b>
<pre class="syntax">
&lt;site url=&quot;contoso.com:8080&quot;&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;open-in&gt;IE11&lt;/open-in&gt;
&lt;/site&gt;</pre>
In this example, going to <a href="https://contoso.com:8080" data-raw-source="https://contoso.com:8080">https://contoso.com:8080</a> using Microsoft Edge, causes the site to open in IE11 and load in IE8 Enterprise Mode.</td>
<td>Internet Explorer 11 and Microsoft Edge</td>
</tr>
</table>
### Deprecated attributes
These v.1 version schema attributes have been deprecated in the v.2 version of the schema:
<table>
<thead>
<tr class="header">
<th>Deprecated attribute</th>
<th>New attribute</th>
<th>Replacement example</th>
</tr>
</thead>
<tbody>
<tr>
<td>&lt;forceCompatView&gt;</td>
<td>&lt;compat-mode&gt;</td>
<td>Replace &lt;forceCompatView=&quot;true&quot;&gt; with &lt;compat-mode&gt;IE7Enterprise&lt;/compat-mode&gt;</td>
</tr>
<tr>
<td>&lt;docMode&gt;</td>
<td>&lt;compat-mode&gt;</td>
<td>Replace &lt;docMode=&quot;IE5&quot;&gt; with &lt;compat-mode&gt;IE5&lt;/compat-mode&gt;</td>
</tr>
<tr>
<td>&lt;doNotTransition&gt;</td>
<td>&lt;open-in&gt;</td>
<td>Replace &lt;doNotTransition=&quot;true&quot;&gt; with &lt;open-in&gt;none&lt;/open-in&gt;</td>
</tr>
<tr>
<td>&lt;domain&gt; and &lt;path&gt;</td>
<td>&lt;site&gt;</td>
<td>Replace:
<pre class="syntax">
&lt;emie&gt;
&lt;domain exclude=&quot;false&quot;&gt;contoso.com&lt;/domain&gt;
&lt;/emie&gt;</pre>
With:
<pre class="syntax">
&lt;site url=&quot;contoso.com&quot;/&gt;
&lt;compat-mode&gt;IE8Enterprise&lt;/compat-mode&gt;
&lt;/site&gt;</pre>
<b>-AND-</b><p>
Replace:
<pre class="syntax">
&lt;emie&gt;
&lt;domain exclude=&quot;true&quot;&gt;contoso.com
&lt;path exclude=&quot;false&quot; forceCompatView=&quot;true&quot;&gt;/about&lt;/path&gt;
&lt;/domain&gt;
&lt;/emie&gt;</pre>
With:
<pre class="syntax">
&lt;site url=&quot;contoso.com/about&quot;&gt;
&lt;compat-mode&gt;IE7Enterprise&lt;/compat-mode&gt;
&lt;/site&gt;</pre></td>
</tr>
</table>
While the old, replaced attributes aren't supported in the v.2 version of the schema, they'll continue to work in the v.1 version of the schema. If, however, you're using the v.2 version of the schema and these attributes are still there, the v.2 version schema takes precedence. We don’t recommend combining the two schemas, and instead recommend that you move to the v.2 version of the schema to take advantage of the new features.
**Important**<br>
Saving your v.1 version of the file using the new Enterprise Mode Site List Manager (schema v.2) automatically updates the XML to the new v.2 version of the schema.
### What not to include in your schema
We recommend that you not add any of the following items to your schema because they can make your compatibility list behave in unexpected ways:
- Don’t use protocols. For example, https://, https://, or custom protocols. They break parsing.
- Don’t use wildcards.
- Don’t use query strings, ampersands break parsing.
## Related topics
- [Use the Enterprise Mode Site List Manager](use-the-enterprise-mode-site-list-manager.md)

2
devices/hololens/hololens-encryption.md
View File

@ -102,6 +102,6 @@ Provisioning packages are files created by the Windows Configuration Designer to
Encryption is silent on HoloLens. To verify the device encryption status:
- On HoloLens, go to **Settings** > **System** > **About**. **BitLocker** is **enabled** if the device is encrypted.
- On HoloLens, go to **Settings** > **System** > **About**. **BitLocker** is **enabled** if the device is encrypted.
![About screen showing BitLocker enabled](images/about-encryption.png)

6
devices/hololens/hololens-updates.md
View File

@ -22,9 +22,9 @@ manager: dansimp
For a complete list of Update policies, see [Policies supported by Windows Holographic for Business](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider#a-href-idhololenspoliciesapolicies-supported-by-windows-holographic-for-business).
To configure how and when updates are applied, use the following policies:
- [Update/AllowAutoUpdate](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-allowautoupdate)
- [Update/ScheduledInstallDay](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-scheduledinstallday)
- [Update/ScheduledInstallTime](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-scheduledinstalltime)
- [Update/AllowAutoUpdate](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-allowautoupdate)
- [Update/ScheduledInstallDay](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-scheduledinstallday)
- [Update/ScheduledInstallTime](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-scheduledinstalltime)
To turn off the automatic check for updates, set the following policy to value **5** – Turn off Automatic Updates:
- [Update/AllowAutoUpdate](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-allowautoupdate)

2
devices/surface-hub/surface-hub-2s-setup.md
View File

@ -97,4 +97,4 @@ If you insert a USB thumb drive with a provisioning package into one of the USB
![* Select a device account and friendly name from your configuration file*](images/sh2-run14.png) <br>
4. Follow the instructions to complete first time Setup.
4. Follow the instructions to complete first time Setup.

14
devices/surface-hub/surface-hub-update-history.md
View File

@ -26,6 +26,18 @@ Please refer to the “[Surface Hub Important Information](https://support.micro
## Windows 10 Team Creators Update 1703
<details>
<summary>June 18, 2019—update for Team edition based on KB4503289* (OS Build 15063.1897)</summary>
This update to the Surface Hub includes quality improvements and security fixes. Key updates to Surface Hub, not already outlined in [Windows 10 Update History](https://support.microsoft.com/help/4018124/windows-10-update-history), include:
* Addresses an issue with log collection for Microsoft Surface Hub 2S.
* Addresses an issue preventing a user from signing in to a Microsoft Surface Hub device with an Azure Active Directory account. This issue occurs because a previous session did not end successfully.
Please refer to the [Surface Hub Admin guide](https://docs.microsoft.com/surface-hub/) for enabling/disabling device features and services.
*[KB4503289](https://support.microsoft.com/help/4503289)
</details>
<details>
<summary>May 28, 2019—update for Team edition based on KB4499162* (OS Build 15063.1835)</summary>
@ -484,4 +496,4 @@ This update to the Surface Hub includes quality improvements and security fixes.
* [Windows 10 November update: FAQ](http://windows.microsoft.com/windows-10/windows-update-faq)
* [Microsoft Surface update history](http://go.microsoft.com/fwlink/p/?LinkId=724327)
* [Microsoft Lumia update history](http://go.microsoft.com/fwlink/p/?LinkId=785968)
* [Get Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=616447)
* [Get Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=616447)

5
devices/surface-hub/whiteboard-collaboration.md
View File

@ -34,7 +34,7 @@ To get Whiteboard to Whiteboard collaboration up and running, you’ll need to m
- Currently not utilizing Office 365 Germany or Office 365 operated by 21Vianet
- Surface Hub needs to be updated to Windows 10, version 1607 or newer
- Port 443 needs to be open since Whiteboard makes standard https requests
- Whiteboard.ms, wbd.ms, \*.onenote.com, and your company's SharePoint tenant domain URLs need to be whitelisted for proxies
- Whiteboard.ms, whiteboard.microsoft.com, wbd.ms, \*.onenote.com, and your company's SharePoint tenant domain URLs need to be whitelisted for proxies
>[!NOTE]
@ -68,4 +68,5 @@ After you’re done, you can export a copy of the Whiteboard collaboration for y
## Related topics
- [Windows 10 Creators Update for Surface Hub](https://www.microsoft.com/surface/support/surface-hub/windows-10-creators-update-surface-hub)
- [Support documentation for Microsoft Whiteboard](https://support.office.com/en-us/article/Whiteboard-Help-0c0f2aa0-b1bb-491c-b814-fd22de4d7c01)
- [Support documentation for Microsoft Whiteboard](https://support.office.com/article/Whiteboard-Help-0c0f2aa0-b1bb-491c-b814-fd22de4d7c01)

8
devices/surface/step-by-step-surface-deployment-accelerator.md
View File

@ -61,8 +61,8 @@ The following steps show you how to create a deployment share for Windows 10 tha
>[!NOTE]
>As of SDA version 1.96.0405, SDA will install only the components of the Windows ADK that are required for deployment, as follows:
> * Deployment tools
> * User State Migration Tool (USMT)
> * Windows Preinstallation Environment (WinPE)
> * User State Migration Tool (USMT)
> * Windows Preinstallation Environment (WinPE)
> [!NOTE]
> As of SDA version 1.96.0405, SDA will install and use MDT 2013 Update 2. Earlier versions of SDA are compatible only with MDT 2013 Update 1.
@ -75,11 +75,11 @@ The following steps show you how to create a deployment share for Windows 10 tha
- **Local Path** – Specify or browse to a location on the local storage device where you would like to store the deployment share files for the Windows 10 SDA deployment share. For example, **E:\\SDAWin10\\** is the location specified in Figure 3.
- **Share Name** – Specify a name for the file share that will be used to access the deployment share on this server from the network. For example, **SDAWin10** is the deployment share name shown in Figure 3. The local path folder is automatically shared by the SDA scripts under this name to the group **Everyone** with a permission level of **Full Control**.
- **Share Name** – Specify a name for the file share that will be used to access the deployment share on this server from the network. For example, **SDAWin10** is the deployment share name shown in Figure 3. The local path folder is automatically shared by the SDA scripts under this name to the group **Everyone** with a permission level of **Full Control**.
- **Windows 10 Deployment Services**
- Select the **Import boot media into the local Windows Deployment Service** check box if you would like to boot your Surface devices from the network to perform the Windows deployment. Windows Deployment Services must be installed and configured to respond to PXE boot requests. See [Windows Deployment Services Getting Started Guide for Windows Server 2012](https://technet.microsoft.com/library/jj648426.aspx) for more information about how to configure Windows Deployment Services for PXE boot.
- Select the **Import boot media into the local Windows Deployment Service** check box if you would like to boot your Surface devices from the network to perform the Windows deployment. Windows Deployment Services must be installed and configured to respond to PXE boot requests. See [Windows Deployment Services Getting Started Guide for Windows Server 2012](https://technet.microsoft.com/library/jj648426.aspx) for more information about how to configure Windows Deployment Services for PXE boot.
- **Windows 10 Source Files**

321
devices/surface/use-system-center-configuration-manager-to-manage-devices-with-semm.md
View File

@ -103,39 +103,45 @@ The sample scripts include examples of how to set Surface UEFI settings and how
### Specify certificate and package names
The first region of the script that you need to modify is the portion that specifies and loads the SEMM certificate, and also indicates the names for the SEMM configuration package and SEMM reset package. The certificate and package names are specified on lines 56 through 67 in the ConfigureSEMM.ps1 script:
The first region of the script that you need to modify is the portion that specifies and loads the SEMM certificate, and also indicates SurfaceUEFIManager version, the names for the SEMM configuration package and SEMM reset package. The certificate name and SurfaceUEFIManager version are specified on lines 56 through 73 in the ConfigureSEMM.ps1 script:
```
56 $WorkingDirPath = split-path -parent $MyInvocation.MyCommand.Definition
57 $packageRoot = "$WorkingDirPath\Config"
58
59 if (-not (Test-Path $packageRoot)) { New-Item -ItemType Directory -Force -Path $packageRoot }
60 Copy-Item "$WorkingDirPath\FabrikamOwnerSigner.pfx" $packageRoot
61
62 $privateOwnerKey = Join-Path -Path $packageRoot -ChildPath "FabrikamOwnerSigner.pfx"
63 $ownerPackageName = Join-Path -Path $packageRoot -ChildPath "FabrikamSignerProvisioningPackage.pkg"
64 $resetPackageName = Join-Path -Path $packageRoot -ChildPath "FabrikamUniversalResetPackage.pkg"
65
66 # If your PFX file requires a password then it can be set here, otherwise use a blank string.
67 $password = "1234"
58 $certName = "FabrikamSEMMSample.pfx"
59 $DllVersion = "2.26.136.0"
60
61 $certNameOnly = [System.IO.Path]::GetFileNameWithoutExtension($certName)
62 $ProvisioningPackage = $certNameOnly + "ProvisioningPackage.pkg"
63 $ResetPackage = $certNameOnly + "ResetPackage.pkg"
64
65 if (-not (Test-Path $packageRoot)) { New-Item -ItemType Directory -Force -Path $packageRoot }
66 Copy-Item "$WorkingDirPath\$certName" $packageRoot
67
68 $privateOwnerKey = Join-Path -Path $packageRoot -ChildPath $certName
69 $ownerPackageName = Join-Path -Path $packageRoot -ChildPath $ProvisioningPackage
70 $resetPackageName = Join-Path -Path $packageRoot -ChildPath $ResetPackage
71
72 # If your PFX file requires a password then it can be set here, otherwise use a blank string.
73 $password = "1234"
```
Replace the **FabrikamOwnerSigner.pfx** value for the **$privateOwnerKey** variable with the name of your SEMM Certificate file on both lines 60 and 62. The script will create a working directory (named Config) in the folder where your scripts are located, and will then copy the certificate file to this working directory.
Replace the **FabrikamSEMMSample.pfx** value for the **$certName** variable with the name of your SEMM Certificate file on line 58. The script will create a working directory (named Config) in the folder where your scripts are located, and will then copy the certificate file to this working directory.
Replace the **FabrikamSignerProvisioningPackage.pkg** and **FabrikamUniversalResetPackage.pkg** values on lines 63 and 64 to define the **$ownerPackageName** and **$resetPackageName** variables with your desired names for the SEMM configuration and reset packages. These packages will also be created in the Config directory and hold the configuration for Surface UEFI settings and permissions generated by the script.
Owner package and reset package will also be created in the Config directory and hold the configuration for Surface UEFI settings and permissions generated by the script.
On line 67, replace the value of the **$password** variable, from 1234, to the password for your certificate file. If a password is not required, delete the **1234** text.
On line 73, replace the value of the **$password** variable, from 1234, to the password for your certificate file. If a password is not required, delete the **1234** text.
>[!Note]
>The last two characters of the certificate thumbprint are required to enroll a device in SEMM. This script will display these digits to the user, which allows the user or technician to record these digits before the system reboots to enroll the device in SEMM. The script uses the following code, found on lines 144-149, to accomplish this:
>The last two characters of the certificate thumbprint are required to enroll a device in SEMM. This script will display these digits to the user, which allows the user or technician to record these digits before the system reboots to enroll the device in SEMM. The script uses the following code, found on lines 150-155, to accomplish this:
```
144 # Device owners will need the last two characters of the thumbprint to accept SEMM ownership.
145 # For convenience we get the thumbprint here and present to the user.
146 $pw = ConvertTo-SecureString $password -AsPlainText -Force
147 $certPrint = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
148 $certPrint.Import($privateOwnerKey, $pw, [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::DefaultKeySet)
149 Write-Host "Thumbprint =" $certPrint.Thumbprint
150 # Device owners will need the last two characters of the thumbprint to accept SEMM ownership.
151 # For convenience we get the thumbprint here and present to the user.
152 $pw = ConvertTo-SecureString $password -AsPlainText -Force
153 $certPrint = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
154 $certPrint.Import($privateOwnerKey, $pw, [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::DefaultKeySet)
155 Write-Host "Thumbprint =" $certPrint.Thumbprint
```
Administrators with access to the certificate file (.pfx) can read the thumbprint at any time by opening the .pfx file in CertMgr. To view the thumbprint with CertMgr, follow this process:
@ -153,46 +159,47 @@ Administrators with access to the certificate file (.pfx) can read the thumbprin
### Configure permissions
The first region of the script where you will specify the configuration for Surface UEFI is the **Configure Permissions** region. This region begins at line 202 in the sample script with the comment **# Configure Permissions** and continues to line 238. The following code fragment first sets permissions to all Surface UEFI settings so that they may be modified by SEMM only, then adds explicit permissions to allow the local user to modify the Surface UEFI password, TPM, and front and rear cameras:
The first region of the script where you will specify the configuration for Surface UEFI is the **Configure Permissions** region. This region begins at line 210 in the sample script with the comment **# Configure Permissions** and continues to line 247. The following code fragment first sets permissions to all Surface UEFI settings so that they may be modified by SEMM only, then adds explicit permissions to allow the local user to modify the Surface UEFI password, TPM, and front and rear cameras:
```
202 # Configure Permissions
203 foreach ($uefiV2 IN $surfaceDevices.Values) {
204 # Here we define which "identities" will be allowed to modify which settings
205 # PermissionSignerOwner = The primary SEMM enterprise owner identity
206 # PermissionLocal = The user when booting to the UEFI pre-boot GUI
207 # PermissionSignerUser, PermissionSignerUser1, PermissionSignerUser2 =
208 # Additional user identities created so that the signer owner
209 # can delegate permission control for some settings.
210 $ownerOnly = [Microsoft.Surface.IUefiSetting]::PermissionSignerOwner
211 $ownerAndLocalUser = ([Microsoft.Surface.IUefiSetting]::PermissionSignerOwner -bor [Microsoft.Surface.IUefiSetting]::PermissionLocal)
212
213 # Make all permissions owner only by default
214 foreach ($setting IN $uefiV2.Settings.Values) {
215 $setting.ConfiguredPermissionFlags = $ownerOnly
216 }
217 # Allow the local user to change their own password
218 $uefiV2.SettingsById[501].ConfiguredPermissionFlags = $ownerAndLocalUser
219
220 # Allow the local user to change the state of the TPM
221 $uefiV2.Settings["Trusted Platform Module (TPM)"].ConfiguredPermissionFlags = $ownerAndLocalUser
222
223 # Allow the local user to change the state of the Front and Rear cameras
224 $uefiV2.SettingsById[302].ConfiguredPermissionFlags = $ownerAndLocalUser
225 $uefiV2.SettingsById[304].ConfiguredPermissionFlags = $ownerAndLocalUser
226
227
228 # Create a unique package name based on family and LSV.
229 # We will choose a name that can be parsed by later scripts.
230 $packageName = $uefiV2.SurfaceUefiFamily + "^Permissions^" + $lsv + ".pkg"
231 $fullPackageName = Join-Path -Path $packageRoot -ChildPath $packageName
232
233 # Build and sign the Permission package then save it to a file.
234 $permissionPackageStream = $uefiV2.BuildAndSignPermissionPackage($privateOwnerKey, $password, "", $null, $lsv)
235 $permissionPackage = New-Object System.IO.Filestream($fullPackageName, [System.IO.FileMode]::CreateNew, [System.IO.FileAccess]::Write)
236 $permissionPackageStream.CopyTo($permissionPackage)
237 $permissionPackage.Close()
238 }
210 # Configure Permissions
211 foreach ($uefiV2 IN $surfaceDevices.Values) {
212 if ($uefiV2.SurfaceUefiFamily -eq $Device.Model) {
213 Write-Host "Configuring permissions"
214 Write-Host $Device.Model
215 Write-Host "======================="
216
217 # Here we define which "identities" will be allowed to modify which settings
218 # PermissionSignerOwner = The primary SEMM enterprise owner identity
219 # PermissionLocal = The user when booting to the UEFI pre-boot GUI
220 # PermissionSignerUser, PermissionSignerUser1, PermissionSignerUser2 =
221 # Additional user identities created so that the signer owner
222 # can delegate permission control for some settings.
223 $ownerOnly = [Microsoft.Surface.IUefiSetting]::PermissionSignerOwner
224 $ownerAndLocalUser = ([Microsoft.Surface.IUefiSetting]::PermissionSignerOwner -bor [Microsoft.Surface.IUefiSetting]::PermissionLocal)
225
226 # Make all permissions owner only by default
227 foreach ($setting IN $uefiV2.Settings.Values) {
228 $setting.ConfiguredPermissionFlags = $ownerOnly
229 }
230
231 # Allow the local user to change their own password
232 $uefiV2.SettingsById[501].ConfiguredPermissionFlags = $ownerAndLocalUser
233
234 Write-Host ""
235
236 # Create a unique package name based on family and LSV.
237 # We will choose a name that can be parsed by later scripts.
238 $packageName = $uefiV2.SurfaceUefiFamily + "^Permissions^" + $lsv + ".pkg"
239 $fullPackageName = Join-Path -Path $packageRoot -ChildPath $packageName
240
241 # Build and sign the Permission package then save it to a file.
242 $permissionPackageStream = $uefiV2.BuildAndSignPermissionPackage($privateOwnerKey, $password, "", $null, $lsv)
243 $permissionPackage = New-Object System.IO.Filestream($fullPackageName, [System.IO.FileMode]::CreateNew, [System.IO.FileAccess]::Write)
244 $permissionPackageStream.CopyTo($permissionPackage)
245 $permissionPackage.Close()
246 }
247 }
```
Each **$uefiV2** variable identifies a Surface UEFI setting by setting name or ID, and then configures the permissions to one of the following values:
@ -204,69 +211,169 @@ You can find information about the available settings names and IDs for Surface
### Configure settings
The second region of the script where you will specify the configuration for Surface UEFI is the **Configure Settings** region of the ConfigureSEMM.ps1 script, which configures whether each setting is enabled or disabled. The sample script includes instructions to set all settings to their default values. The script then provides explicit instructions to disable IPv6 for PXE Boot and to leave the Surface UEFI Administrator password unchanged. You can find this region beginning with the **# Configure Settings** comment at line 282 through line 312 in the sample script. The region appears as follows:
The second region of the script where you will specify the configuration for Surface UEFI is the **Configure Settings** region of the ConfigureSEMM.ps1 script, which configures whether each setting is enabled or disabled. The sample script includes instructions to set all settings to their default values. The script then provides explicit instructions to disable IPv6 for PXE Boot and to leave the Surface UEFI Administrator password unchanged. You can find this region beginning with the **# Configure Settings** comment at line 291 through line 335 in the sample script. The region appears as follows:
```
282 # Configure Settings
283 foreach ($uefiV2 IN $surfaceDevices.Values) {
284 # In this demo, we will start by setting every setting to the default factory setting.
285 # You may want to start by doing this in your scripts
286 # so that every setting gets set to a known state.
287 foreach ($setting IN $uefiV2.Settings.Values) {
288 $setting.ConfiguredValue = $setting.DefaultValue
289 }
290
291 # If you want to set something to a different value from the default,
292 # here are examples of how to accomplish this.
293 $uefiV2.Settings["IPv6 for PXE Boot"].ConfiguredValue = "Disabled"
294
295 # If you want to leave the setting unmodified, set it to $null
296 # PowerShell has issues setting things to $null so ClearConfiguredValue()
297 # is supplied to do this explicitly.
298 # Here is an example of leaving the UEFI administrator password as-is,
299 # even after we initially set it to factory default above.
300 $uefiV2.SettingsById[501].ClearConfiguredValue()
301
302 # Create a unique package name based on family and LSV.
303 # We will choose a name that can be parsed by later scripts.
304 $packageName = $uefiV2.SurfaceUefiFamily + "^Settings^" + $lsv + ".pkg"
305 $fullPackageName = Join-Path -Path $packageRoot -ChildPath $packageName
306
307 # Build and sign the Settings package then save it to a file.
308 $settingsPackageStream = $uefiV2.BuildAndSignSecuredSettingsPackage($privateOwnerKey, $password, "", $null, $lsv)
309 $settingsPackage = New-Object System.IO.Filestream($fullPackageName, [System.IO.FileMode]::CreateNew, [System.IO.FileAccess]::Write)
310 $settingsPackageStream.CopyTo($settingsPackage)
311 $settingsPackage.Close()
312 }
291 # Configure Settings
292 foreach ($uefiV2 IN $surfaceDevices.Values) {
293 if ($uefiV2.SurfaceUefiFamily -eq $Device.Model) {
294 Write-Host "Configuring settings"
295 Write-Host $Device.Model
296 Write-Host "===================="
297
298 # In this demo, we will start by setting every setting to the default factory setting.
299 # You may want to start by doing this in your scripts
300 # so that every setting gets set to a known state.
301 foreach ($setting IN $uefiV2.Settings.Values) {
302 $setting.ConfiguredValue = $setting.DefaultValue
303 }
304
305 $EnabledValue = "Enabled"
306 $DisabledValue = "Disabled"
307
308 # If you want to set something to a different value from the default,
309 # here are examples of how to accomplish this.
310 # This disables IPv6 PXE boot by name:
311 $uefiV2.Settings["IPv6 for PXE Boot"].ConfiguredValue = $DisabledValue
312
313 # This disables IPv6 PXE Boot by ID:
314 $uefiV2.SettingsById[400].ConfiguredValue = $DisabledValue
315
316 Write-Host ""
317
318 # If you want to leave the setting unmodified, set it to $null
319 # PowerShell has issues setting things to $null so ClearConfiguredValue()
320 # is supplied to do this explicitly.
321 # Here is an example of leaving the UEFI administrator password as-is,
322 # even after we initially set it to factory default above.
323 $uefiV2.SettingsById[501].ClearConfiguredValue()
324
325 # Create a unique package name based on family and LSV.
326 # We will choose a name that can be parsed by later scripts.
327 $packageName = $uefiV2.SurfaceUefiFamily + "^Settings^" + $lsv + ".pkg"
328 $fullPackageName = Join-Path -Path $packageRoot -ChildPath $packageName
329
330 # Build and sign the Settings package then save it to a file.
331 $settingsPackageStream = $uefiV2.BuildAndSignSecuredSettingsPackage($privateOwnerKey, $password, "", $null, $lsv)
332 $settingsPackage = New-Object System.IO.Filestream($fullPackageName, [System.IO.FileMode]::CreateNew, [System.IO.FileAccess]::Write)
333 $settingsPackageStream.CopyTo($settingsPackage)
334 $settingsPackage.Close()
335 }
```
Like the permissions set in the **Configure Permissions** section of the script, the configuration of each Surface UEFI setting is performed by defining the **$uefiV2** variable. For each line defining the **$uefiV2** variable, a Surface UEFI setting is identified by setting name or ID and the configured value is set to **Enabled** or **Disabled**.
If you do not want to alter the configuration of a Surface UEFI setting, for example to ensure that the Surface UEFI administrator password is not cleared by the action of resetting all Surface UEFI settings to their default, you can use **ClearConfiguredValue()** to enforce that this setting will not be altered. In the sample script, this is used on line 300 to prevent the clearing of the Surface UEFI Administrator password, identified in the sample script by its setting ID, **501**.
If you do not want to alter the configuration of a Surface UEFI setting, for example to ensure that the Surface UEFI administrator password is not cleared by the action of resetting all Surface UEFI settings to their default, you can use **ClearConfiguredValue()** to enforce that this setting will not be altered. In the sample script, this is used on line 323 to prevent the clearing of the Surface UEFI Administrator password, identified in the sample script by its setting ID, **501**.
You can find information about the available settings names and IDs for Surface UEFI in the [Settings Names and IDs](#settings-names-and-ids) section later in this article.
### Settings registry key
To identify enrolled systems for Configuration Manager, the ConfigureSEMM.ps1 script writes a registry key that can be used to identify enrolled systems as having been installed with the SEMM configuration script. This key can be found at the following location:
To identify enrolled systems for Configuration Manager, the ConfigureSEMM.ps1 script writes registry keys that can be used to identify enrolled systems as having been installed with the SEMM configuration script. These keys can be found at the following location:
`HKLM\SOFTWARE\Microsoft\Surface\SEMM\Enabled_Version1000`
`HKLM\SOFTWARE\Microsoft\Surface\SEMM`
The following code fragment, found on lines 352-363, is used to write this registry key:
The following code fragment, found on lines 380-477, is used to write these registry keys:
```
352 $SurfaceRegKey = "HKLM:\SOFTWARE\Microsoft\Surface\SEMM"
353 New-RegKey $SurfaceRegKey
354 $SurfaceRegValue = Get-ItemProperty $SurfaceRegKey Enabled_Version1000 -ErrorAction SilentlyContinue
355
356 If ($SurfaceRegValue -eq $null)
357 {
358 New-ItemProperty -Path $SurfaceRegKey -Name Enabled_Version1000 -PropertyType String -Value 1 | Out-Null
359 }
360 Else
361 {
362 Set-ItemProperty -Path $SurfaceRegKey -Name Enabled_Version1000 -Value 1
363 }
380 # For SCCM or other management solutions that wish to know what version is applied, tattoo the LSV and current DateTime (in UTC) to the registry:
381 $UTCDate = (Get-Date).ToUniversalTime().ToString()
382 $certIssuer = $certPrint.Issuer
383 $certSubject = $certPrint.Subject
384
385 $SurfaceRegKey = "HKLM:\SOFTWARE\Microsoft\Surface\SEMM"
386 New-RegKey $SurfaceRegKey
387 $LSVRegValue = Get-ItemProperty $SurfaceRegKey LSV -ErrorAction SilentlyContinue
388 $DateTimeRegValue = Get-ItemProperty $SurfaceRegKey LastConfiguredUTC -ErrorAction SilentlyContinue
389 $OwnershipSessionIdRegValue = Get-ItemProperty $SurfaceRegKey OwnershipSessionId -ErrorAction SilentlyContinue
390 $PermissionSessionIdRegValue = Get-ItemProperty $SurfaceRegKey PermissionSessionId -ErrorAction SilentlyContinue
391 $SettingsSessionIdRegValue = Get-ItemProperty $SurfaceRegKey SettingsSessionId -ErrorAction SilentlyContinue
392 $IsResetRegValue = Get-ItemProperty $SurfaceRegKey IsReset -ErrorAction SilentlyContinue
393 $certUsedRegValue = Get-ItemProperty $SurfaceRegKey CertName -ErrorAction SilentlyContinue
394 $certIssuerRegValue = Get-ItemProperty $SurfaceRegKey CertIssuer -ErrorAction SilentlyContinue
395 $certSubjectRegValue = Get-ItemProperty $SurfaceRegKey CertSubject -ErrorAction SilentlyContinue
396
397
398 If ($LSVRegValue -eq $null)
399 {
400 New-ItemProperty -Path $SurfaceRegKey -Name LSV -PropertyType DWORD -Value $lsv | Out-Null
401 }
402 Else
403 {
404 Set-ItemProperty -Path $SurfaceRegKey -Name LSV -Value $lsv
405 }
406
407 If ($DateTimeRegValue -eq $null)
408 {
409 New-ItemProperty -Path $SurfaceRegKey -Name LastConfiguredUTC -PropertyType String -Value $UTCDate | Out-Null
410 }
411 Else
412 {
413 Set-ItemProperty -Path $SurfaceRegKey -Name LastConfiguredUTC -Value $UTCDate
414 }
415
416 If ($OwnershipSessionIdRegValue -eq $null)
417 {
418 New-ItemProperty -Path $SurfaceRegKey -Name OwnershipSessionId -PropertyType String -Value $ownerSessionIdValue | Out-Null
419 }
420 Else
421 {
422 Set-ItemProperty -Path $SurfaceRegKey -Name OwnershipSessionId -Value $ownerSessionIdValue
423 }
424
425 If ($PermissionSessionIdRegValue -eq $null)
426 {
427 New-ItemProperty -Path $SurfaceRegKey -Name PermissionSessionId -PropertyType String -Value $permissionSessionIdValue | Out-Null
428 }
429 Else
430 {
431 Set-ItemProperty -Path $SurfaceRegKey -Name PermissionSessionId -Value $permissionSessionIdValue
432 }
433
434 If ($SettingsSessionIdRegValue -eq $null)
435 {
436 New-ItemProperty -Path $SurfaceRegKey -Name SettingsSessionId -PropertyType String -Value $settingsSessionIdValue | Out-Null
437 }
438 Else
439 {
440 Set-ItemProperty -Path $SurfaceRegKey -Name SettingsSessionId -Value $settingsSessionIdValue
441 }
442
443 If ($IsResetRegValue -eq $null)
444 {
445 New-ItemProperty -Path $SurfaceRegKey -Name IsReset -PropertyType DWORD -Value 0 | Out-Null
446 }
447 Else
448 {
449 Set-ItemProperty -Path $SurfaceRegKey -Name IsReset -Value 0
450 }
451
452 If ($certUsedRegValue -eq $null)
453 {
454 New-ItemProperty -Path $SurfaceRegKey -Name CertName -PropertyType String -Value $certName | Out-Null
455 }
456 Else
457 {
458 Set-ItemProperty -Path $SurfaceRegKey -Name CertName -Value $certName
459 }
460
461 If ($certIssuerRegValue -eq $null)
462 {
463 New-ItemProperty -Path $SurfaceRegKey -Name CertIssuer -PropertyType String -Value $certIssuer | Out-Null
464 }
465 Else
466 {
467 Set-ItemProperty -Path $SurfaceRegKey -Name CertIssuer -Value $certIssuer
468 }
469
470 If ($certSubjectRegValue -eq $null)
471 {
472 New-ItemProperty -Path $SurfaceRegKey -Name CertSubject -PropertyType String -Value $certSubject | Out-Null
473 }
474 Else
475 {
476 Set-ItemProperty -Path $SurfaceRegKey -Name CertSubject -Value $certSubject
477 }
```
### Settings names and IDs

1
mdop/agpm/TOC.md
View File

@ -240,5 +240,6 @@
###### [AGPM Server Connection Settings](agpm-server-connection-settings.md)
###### [Feature Visibility Settings](feature-visibility-settings.md)
##### [Other Enhancements to the GPMC](other-enhancements-to-the-gpmc.md)
## [Troubleshooting AGPM Upgrades](troubleshooting-agpm40-upgrades.md)
## [Resources for AGPM](resources-for-agpm.md)

2
mdop/agpm/index.md
View File

@ -1,7 +1,7 @@
---
title: Advanced Group Policy Management
description: Advanced Group Policy Management
author: jamiejdt
author: dansimp
ms.assetid: 493ca3c3-c3d6-4bb1-9430-dc1e43c86bb0
ms.pagetype: mdop
ms.mktglfcycl: manage

41
mdop/agpm/troubleshooting-agpm40-upgrades.md Normal file
View File

@ -0,0 +1,41 @@
---
title: Troubleshooting AGPM Upgrades
description: Troubleshooting AGPM Upgrades
author: jedodson
ms.assetid: 1abbf0c1-fd32-46a8-a3ba-c005f066523d
ms.reviewer:
manager: dansimp
ms.author: jedodson
ms.pagetype: mdop
ms.mktglfcycl: manage
ms.sitesec: library
ms.prod: w10
ms.date: 06/16/2016
---
# Troubleshooting AGPM Upgrades
This section lists common issues that you may encounter when you upgrade your Advanced Group Policy Management (AGPM) server to a newer version (e.g. AGPM 4.0 to AGPM 4.3). To diagnose issues not listed here, it may be helpful to view the [Troubleshooting AGPM](troubleshooting-agpm-agpm40.md) or for an AGPM Administrator (Full Control) to use logging and tracing. For more information, see [Configure Logging and Tracing](configure-logging-and-tracing-agpm40.md).
## What problems are you having?
- [Failed to generate a HTML GPO difference report (Error code 80004003)](#bkmk-error-80004003)
### <a href="" id="bkmk-error-80004003"></a>Failed to generate a HTML GPO difference report (Error code 80004003)
- **Cause**: You have installed the AGPM upgrade package with an incorrect account.
- **Solution**: You will need to be an AGPM administrator in order to fix this issue.
- Ensure you know the username & password of your **AGPM service account**.
- Log onto your AGPM server interactively as your AGPM service account.
- This is critically important, as the install will fail if you use a different account.
- Shutdown the AGPM service.
- Install the required hotfix.
- Connect to AGPM using an AGPM client to test that your difference reports are now functioning.

4
mdop/appv-v4/app-v-45-sp2-release-notes.md
View File

@ -73,11 +73,11 @@ When this has been completed, install the App-V 4.5 SP2 Clients by using Setup.m
When installing Microsoft Application Error Reporting, use the following command if you are installing or upgrading to the App-V 4.5 SP2 Desktop Client:
**    msiexec /i dw20shared.msi APPGUID={C6FC75B9-7D86-4C44-8BDB-EAFE1F0E200D}  allusers=1 reboot=suppress REINSTALL=all REINSTALLMODE=vomus**
**msiexec /i dw20shared.msi APPGUID={C6FC75B9-7D86-4C44-8BDB-EAFE1F0E200D}  allusers=1 reboot=suppress REINSTALL=all REINSTALLMODE=vomus**
Alternatively, if you are installing or upgrading to the App-V 4.5 SP2 Client for Remote Desktop Services (formerly Terminal Services), use the following command:
**    msiexec /i dw20shared.msi APPGUID={ECF80BBA-CA07-4A74-9ED6-E064F38AF1F5} allusers=1 reboot=suppress REINSTALL=all REINSTALLMODE=vomus**
**msiexec /i dw20shared.msi APPGUID={ECF80BBA-CA07-4A74-9ED6-E064F38AF1F5} allusers=1 reboot=suppress REINSTALL=all REINSTALLMODE=vomus**
**Note**  
- The APPGUID parameter references the product code of the App-V Clients that you install or upgrade. The product code is unique for each Setup.msi. You can use the Orca Database Editor or a similar tool to examine Windows Installer files and determine the product code. This step is required for all installations or upgrades to App-V 4.5 SP2.

2
mdop/appv-v4/how-to-configure-a-read-only-cache-on-the-app-v-client--rds--sp1.md
View File

@ -156,7 +156,7 @@ Instead of changing the AppFS key FILENAME value every time that a new cache fil
3. On the VDI Master VM Image, open a Command Prompt window by using the **Run as administrator** option and grant remote link permissions so that the VM can access the symbolic link on the VDI Host operating system. By default, remote link permissions are disabled.
**     fsutil behavior set SymlinkEvaluation R2R:1**
**fsutil behavior set SymlinkEvaluation R2R:1**
**Note**  
On the storage server, appropriate link permissions must be enabled. Depending on the location of link and the Sftfs.fsd file, the permissions are **L2L:1** or **L2R:1** or **R2L:1** or **R2R:1**.

2
mdop/appv-v4/how-to-configure-a-read-only-cache-on-the-app-v-client--vdi-.md
View File

@ -167,7 +167,7 @@ Instead of modifying the AppFS key FILENAME value every time that a new cache fi
3. On the VDI Master VM Image, open a Command Prompt window by using the **Run as administrator** option and grant remote link permissions so that the VM can access the symbolic link on the VDI Host operating system. By default, remote link permissions are disabled.
**     fsutil behavior set SymlinkEvaluation R2R:1**
**fsutil behavior set SymlinkEvaluation R2R:1**
**Note**  
On the storage server, appropriate link permissions must be enabled. Depending on the location of link and the Sftfs.fsd file, the permissions are **L2L:1** or **L2R:1** or **R2L:1** or **R2R:1**.

100
mdop/appv-v4/how-to-manually-install-the-application-virtualization-client.md
View File

@ -13,52 +13,42 @@ ms.prod: w8
ms.date: 08/30/2016
---
# How to Manually Install the Application Virtualization Client
There are two types of Application Virtualization Client components: the Application Virtualization Desktop Client, which is designed for installation on desktop computers, and the Application Virtualization Client for Remote Desktop Services (formerly Terminal Services), which you can install on Remote Desktop Session Host (RD Session Host) servers . Although the two client installer programs are different, you can use the following procedure to manually install either the Application Virtualization Desktop Client on a single desktop computer or the Application Virtualization Client for Remote Desktop Services on a single RD Session Host server. In a production environment, you most likely will install the Application Virtualization Desktop Client on multiple desktop computers with an automated scripted installation process. For information about how to install multiple clients by using a scripted installation process, see [How to Install the Client by Using the Command Line](how-to-install-the-client-by-using-the-command-line-new.md).
**Note**
1. If you are installing the Application Virtualization Client for Remote Desktop Services software on a RD Session Host server, advise users who have an open RDP or ICA client session with the RD Session Host server that they must save their work and close their sessions. In a Remote Desktop session, you can install the client the client manually. For more information about upgrading the client, see [How to Upgrade the Application Virtualization Client](how-to-upgrade-the-application-virtualization-client.md).
2. If you have any configuration on the user’s computer that depends on the client install path, note that the Application Virtualization (App-V) 4.5 client uses a different install folder than previous versions. By default, a new install of the Application Virtualization (App-V) 4.5 client will install to the \\Program Files\\Microsoft Application Virtualization Client folder. If an earlier version of the client is already installed, installing the App-V client will perform an upgrade into the existing installation folder.
1. If you are installing the Application Virtualization Client for Remote Desktop Services software on a RD Session Host server, advise users who have an open RDP or ICA client session with the RD Session Host server that they must save their work and close their sessions. In a Remote Desktop session, you can install the client the client manually. For more information about upgrading the client, see [How to Upgrade the Application Virtualization Client](how-to-upgrade-the-application-virtualization-client.md).
2. If you have any configuration on the user’s computer that depends on the client install path, note that the Application Virtualization (App-V) 4.5 client uses a different install folder than previous versions. By default, a new install of the Application Virtualization (App-V) 4.5 client will install to the \\Program Files\\Microsoft Application Virtualization Client folder. If an earlier version of the client is already installed, installing the App-V client will perform an upgrade into the existing installation folder.
**Note**
For App-V version 4.6 and later, when the App-V client is installed, SFTLDR.DLL is installed in the Windows\\system32 directory. If the App-V client is installed on a 64-bit system, SFTLDR\_WOW64.DLL is installed in the Windows\\SysWOW64 directory.
**To manually install Application Virtualization Desktop Client**
1. After you have obtained the correct installer archive file and saved it to your computer, make sure you are logged on with an account having administrator rights on the computer and double-click the file to expand the archive.
1. After you have obtained the correct installer archive file and saved it to your computer, make sure you are logged on with an account having administrator rights on the computer and double-click the file to expand the archive.
2. Choose the folder in which to save the files, and then open the folder after the files have been copied to it.
2. Choose the folder in which to save the files, and then open the folder after the files have been copied to it.
3. Review the Release Notes if appropriate.
3. Review the Release Notes if appropriate.
4. Browse to find the setup.exe file, and double-click setup.exe to start the installation.
4. Browse to find the setup.exe file, and double-click setup.exe to start the installation.
5. The wizard checks the system to ensure that all prerequisite software is installed, and if any of the following are missing, the wizard will automatically prompt you to install them:
5. The wizard checks the system to ensure that all prerequisite software is installed, and if any of the following are missing, the wizard will automatically prompt you to install them:
- Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
- Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)
- Microsoft Core XML Services (MSXML) 6.0 SP1 (x86)
- Microsoft Core XML Services (MSXML) 6.0 SP1 (x86)
- Microsoft Application Error Reporting
- Microsoft Application Error Reporting
**Note**
For App-V version 4.6 and later, the wizard will also install Microsoft Visual C++ 2008 SP1 Redistributable Package (x86).
For more information about installing Microsoft Visual C++ 2008 SP1 Redistributable Package (x86), see <https://go.microsoft.com/fwlink/?LinkId=150700> (https://go.microsoft.com/fwlink/?LinkId=150700).
For more information about installing Microsoft Visual C++ 2008 SP1 Redistributable Package (x86), see [https://go.microsoft.com/fwlink/?LinkId=150700](https://go.microsoft.com/fwlink/?LinkId=150700).
~~~
If prompted, click **Install**. Installation progress is displayed, and the status changes from **Pending** to **Installing**. Installation status changes to **Succeeded** as each step is completed successfully.
~~~
If prompted, click **Install**. Installation progress is displayed, and the status changes from **Pending** to **Installing**. Installation status changes to **Succeeded** as each step is completed successfully.
6. When the **Microsoft Application Virtualization Desktop Client – InstallShield Wizard** is displayed, click **Next**.
@ -76,88 +66,66 @@ If prompted, click **Install**. Installation progress is displayed, and the stat
12. On the **Application Virtualization Data Location** screen, click **Next** to accept the default data locations or complete the following actions to change where the data is stored:
1. Click **Change**, and then browse to or, in the **Global Data Location** field, enter the destination folder for the global data location, and click **OK**. The Global Data Directory is where the Application Virtualization Desktop Client caches data shared by all users on the computer, like OSD files and SFT file data.
1. Click **Change**, and then browse to or, in the **Global Data Location** field, enter the destination folder for the global data location, and click **OK**. The Global Data Directory is where the Application Virtualization Desktop Client caches data shared by all users on the computer, like OSD files and SFT file data.
2. If you want to change the drive letter to be used, select the preferred drive letter from the drop-down list.
2. If you want to change the drive letter to be used, select the preferred drive letter from the drop-down list.
3. Enter a new path to store the user-specific data in the **User-specific Data Location** field if you want to change the data location. The User Data Directory is where the Application Virtualization Desktop Client stores user-specific information, like personal settings for virtualized applications.
3. Enter a new path to store the user-specific data in the **User-specific Data Location** field if you want to change the data location. The User Data Directory is where the Application Virtualization Desktop Client stores user-specific information, like personal settings for virtualized applications.
**Note**
This path must be different for every user, so it should include a user-specific environment variable or a mapped drive or something else that will resolve to a unique path for each user.
4. When you have finished making the changes, click **Next**.
4. When you have finished making the changes, click **Next**.
13. On the **Cache Size Settings** screen, you can accept or change the default cache size. Click one of the following radio buttons to choose how to manage the cache space:
1. **Use maximum cache size**. Enter a numeric value from 100–1,048,576 (1 TB) in the **Maximum size (MB)** field to specify the maximum size of the cache.
1. **Use maximum cache size**. Enter a numeric value from 100–1,048,576 (1 TB) in the **Maximum size (MB)** field to specify the maximum size of the cache.
2. **Use free disk space threshold**. Enter a numeric value to specify the amount of free disk space, in MB, that the Application Virtualization Client must leave available on the disk. This allows the cache to grow until the amount of free disk space reaches this limit. The value shown in **Free disk space remaining** indicates how much disk space is currently unused.
2. **Use free disk space threshold**. Enter a numeric value to specify the amount of free disk space, in MB, that the Application Virtualization Client must leave available on the disk. This allows the cache to grow until the amount of free disk space reaches this limit. The value shown in **Free disk space remaining** indicates how much disk space is currently unused.
**Important**
To ensure that the cache has sufficient space allocated for all packages that might be deployed, use the **Use free disk space threshold** setting when you configure the client so that the cache can grow as needed. Alternatively, determine in advance how much disk space will be needed for the App-V cache, and at installation time, set the cache size accordingly. For more information about the cache space management feature, in the Microsoft Application Virtualization (App-V) Operations Guide, see **How to Use the Cache Space Management Feature**.
**Important**
To ensure that the cache has sufficient space allocated for all packages that might be deployed, use the **Use free disk space threshold** setting when you configure the client so that the cache can grow as needed. Alternatively, determine in advance how much disk space will be needed for the App-V cache, and at installation time, set the cache size accordingly. For more information about the cache space management feature, in the Microsoft Application Virtualization (App-V) Operations Guide, see **How to Use the Cache Space Management Feature**.
~~~
Click **Next** to continue.
~~~
Click **Next** to continue.
14. In the following sections of the **Runtime Package Policy Configuration** screen, you can change the parameters that affect how the Application Virtualization client behaves during runtime:
1. **Application Source Root**. Specifies the location of SFT files. If used, overrides the protocol, server, and port portions of the CODEBASE HREF URL in the OSD file.
1. **Application Source Root**. Specifies the location of SFT files. If used, overrides the protocol, server, and port portions of the CODEBASE HREF URL in the OSD file.
2. **Application Authorization**. When **Require User authorization even when cached** is checked, users are required to connect to a server and validate their credentials at least once before they are allowed to start each virtual application.
2. **Application Authorization**. When **Require User authorization even when cached** is checked, users are required to connect to a server and validate their credentials at least once before they are allowed to start each virtual application.
3. **Allow streaming from file**. Indicates whether streaming from file will be enabled, regardless of how the **Application Source Root** field is used. If not checked, streaming from files is disabled. This must be checked if **Application Source Root** contains a UNC path in the form \\\\server\\share.
3. **Allow streaming from file**. Indicates whether streaming from file will be enabled, regardless of how the **Application Source Root** field is used. If not checked, streaming from files is disabled. This must be checked if **Application Source Root** contains a UNC path in the form \\\\server\\share.
4. **Automatically Load Application**. Controls when and how automatic background loading of applications occurs.
4. **Automatically Load Application**. Controls when and how automatic background loading of applications occurs.
**Note**
When you install the App-V client to use with a read-only cache, for example, with a VDI server implementation, set **What applications to Auto Load** to **Do not automatically load applications** to prevent the client from trying to update applications in the read-only cache.
~~~
Click **Next** to continue.
~~~
Click **Next** to continue.
15. On the **Publishing Server** screen, select the **Set up a Publishing Server now** check box if you want to define a publishing server, or click **Next** if you want to complete this later. To define a publishing server, specify the following information:
1. **Display Name**—Enter the name you want to display for the server.
1. **Display Name**—Enter the name you want to display for the server.
2. **Type**—Select the server type from the drop-down list of server types.
2. **Type**—Select the server type from the drop-down list of server types.
3. **Host Name** and **Port**—Enter the host name and the port in the corresponding fields. When you select a server type in the drop-down list, the port field will automatically fill with the standard port numbers. To change a port number, click the server type in the list and change the port number according to your needs.
3. **Host Name** and **Port**—Enter the host name and the port in the corresponding fields. When you select a server type in the drop-down list, the port field will automatically fill with the standard port numbers. To change a port number, click the server type in the list and change the port number according to your needs.
4. **Path**—If you have selected either **Standard HTTP Server** or **Enhanced Security HTTP Server**, you must enter the complete path to the XML file containing publishing data in this field. If you select either **Application Virtualization Server** or **Enhanced Security Application Virtualization Server**, this field is not active.
4. **Path**—If you have selected either **Standard HTTP Server** or **Enhanced Security HTTP Server**, you must enter the complete path to the XML file containing publishing data in this field. If you select either **Application Virtualization Server** or **Enhanced Security Application Virtualization Server**, this field is not active.
5. **Automatically contact this server to update settings when a user logs in**—Select this check box if you want this server to be queried automatically when users log in to their account on the Application Virtualization Client.
5. **Automatically contact this server to update settings when a user logs in**—Select this check box if you want this server to be queried automatically when users log in to their account on the Application Virtualization Client.
6. When finished with the configuration steps, click **Next**.
6. When finished with the configuration steps, click **Next**.
16. On the **Ready to Install the Program** screen, click **Install**. A screen is displayed that shows the progress of the installation.
17. On the **Install Wizard Completed** screen, click **Finish**.
**Note**
If the installation fails for any reason, you might need to restart the computer before trying the install again.
**Note**
If the installation fails for any reason, you might need to restart the computer before trying the install again.
## Related topics
[How to Install the Client by Using the Command Line](how-to-install-the-client-by-using-the-command-line-new.md)
[Stand-Alone Delivery Scenario Overview](stand-alone-delivery-scenario-overview.md)

2
mdop/appv-v4/index.md
View File

@ -1,7 +1,7 @@
---
title: Application Virtualization 4
description: Application Virtualization 4
author: jamiejdt
author: dansimp
ms.assetid: 9da557bc-f433-47d3-8af7-68ec4ff9bd3f
ms.pagetype: mdop, appcompat, virtualization
ms.mktglfcycl: deploy

24
mdop/appv-v4/microsoft-application-virtualization-46-service-pack-2-privacy-statement.md
View File

@ -76,7 +76,7 @@ This section is divided into two parts: (1) features in all versions of App-V an
Microsoft Error Reporting provides a service that allows you to report problems you may be having with App-V to Microsoft and to receive information that may help you avoid or solve such problems.
**Information Collected, Processed, or Transmitted: **
**Information Collected, Processed, or Transmitted:**
For information about the information collected, processed, or transmitted by Microsoft Error Reporting, see the Microsoft Error Reporting privacy statement at <https://go.microsoft.com/fwlink/?linkid=50293>.
@ -84,7 +84,7 @@ For information about the information collected, processed, or transmitted by Mi
We use the error reporting data to solve customer problems and improve our software and services.
**Choice/Control: **
**Choice/Control:**
App-V does not change your Microsoft Error Reporting settings. If you previously turned on error reporting, it will send Microsoft the information about the errors you encountered. When Microsoft needs additional data to analyze the problem, you will be prompted to review the data and choose whether or not to send it.  App-V will always respect your Microsoft Error Reporting settings.
@ -98,7 +98,7 @@ Enterprise customers can use Group Policy to configure how Microsoft Error Repor
Microsoft Update is a service that provides Windows updates as well as updates for other Microsoft software, including App-V.  For details about what information is collected, how it is used and how to change your settings, see the Update Services Privacy Statement at <https://go.microsoft.com/fwlink/?linkid=50142>.
**Choice/Control: **
**Choice/Control:**
If Microsoft Update is not enabled, you can opt-in during setup and subsequent checks for updates will follow the machine-wide schedule. You can update this option from the Microsoft Update Control Panel item.
@ -108,7 +108,7 @@ If Microsoft Update is not enabled, you can opt-in during setup and subsequent c
The product will collect various configuration items, including UserID, MachineID and SecurityGroup details, to be able to enforce settings on managed nodes. The data is stored in the App-V SQL database and transmitted across the App-V server and client components to enforce the configuration on the managed node.
**Information Collected, Processed, or Transmitted: **
**Information Collected, Processed, or Transmitted:**
User and machine information and configuration content
@ -116,7 +116,7 @@ User and machine information and configuration content
The information is used to enforce the application access configuration on the managed nodes within the enterprise. The information does not leave the enterprise.
**Choice/Control: **
**Choice/Control:**
By default, the product does not have any data. All data is entered and enabled by the admin and can be viewed in the Management console. The feature cannot be disabled as this is the product functionality. To disable this, App-V will need to be uninstalled.
@ -130,7 +130,7 @@ None of this information is sent out of the enterprise.
It captures package history and asset information as part of the package.
**Information Collected, Processed, or Transmitted: **
**Information Collected, Processed, or Transmitted:**
Information about the package and the sequencing environment is collected and stored in the package manifest during sequencing.
@ -138,7 +138,7 @@ Information about the package and the sequencing environment is collected and st
The information will be used by the admin to track the updates done to a package during its lifecycle. It will also be used by software deployment systems to track the package deployments within the organization.
**Choice/Control: **
**Choice/Control:**
This feature is always enabled and cannot be turned off.
@ -152,7 +152,7 @@ This administrator information will be stored in the package and can be viewed b
The product will collect a variety of reporting data points, including the username, to allow reporting on the usage of the product.
**Information Collected, Processed, or Transmitted: **
**Information Collected, Processed, or Transmitted:**
Information about the machine, package and application usage are collected from every machine that reporting is enabled on.
@ -160,7 +160,7 @@ Information about the machine, package and application usage are collected from
The information is used to report on application usage within the enterprise. The information does not leave the enterprise.
**Choice/Control: **
**Choice/Control:**
By default, the product does not have any data. Data is only collected once the reporting feature is enabled on the App-V Client. To disable the collection of reporting data, the reporting feature must be disabled on all clients.
@ -178,7 +178,7 @@ This section addresses specific features available in App-V 4.6 SP1 and later.
The Customer Experience Improvement Program (“CEIP”) collects basic information about your hardware configuration and how you use our software and services in order to identify trends and usage patterns. CEIP also collects the type and number of errors you encounter, software and hardware performance, and the speed of services. We will not collect your name, address, or other contact information.
**Information Collected, Processed, or Transmitted: **
**Information Collected, Processed, or Transmitted:**
For more information about the information collected, processed, or transmitted by CEIP, see the CEIP privacy statement at <https://go.microsoft.com/fwlink/?LinkID=52097>.
@ -186,7 +186,7 @@ For more information about the information collected, processed, or transmitted
We use this information to improve the quality, reliability, and performance of Microsoft software and services.
**Choice/Control: **
**Choice/Control:**
CEIP is optional and the opt-in status can be updated during install or post install from the GUI.  
@ -196,7 +196,7 @@ CEIP is optional and the opt-in status can be updated during install or post ins
Customers can use Application Package Accelerators to automatically package complex applications without installing the application. The App-V sequencer allows you to create package accelerators for each virtual package. You can then use these package accelerators to automatically re-create the same virtual package in the future. You may also use package accelerators released by Microsoft or other third parties to simplify and automate packaging of complex applications.
**Information Collected, Processed, or Transmitted: **
**Information Collected, Processed, or Transmitted:**
Application Package Accelerators may contain information such as computer names, user account information, and information about applications included in the Package Accelerator file.

4
mdop/appv-v4/planning-for-client-security.md
View File

@ -34,7 +34,7 @@ By default, at installation the App-V client is configured with the minimum perm
By default, the installation of the client registers file type associations (FTAs) for OSD files, which enables users to start applications directly from OSD files instead of the published shortcuts. If a user with local administrator rights receives an OSD file containing malicious code, either in e-mail or downloaded from a Web site, the user can open the OSD file and start the application even if the client has been set to restrict the **Add Application** permission. You can unregister the FTAs for the OSD to reduce this risk. Also, consider blocking this extension in the e-mail system and at the firewall. For more information about configuring Outlook to block extensions, see <https://go.microsoft.com/fwlink/?LinkId=133278>.
**Security Note:  **
**Security Note:**
Starting with App-V version 4.6, the file type association is no longer created for OSD files during a new installation of the client, although the existing settings will be maintained during an upgrade from version 4.2 or 4.5 of the App-V client. If for any reason it is essential to create the file type association, you can create the following registry keys and set their values as shown:
@ -50,7 +50,7 @@ During installation, you can use the **RequireAuthorizationIfCached** parameter
Antivirus software running on an App-V Client computer can detect and report an infected file in the virtual environment. However, it cannot disinfect the file. If a virus is detected in the virtual environment, the antivirus software would perform the configured quarantine or repair operation in the cache, not in the actual package. Configure the antivirus software with an exception for the sftfs.fsd file. This file is the cache file that stores packages on the App-V Client.
**Security Note:  **
**Security Note:**
If a virus is detected in an application or package deployed in the production environment, replace the application or package with a virus-free version.

2
mdop/appv-v4/security-and-protection-overview.md
View File

@ -21,7 +21,7 @@ Microsoft Application Virtualization 4.5 provides the following enhanced securi
- Application Virtualization now supports Transport Layer Security (TLS) using X.509 V3 certificates. Provided that a server certificate has been provisioned to the planned Application Virtualization Management or Streaming Server, the installation will default to secure, using the RTSPS protocol over port 322. Using RTSPS ensures that communication between the Application Virtualization Servers and the Application Virtualization Clients is signed and encrypted. If no certificate is assigned to the server during the Application Virtualization Server installation, the communication will be set to RTSP over port 554.
**Security Note:  **
**Security Note:**
To help provide a secure setup of the server, you must make sure that RTSP ports are disabled even if you have all packages configured to use RTSPS.

2
mdop/appv-v5/index.md
View File

@ -1,7 +1,7 @@
---
title: Application Virtualization 5
description: Application Virtualization 5
author: jamiejdt
author: dansimp
ms.assetid: e82eb44b-9ccd-41aa-923b-71400230ad23
ms.pagetype: mdop, appcompat, virtualization
ms.mktglfcycl: deploy

2
mdop/dart-v10/index.md
View File

@ -1,7 +1,7 @@
---
title: Diagnostics and Recovery Toolset 10
description: Diagnostics and Recovery Toolset 10
author: jamiejdt
author: dansimp
ms.assetid: 64403eca-ff05-4327-ac33-bdcc96e706c8
ms.pagetype: mdop
ms.mktglfcycl: support

2
mdop/dart-v7/index.md
View File

@ -1,7 +1,7 @@
---
title: Diagnostics and Recovery Toolset 7 Administrator's Guide
description: Diagnostics and Recovery Toolset 7 Administrator's Guide
author: jamiejdt
author: dansimp
ms.assetid: bf89eccd-fc03-48ff-9019-a8640e11dd99
ms.pagetype: mdop
ms.mktglfcycl: support

2
mdop/dart-v8/index.md
View File

@ -1,7 +1,7 @@
---
title: Diagnostics and Recovery Toolset 8 Administrator's Guide
description: Diagnostics and Recovery Toolset 8 Administrator's Guide
author: jamiejdt
author: dansimp
ms.assetid: 33685dd7-844f-4864-b504-3ef384ef01de
ms.pagetype: mdop
ms.mktglfcycl: support

2
mdop/index.md
View File

@ -2,7 +2,7 @@
title: MDOP Information Experience
description: MDOP Information Experience
ms.assetid: 12b8ab56-3267-450d-bb22-1c7e44cb8e52
author: jamiejdt
author: dansimp
ms.pagetype: mdop
ms.mktglfcycl: manage
ms.sitesec: library

68
mdop/mbam-v1/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft BitLocker Administration and Monitoring 1 Administrator's Guide
description: Microsoft BitLocker Administration and Monitoring 1 Administrator's Guide
author: jamiejdt
author: dansimp
ms.assetid: 4086e721-db24-4439-bdcd-ac5ef901811f
ms.pagetype: mdop, security
ms.mktglfcycl: manage
@ -10,46 +10,36 @@ ms.prod: w8
ms.date: 04/19/2017
---
# Microsoft BitLocker Administration and Monitoring 1 Administrator's Guide
Microsoft BitLocker Administration and Monitoring (MBAM) provides a simplified administrative interface that you can use to manage BitLocker drive encryption. With MBAM, you can select BitLocker encryption policy options that are appropriate to your enterprise and then use them to monitor client compliance with those policies. You can also report on the encryption status of an individual computer and on the entire enterprise. In addition, you can access recovery key information when users forget their PIN or password, or when their BIOS or boot record changes.
<a href="" id="getting-started-with-mbam-1-0"></a>[Getting Started with MBAM 1.0](getting-started-with-mbam-10.md)
[About MBAM 1.0](about-mbam-10.md)**|**[Evaluating MBAM 1.0](evaluating-mbam-10.md)**|**[High Level Architecture for MBAM 1.0](high-level-architecture-for-mbam-10.md)**|**[Accessibility for MBAM 1.0](accessibility-for-mbam-10.md)**|**[Privacy Statement for MBAM 1.0](privacy-statement-for-mbam-10.md)
<a href="" id="planning-for-mbam-1-0"></a>[Planning for MBAM 1.0](planning-for-mbam-10.md)
[Preparing your Environment for MBAM 1.0](preparing-your-environment-for-mbam-10.md)**|**[MBAM 1.0 Deployment Prerequisites](mbam-10-deployment-prerequisites.md)**|**[Planning to Deploy MBAM 1.0](planning-to-deploy-mbam-10.md)**|**[MBAM 1.0 Supported Configurations](mbam-10-supported-configurations.md)**|**[MBAM 1.0 Planning Checklist](mbam-10-planning-checklist.md)
<a href="" id="deploying-mbam-1-0"></a>[Deploying MBAM 1.0](deploying-mbam-10.md)
[Deploying the MBAM 1.0 Server Infrastructure](deploying-the-mbam-10-server-infrastructure.md)**|**[Deploying MBAM 1.0 Group Policy Objects](deploying-mbam-10-group-policy-objects.md)**|**[Deploying the MBAM 1.0 Client](deploying-the-mbam-10-client.md)**|**[Deploying the MBAM 1.0 Language Release Update](deploying-the-mbam-10-language-release-update.md)**|**[MBAM 1.0 Deployment Checklist](mbam-10-deployment-checklist.md)
<a href="" id="operations-for-mbam-1-0"></a>[Operations for MBAM 1.0](operations-for-mbam-10.md)
[Administering MBAM 1.0 Features](administering-mbam-10-features.md)**|**[Monitoring and Reporting BitLocker Compliance with MBAM 1.0](monitoring-and-reporting-bitlocker-compliance-with-mbam-10.md)**|**[Performing BitLocker Management with MBAM](performing-bitlocker-management-with-mbam.md)**|**[Administering MBAM 1.0 by Using PowerShell](administering-mbam-10-by-using-powershell.md)
<a href="" id="troubleshooting-mbam-1-0"></a>[Troubleshooting MBAM 1.0](troubleshooting-mbam-10.md)
### More Information
<a href="" id="release-notes-for-mbam-1-0"></a>[Release Notes for MBAM 1.0](release-notes-for-mbam-10.md)
View updated product information and known issues for MBAM 1.0.
<a href="" id="mdop-techcenter-page"></a>[MDOP TechCenter Page](https://go.microsoft.com/fwlink/p/?LinkId=225286)
Learn about the latest MDOP information and resources.
<a href="" id="mdop-information-experience"></a>[MDOP Information Experience](https://go.microsoft.com/fwlink/p/?LinkId=236032)
Find documentation, videos, and other resources for MDOP technologies. You can also [send us feedback](mailto:MDOPDocs@microsoft.com) or learn about updates by following us on [Facebook](https://go.microsoft.com/fwlink/p/?LinkId=242445) or [Twitter](https://go.microsoft.com/fwlink/p/?LinkId=242447).
 
 
- [Getting Started with MBAM 1.0](getting-started-with-mbam-10.md)
- [About MBAM 1.0](about-mbam-10.md)
- [Release Notes for MBAM 1.0](release-notes-for-mbam-10.md)
- [Evaluating MBAM 1.0](evaluating-mbam-10.md)
- [High Level Architecture for MBAM 1.0](high-level-architecture-for-mbam-10.md)
- [Accessibility for MBAM 1.0](accessibility-for-mbam-10.md)
- [Privacy Statement for MBAM 1.0](privacy-statement-for-mbam-10.md)
- [Planning for MBAM 1.0](planning-for-mbam-10.md)
- [Preparing your Environment for MBAM 1.0](preparing-your-environment-for-mbam-10.md)
- [MBAM 1.0 Deployment Prerequisites](mbam-10-deployment-prerequisites.md)
- [Planning to Deploy MBAM 1.0](planning-to-deploy-mbam-10.md)
- [MBAM 1.0 Supported Configurations](mbam-10-supported-configurations.md)
- [MBAM 1.0 Planning Checklist](mbam-10-planning-checklist.md)
- [Deploying MBAM 1.0](deploying-mbam-10.md)
- [Deploying the MBAM 1.0 Server Infrastructure](deploying-the-mbam-10-server-infrastructure.md)
- [Deploying MBAM 1.0 Group Policy Objects](deploying-mbam-10-group-policy-objects.md)
- [Deploying the MBAM 1.0 Client](deploying-the-mbam-10-client.md)
- [Deploying the MBAM 1.0 Language Release Update](deploying-the-mbam-10-language-release-update.md)
- [MBAM 1.0 Deployment Checklist](mbam-10-deployment-checklist.md)
- [Operations for MBAM 1.0](operations-for-mbam-10.md)
- [Administering MBAM 1.0 Features](administering-mbam-10-features.md)
- [Monitoring and Reporting BitLocker Compliance with MBAM 1.0](monitoring-and-reporting-bitlocker-compliance-with-mbam-10.md)
- [Performing BitLocker Management with MBAM](performing-bitlocker-management-with-mbam.md)
- [Administering MBAM 1.0 by Using PowerShell](administering-mbam-10-by-using-powershell.md)
- [Troubleshooting MBAM 1.0](troubleshooting-mbam-10.md)
## More Information
- [MDOP Information Experience](https://go.microsoft.com/fwlink/p/?LinkId=236032)
Find documentation, videos, and other resources for MDOP technologies.

64
mdop/mbam-v2/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft BitLocker Administration and Monitoring 2 Administrator's Guide
description: Microsoft BitLocker Administration and Monitoring 2 Administrator's Guide
author: jamiejdt
author: dansimp
ms.assetid: fdb43f62-960a-4811-8802-50efdf04b4af
ms.pagetype: mdop, security
ms.mktglfcycl: manage
@ -10,43 +10,47 @@ ms.prod: w8
ms.date: 04/19/2017
---
# Microsoft BitLocker Administration and Monitoring 2 Administrator's Guide
Microsoft BitLocker Administration and Monitoring (MBAM) 2.0 provides a simplified administrative interface that you can use to manage BitLocker drive encryption. In BitLocker Administration and Monitoring 2.0, you can select BitLocker drive encryption policy options that are appropriate for your enterprise, and then use them to monitor client compliance with those policies. You can also report on the encryption status of an individual computer and on the enterprise as a whole. In addition, you can access recovery key information when users forget their PIN or password or when their BIOS or boot record changes.
<a href="" id="getting-started-with-mbam-2-0"></a>[Getting Started with MBAM 2.0](getting-started-with-mbam-20-mbam-2.md)
## Outline
[About MBAM 2.0](about-mbam-20-mbam-2.md)**|**[Release Notes for MBAM 2.0](release-notes-for-mbam-20-mbam-2.md)**|**[About MBAM 2.0 SP1](about-mbam-20-sp1.md)**|**[Release Notes for MBAM 2.0 SP1](release-notes-for-mbam-20-sp1.md)**|**[Evaluating MBAM 2.0](evaluating-mbam-20-mbam-2.md)**|**[High-Level Architecture for MBAM 2.0](high-level-architecture-for-mbam-20-mbam-2.md)**|**[Accessibility for MBAM 2.0](accessibility-for-mbam-20-mbam-2.md)
- [Getting Started with MBAM 2.0](getting-started-with-mbam-20-mbam-2.md)
- [About MBAM 2.0](about-mbam-20-mbam-2.md)
- [Release Notes for MBAM 2.0](release-notes-for-mbam-20-mbam-2.md)
- [About MBAM 2.0 SP1](about-mbam-20-sp1.md)
- [Release Notes for MBAM 2.0 SP1](release-notes-for-mbam-20-sp1.md)
- [Evaluating MBAM 2.0](evaluating-mbam-20-mbam-2.md)
- [High-Level Architecture for MBAM 2.0](high-level-architecture-for-mbam-20-mbam-2.md)
- [Accessibility for MBAM 2.0](accessibility-for-mbam-20-mbam-2.md)
- [Planning for MBAM 2.0](planning-for-mbam-20-mbam-2.md)
- [Preparing your Environment for MBAM 2.0](preparing-your-environment-for-mbam-20-mbam-2.md)
- [MBAM 2.0 Deployment Prerequisites](mbam-20-deployment-prerequisites-mbam-2.md)
- [Planning to Deploy MBAM 2.0](planning-to-deploy-mbam-20-mbam-2.md)
- [MBAM 2.0 Supported Configurations](mbam-20-supported-configurations-mbam-2.md)
- [MBAM 2.0 Planning Checklist](mbam-20-planning-checklist-mbam-2.md)
- [Deploying MBAM 2.0](deploying-mbam-20-mbam-2.md)
- [Deploying the MBAM 2.0 Server Infrastructure](deploying-the-mbam-20-server-infrastructure-mbam-2.md)
- [Deploying MBAM 2.0 Group Policy Objects](deploying-mbam-20-group-policy-objects-mbam-2.md)
- [Deploying the MBAM 2.0 Client](deploying-the-mbam-20-client-mbam-2.md)
- [MBAM 2.0 Deployment Checklist](mbam-20-deployment-checklist-mbam-2.md)
- [Upgrading from Previous Versions of MBAM](upgrading-from-previous-versions-of-mbam.md)
- [Operations for MBAM 2.0](operations-for-mbam-20-mbam-2.md)
- [Using MBAM with Configuration Manager](using-mbam-with-configuration-manager.md)
- [Administering MBAM 2.0 Features](administering-mbam-20-features-mbam-2.md)
- [Monitoring and Reporting BitLocker Compliance with MBAM 2.0](monitoring-and-reporting-bitlocker-compliance-with-mbam-20-mbam-2.md)
- [Performing BitLocker Management with MBAM](performing-bitlocker-management-with-mbam-mbam-2.md)
- [Maintaining MBAM 2.0](maintaining-mbam-20-mbam-2.md)
- [Security and Privacy for MBAM 2.0](security-and-privacy-for-mbam-20-mbam-2.md)
- [Administering MBAM 2.0 Using PowerShell](administering-mbam-20-using-powershell-mbam-2.md)
- [Troubleshooting MBAM 2.0](troubleshooting-mbam-20-mbam-2.md)
<a href="" id="planning-for-mbam-2-0"></a>[Planning for MBAM 2.0](planning-for-mbam-20-mbam-2.md)
## More Information
[Preparing your Environment for MBAM 2.0](preparing-your-environment-for-mbam-20-mbam-2.md)**|**[MBAM 2.0 Deployment Prerequisites](mbam-20-deployment-prerequisites-mbam-2.md)**|**[Planning to Deploy MBAM 2.0](planning-to-deploy-mbam-20-mbam-2.md)**|**[MBAM 2.0 Supported Configurations](mbam-20-supported-configurations-mbam-2.md)**|**[MBAM 2.0 Planning Checklist](mbam-20-planning-checklist-mbam-2.md)
- [MDOP Information Experience](index.md)
<a href="" id="deploying-mbam-2-0"></a>[Deploying MBAM 2.0](deploying-mbam-20-mbam-2.md)
[Deploying the MBAM 2.0 Server Infrastructure](deploying-the-mbam-20-server-infrastructure-mbam-2.md)**|**[Deploying MBAM 2.0 Group Policy Objects](deploying-mbam-20-group-policy-objects-mbam-2.md)**|**[Deploying the MBAM 2.0 Client](deploying-the-mbam-20-client-mbam-2.md)**|**[MBAM 2.0 Deployment Checklist](mbam-20-deployment-checklist-mbam-2.md)**|**[Upgrading from Previous Versions of MBAM](upgrading-from-previous-versions-of-mbam.md)
<a href="" id="operations-for-mbam-2-0"></a>[Operations for MBAM 2.0](operations-for-mbam-20-mbam-2.md)
[Using MBAM with Configuration Manager](using-mbam-with-configuration-manager.md)**|**[Administering MBAM 2.0 Features](administering-mbam-20-features-mbam-2.md)**|**[Monitoring and Reporting BitLocker Compliance with MBAM 2.0](monitoring-and-reporting-bitlocker-compliance-with-mbam-20-mbam-2.md)**|**[Performing BitLocker Management with MBAM](performing-bitlocker-management-with-mbam-mbam-2.md)**|**[Maintaining MBAM 2.0](maintaining-mbam-20-mbam-2.md)**|**[Security and Privacy for MBAM 2.0](security-and-privacy-for-mbam-20-mbam-2.md)**|** [Administering MBAM 2.0 Using PowerShell](administering-mbam-20-using-powershell-mbam-2.md)
<a href="" id="troubleshooting-mbam-2-0"></a>[Troubleshooting MBAM 2.0](troubleshooting-mbam-20-mbam-2.md)
### More Information
- [Release Notes for MBAM 2.0](release-notes-for-mbam-20-mbam-2.md)
View updated product information and known issues for MBAM 2.0.
- [MDOP TechCenter Page](https://go.microsoft.com/fwlink/p/?LinkId=225286)
Learn about the latest MDOP information and resources.
- [MDOP Information Experience](https://go.microsoft.com/fwlink/p/?LinkId=236032)
Find documentation, videos, and other resources for MDOP technologies. You can also [send us feedback](mailto:MDOPDocs@microsoft.com) or learn about updates by following us on [Facebook](https://go.microsoft.com/fwlink/p/?LinkId=242445) or [Twitter](https://go.microsoft.com/fwlink/p/?LinkId=242447).
Find documentation, videos, and other resources for MDOP technologies.
 

2
mdop/mbam-v25/apply-hotfix-for-mbam-25-sp1.md
View File

@ -19,7 +19,7 @@ author: shortpatti
This topic describes the process for applying the hotfixes for Microsoft BitLocker Administration and Monitoring (MBAM) Server 2.5 SP1
### Before you begin, download the latest hotfix of Microsoft BitLocker Administration and Monitoring (MBAM) Server 2.5 SP1
[Desktop Optimization Pack](https://www.microsoft.com/en-us/download/details.aspx?id=57157)
[Desktop Optimization Pack](https://www.microsoft.com/en-us/download/details.aspx?id=58345)
#### Steps to update the MBAM Server for existing MBAM environment
1. Remove MBAM server feature (do this by opening the MBAM Server Configuration Tool, then selecting Remove Features).

100
mdop/mbam-v25/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft BitLocker Administration and Monitoring 2.5
description: Microsoft BitLocker Administration and Monitoring 2.5
author: jamiejdt
author: dansimp
ms.assetid: fd81d7de-b166-47e8-b6c7-d984830762b6
ms.pagetype: mdop, security
ms.mktglfcycl: manage
@ -10,67 +10,61 @@ ms.prod: w10
ms.date: 04/19/2017
---
# Microsoft BitLocker Administration and Monitoring 2.5
Microsoft BitLocker Administration and Monitoring (MBAM) 2.5 provides a simplified administrative interface that you can use to manage BitLocker Drive Encryption. You configure MBAM Group Policy Templates that enable you to set BitLocker Drive Encryption policy options that are appropriate for your enterprise, and then use them to monitor client compliance with those policies. You can also report on the encryption status of an individual computer and on the enterprise as a whole. In addition, you can access recovery key information when users forget their PIN or password or when their BIOS or boot record changes. For a more detailed description of MBAM, see [About MBAM 2.5](about-mbam-25.md).
To get the MBAM software, see [How Do I Get MDOP](https://go.microsoft.com/fwlink/?LinkId=322049) (https://go.microsoft.com/fwlink/?LinkId=322049).
To obtain MBAM, see [How Do I Get MDOP](index.md#how-to-get-mdop).
<a href="" id="getting-started-with-mbam-2-5"></a>[Getting Started with MBAM 2.5](getting-started-with-mbam-25.md)
## Outline
[About MBAM 2.5](about-mbam-25.md)**|**[Release Notes for MBAM 2.5](release-notes-for-mbam-25.md)**|**[About MBAM 2.5 SP1](about-mbam-25-sp1.md)**|**[Release Notes for MBAM 2.5 SP1](release-notes-for-mbam-25-sp1.md)**|**[Evaluating MBAM 2.5 in a Test Environment](evaluating-mbam-25-in-a-test-environment.md)**|**[High-Level Architecture for MBAM 2.5](high-level-architecture-for-mbam-25.md)**|**[Accessibility for MBAM 2.5](accessibility-for-mbam-25.md)
- <a href="" id="getting-started-with-mbam-2-5"></a>[Getting Started with MBAM 2.5](getting-started-with-mbam-25.md)
- [About MBAM 2.5](about-mbam-25.md)
- [Release Notes for MBAM 2.5](release-notes-for-mbam-25.md)
- [About MBAM 2.5 SP1](about-mbam-25-sp1.md)
- [Release Notes for MBAM 2.5 SP1](release-notes-for-mbam-25-sp1.md)
- [Evaluating MBAM 2.5 in a Test Environment](evaluating-mbam-25-in-a-test-environment.md)
- [High-Level Architecture for MBAM 2.5](high-level-architecture-for-mbam-25.md)
- [Accessibility for MBAM 2.5](accessibility-for-mbam-25.md)
- <a href="" id="planning-for-mbam-2-5"></a>[Planning for MBAM 2.5](planning-for-mbam-25.md)
- [Preparing your Environment for MBAM 2.5](preparing-your-environment-for-mbam-25.md)
- [MBAM 2.5 Deployment Prerequisites](mbam-25-deployment-prerequisites.md)
- [Planning for MBAM 2.5 Group Policy Requirements](planning-for-mbam-25-group-policy-requirements.md)
- [Planning for MBAM 2.5 Groups and Accounts](planning-for-mbam-25-groups-and-accounts.md)
- [Planning How to Secure the MBAM Websites](planning-how-to-secure-the-mbam-websites.md)
- [Planning to Deploy MBAM 2.5](planning-to-deploy-mbam-25.md)
- [MBAM 2.5 Supported Configurations](mbam-25-supported-configurations.md)
- [Planning for MBAM 2.5 High Availability](planning-for-mbam-25-high-availability.md)
- [MBAM 2.5 Security Considerations](mbam-25-security-considerations.md)
- [MBAM 2.5 Planning Checklist](mbam-25-planning-checklist.md)
- <a href="" id="deploying-mbam-2-5"></a>[Deploying MBAM 2.5](deploying-mbam-25.md)
- [Deploying the MBAM 2.5 Server Infrastructure](deploying-the-mbam-25-server-infrastructure.md)
- [Deploying MBAM 2.5 Group Policy Objects](deploying-mbam-25-group-policy-objects.md)
- [Deploying the MBAM 2.5 Client](deploying-the-mbam-25-client.md)
- [MBAM 2.5 Deployment Checklist](mbam-25-deployment-checklist.md)
- [Upgrading to MBAM 2.5 or MBAM 2.5 SP1 from Previous Versions](upgrading-to-mbam-25-or-mbam-25-sp1-from-previous-versions.md)
- [Removing MBAM Server Features or Software](removing-mbam-server-features-or-software.md)
- <a href="" id="operations-for-mbam-2-5"></a>[Operations for MBAM 2.5](operations-for-mbam-25.md)
- [Administering MBAM 2.5 Features](administering-mbam-25-features.md)
- [Monitoring and Reporting BitLocker Compliance with MBAM 2.5](monitoring-and-reporting-bitlocker-compliance-with-mbam-25.md)
- [Performing BitLocker Management with MBAM 2.5](performing-bitlocker-management-with-mbam-25.md)
- [Maintaining MBAM 2.5](maintaining-mbam-25.md)
- [Using Windows PowerShell to Administer MBAM 2.5](using-windows-powershell-to-administer-mbam-25.md)
- <a href="" id="troubleshooting-mbam-2-5"></a>[Troubleshooting MBAM 2.5](troubleshooting-mbam-25.md)
- <a href="" id="technical-reference-for-mbam-2-5"></a>[Technical Reference for MBAM 2.5](technical-reference-for-mbam-25.md)
- [Client Event Logs](client-event-logs.md)
- [Server Event Logs](server-event-logs.md)
<a href="" id="planning-for-mbam-2-5"></a>[Planning for MBAM 2.5](planning-for-mbam-25.md)
[Preparing your Environment for MBAM 2.5](preparing-your-environment-for-mbam-25.md)**|**[MBAM 2.5 Deployment Prerequisites](mbam-25-deployment-prerequisites.md)**|**[Planning for MBAM 2.5 Group Policy Requirements](planning-for-mbam-25-group-policy-requirements.md)**|**[Planning for MBAM 2.5 Groups and Accounts](planning-for-mbam-25-groups-and-accounts.md)**|**[Planning How to Secure the MBAM Websites](planning-how-to-secure-the-mbam-websites.md)**|**[Planning to Deploy MBAM 2.5](planning-to-deploy-mbam-25.md)**|**[MBAM 2.5 Supported Configurations](mbam-25-supported-configurations.md)**|**[Planning for MBAM 2.5 High Availability](planning-for-mbam-25-high-availability.md)**|**[MBAM 2.5 Security Considerations](mbam-25-security-considerations.md)**|**[MBAM 2.5 Planning Checklist](mbam-25-planning-checklist.md)
<a href="" id="deploying-mbam-2-5"></a>[Deploying MBAM 2.5](deploying-mbam-25.md)
[Deploying the MBAM 2.5 Server Infrastructure](deploying-the-mbam-25-server-infrastructure.md)**|**[Deploying MBAM 2.5 Group Policy Objects](deploying-mbam-25-group-policy-objects.md)**|**[Deploying the MBAM 2.5 Client](deploying-the-mbam-25-client.md)**|**[MBAM 2.5 Deployment Checklist](mbam-25-deployment-checklist.md)**|**[Upgrading to MBAM 2.5 or MBAM 2.5 SP1 from Previous Versions](upgrading-to-mbam-25-or-mbam-25-sp1-from-previous-versions.md)**|**[Removing MBAM Server Features or Software](removing-mbam-server-features-or-software.md)
<a href="" id="operations-for-mbam-2-5"></a>[Operations for MBAM 2.5](operations-for-mbam-25.md)
[Administering MBAM 2.5 Features](administering-mbam-25-features.md)**|**[Monitoring and Reporting BitLocker Compliance with MBAM 2.5](monitoring-and-reporting-bitlocker-compliance-with-mbam-25.md)**|**[Performing BitLocker Management with MBAM 2.5](performing-bitlocker-management-with-mbam-25.md)**|**[Maintaining MBAM 2.5](maintaining-mbam-25.md)**|**[Using Windows PowerShell to Administer MBAM 2.5](using-windows-powershell-to-administer-mbam-25.md)
<a href="" id="troubleshooting-mbam-2-5"></a>[Troubleshooting MBAM 2.5](troubleshooting-mbam-25.md)
<a href="" id="technical-reference-for-mbam-2-5"></a>[Technical Reference for MBAM 2.5](technical-reference-for-mbam-25.md)
[Client Event Logs](client-event-logs.md)**|**[Server Event Logs](server-event-logs.md)
### More Information
- [Release Notes for MBAM 2.5](release-notes-for-mbam-25.md)
View updated product information and known issues for MBAM 2.5.
- [MDOP TechCenter Page](https://go.microsoft.com/fwlink/p/?LinkId=225286)
Learn about the latest MDOP information and resources.
- [MDOP Information Experience](https://go.microsoft.com/fwlink/p/?LinkId=236032)
Find documentation, videos, and other resources for MDOP technologies. You can also [send us feedback](mailto:MDOPDocs@microsoft.com) or learn about updates by following us on [Facebook](https://go.microsoft.com/fwlink/p/?LinkId=242445) or [Twitter](https://go.microsoft.com/fwlink/p/?LinkId=242447).
- [MBAM Deployment Guide](https://www.microsoft.com/download/details.aspx?id=38398)
Get help in choosing a deployment method for MBAM, including step-by-step instructions for each method.
- [Apply Hotfixes on MBAM 2.5 SP1 Server](apply-hotfix-for-mbam-25-sp1.md)
Guide of how to apply MBAM 2.5 SP1 Server hotfixes
## Got a suggestion for MBAM?
- Add or vote on suggestions [here](http://mbam.uservoice.com/forums/268571-microsoft-bitlocker-administration-and-monitoring).
- For MBAM issues, use the [MBAM TechNet Forum](https://social.technet.microsoft.com/Forums/home?forum=mdopmbam).
 
 
## More Information
- [MDOP Information Experience](index.md)
Find documentation, videos, and other resources for MDOP technologies.
- [MBAM Deployment Guide](https://www.microsoft.com/download/details.aspx?id=38398)
Get help in choosing a deployment method for MBAM, including step-by-step instructions for each method.
- [Apply Hotfixes on MBAM 2.5 SP1 Server](apply-hotfix-for-mbam-25-sp1.md)
Guide of how to apply MBAM 2.5 SP1 Server hotfixes

12
mdop/medv-v1/how-to-configure-image-pre-staging.md
View File

@ -72,17 +72,17 @@ Image pre-staging is useful only for the initial image download. It is not suppo
**NT AUTHORITY\\Authenticated Users:(OI)(CI)(special access:)**
**                                READ\_CONTROL**
**READ\_CONTROL**
**                                                                                SYNCHRONIZE**
**SYNCHRONIZE**
**                                                                                FILE\_GENERIC\_READ**
**FILE\_GENERIC\_READ**
**                                                                                                FILE\_READ\_DATA**
**FILE\_READ\_DATA**
**                                                                                FILE\_READ\_EA**
**FILE\_READ\_EA**
**                                                                                FILE\_READ\_ATTRIBUTES**
**FILE\_READ\_ATTRIBUTES**
**NT AUTHORITY\\SYSTEM:(OI)(CI)F**

2
mdop/medv-v1/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft Enterprise Desktop Virtualization Planning, Deployment, and Operations Guide
description: Microsoft Enterprise Desktop Virtualization Planning, Deployment, and Operations Guide
author: jamiejdt
author: dansimp
ms.assetid: 7bc3e120-df77-4f4c-bc8e-7aaa4c2a6525
ms.pagetype: mdop, virtualization
ms.mktglfcycl: deploy

2
mdop/medv-v2/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft Enterprise Desktop Virtualization 2.0
description: Microsoft Enterprise Desktop Virtualization 2.0
author: jamiejdt
author: dansimp
ms.assetid: 84109be0-4613-42e9-85fc-fcda8de6e4c4
ms.pagetype: mdop, virtualization
ms.mktglfcycl: deploy

2
mdop/solutions/index.md
View File

@ -1,7 +1,7 @@
---
title: MDOP Solutions and Scenarios
description: MDOP Solutions and Scenarios
author: jamiejdt
author: dansimp
ms.assetid: 1cb18bef-fbae-4e96-a4f1-90cf111c3b5f
ms.pagetype: mdop
ms.mktglfcycl: deploy

2
mdop/uev-v1/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft User Experience Virtualization (UE-V) 1.0
description: Microsoft User Experience Virtualization (UE-V) 1.0
author: jamiejdt
author: dansimp
ms.assetid: 7c2b59f6-bbe9-4373-8b08-c1738665a37b
ms.pagetype: mdop, virtualization
ms.mktglfcycl: deploy

2
mdop/uev-v2/get-started-with-ue-v-2x-new-uevv2.md
View File

@ -193,7 +193,7 @@ You’ll need to deploy a settings storage location, a standard network share wh
**Security Note:  **
**Security Note:**
If you create the settings storage share on a computer running a Windows Server operating system, configure UE-V to verify that either the local Administrators group or the current user is the owner of the folder where settings packages are stored. To enable this additional security, specify this setting in the Windows Server Registry Editor:

2
mdop/uev-v2/index.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft User Experience Virtualization (UE-V) 2.x
description: Microsoft User Experience Virtualization (UE-V) 2.x
author: jamiejdt
author: dansimp
ms.assetid: b860fed0-b846-415d-bdd6-ba60231a64be
ms.pagetype: mdop, virtualization
ms.mktglfcycl: deploy

6
windows/application-management/remove-provisioned-apps-during-update.md
View File

@ -162,9 +162,13 @@ Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.ZuneMusic_8wekyb3d8bbwe]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.ZuneVideo_8wekyb3d8bbwe]
```
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.3DBuilder_8wekyb3d8bbwe]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.HEVCVideoExtension_8wekyb3d8bbwe]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\Microsoft.Messaging_8wekyb3d8bbwe]
```
[Get-AppxPackage](https://docs.microsoft.com/powershell/module/appx/get-appxpackage)
[Get-AppxPackage -allusers](https://docs.microsoft.com/powershell/module/appx/get-appxpackage)

3
windows/application-management/sideload-apps-in-windows-10.md
View File

@ -19,6 +19,9 @@ ms.date: 05/20/2019
- Windows 10
- Windows 10 Mobile
> [!NOTE]
> As of Windows Insider Build 18956, sideloading is enabled by default. Now, you can deploy a signed package onto a device without a special configuration.
"Line-of-Business" (LOB) apps are present in a wide range of businesses and organizations. Organizations value these apps because they solve problems unique to each business.
When you sideload an app, you deploy a signed app package to a device. You maintain the signing, hosting, and deployment of these apps. Sideloading was also available with Windows 8 and Windows 8.1

2
windows/client-management/advanced-troubleshooting-802-authentication.md
View File

@ -17,7 +17,7 @@ ms.topic: troubleshooting
## Overview
This is a general troubleshooting of 802.1X wireless and wired clients. With 802.1X and wireless troubleshooting, it's important to know how the flow of authentication works, and then figuring out where it's breaking. It involves a lot of third party devices and software. Most of the time, we have to identify where the problem is, and another vendor has to fix it. Since we don't make access points or wwitches, it won't be an end-to-end Microsoft solution.
This is a general troubleshooting of 802.1X wireless and wired clients. With 802.1X and wireless troubleshooting, it's important to know how the flow of authentication works, and then figuring out where it's breaking. It involves a lot of third party devices and software. Most of the time, we have to identify where the problem is, and another vendor has to fix it. Since we don't make access points or switches, it won't be an end-to-end Microsoft solution.
## Scenarios

20
windows/client-management/mdm/applocker-csp.md
View File

@ -156,22 +156,8 @@ Each of the previous nodes contains one or more of the following leaf nodes:
<tr class="odd">
<td><p><strong>Policy</strong></p></td>
<td><p>Policy nodes define the policy for launching executables, Windows Installer files, scripts, store apps, and DLL files. The contents of a given Policy node is precisely the XML format for a RuleCollection node in the corresponding AppLocker XML policy.</p>
<p>Policy nodes are a Base64-encoded blob of the binary policy representation. The binary policy may be signed or unsigned.</p>
<p>For CodeIntegrity/Policy, you can use the <a href="https://go.microsoft.com/fwlink/p/?LinkId=724364" data-raw-source="[certutil -encode](https://go.microsoft.com/fwlink/p/?LinkId=724364)">certutil -encode</a> command line tool to encode the data to base-64.</p>
<p>Here is a sample certutil invocation:</p>
```
certutil -encode WinSiPolicy.p7b WinSiPolicy.cer
```
<p>An alternative to using certutil would be to use the following PowerShell invocation:</p>
```
[Convert]::ToBase64String($(Get-Content -Encoding Byte -ReadCount 0 -Path <bin file>))
```
<p>If you are using hybrid MDM management with System Center Configuration Manager or using Intune, ensure that you are using Base64 as the Data type when using Custom OMA-URI functionality to apply the Code Integrity policy.</p>
<p>Data type is string. Supported operations are Get, Add, Delete, and Replace.</p></td>
<p>For nodes, other than CodeIntegrity, policy leaf data type is string. Supported operations are Get, Add, Delete, and Replace.</p>
<p>For CodeIntegrity/Policy, data type is Base64. Supported operations are Get, Add, Delete, and Replace.</td>
</tr>
<tr class="even">
<td><p><strong>EnforcementMode</strong></p></td>
@ -186,6 +172,8 @@ certutil -encode WinSiPolicy.p7b WinSiPolicy.cer
</tbody>
</table>
> [!NOTE]
> To use Code Integrity Policy, you first need to convert the policies to binary format using the ConvertFrom-CIPolicy cmdlet. Then a Base64-encoded blob of the binary policy representation should be created (for example, using the [certutil -encode](https://go.microsoft.com/fwlink/p/?LinkId=724364) command line tool) and added to the Applocker-CSP.
## <a href="" id="productname"></a>Find publisher and product name of apps

2
windows/client-management/mdm/appv-deploy-and-config.md
View File

@ -37,7 +37,7 @@ manager: dansimp
- LastErrorDescription
- SyncStatusDescription
- SyncProgress
- Sync
- Sync
- PublishXML
- AppVDynamicPolicy

34
windows/client-management/mdm/devicestatus-csp.md
View File

@ -277,23 +277,23 @@ Supported operation is Get.
<a href="" id="devicestatus-deviceguard-virtualizationbasedsecurityhwreq"></a>**DeviceStatus/DeviceGuard/VirtualizationBasedSecurityHwReq**
Added in Windows, version 1709. Virtualization-based security hardware requirement status. The value is a 256 value bitmask.
- 0x0: System meets hardware configuration requirements
- 0x1: SecureBoot required
- 0x2: DMA Protection required
- 0x4: HyperV not supported for Guest VM
- 0x8: HyperV feature is not available
- 0x0: System meets hardware configuration requirements
- 0x1: SecureBoot required
- 0x2: DMA Protection required
- 0x4: HyperV not supported for Guest VM
- 0x8: HyperV feature is not available
Supported operation is Get.
<a href="" id="devicestatus-deviceguard-virtualizationbasedsecuritystatus"></a>**DeviceStatus/DeviceGuard/VirtualizationBasedSecurityStatus**
Added in Windows, version 1709. Virtualization-based security status. Value is one of the following:
- 0 - Running
- 1 - Reboot required
- 2 - 64 bit architecture required
- 3 - not licensed
- 4 - not configured
- 5 - System doesn't meet hardware requirements
- 42 – Other. Event logs in Microsoft-Windows-DeviceGuard have more details
- 0 - Running
- 1 - Reboot required
- 2 - 64 bit architecture required
- 3 - not licensed
- 4 - not configured
- 5 - System doesn't meet hardware requirements
- 42 – Other. Event logs in Microsoft-Windows-DeviceGuard have more details
Supported operation is Get.
@ -301,11 +301,11 @@ Supported operation is Get.
<a href="" id="devicestatus-deviceguard-lsacfgcredguardstatus"></a>**DeviceStatus/DeviceGuard/LsaCfgCredGuardStatus**
Added in Windows, version 1709. Local System Authority (LSA) credential guard status.
- 0 - Running
- 1 - Reboot required
- 2 - Not licensed for Credential Guard
- 3 - Not configured
- 4 - VBS not running
- 0 - Running
- 1 - Reboot required
- 2 - Not licensed for Credential Guard
- 3 - Not configured
- 4 - VBS not running
Supported operation is Get.

15
windows/client-management/mdm/enable-admx-backed-policies-in-mdm.md
View File

@ -19,20 +19,23 @@ This is a step-by-step guide to configuring ADMX-backed policies in MDM.
Starting in Windows 10 version 1703, Mobile Device Management (MDM) policy configuration support was expanded to allow access of select Group Policy administrative templates (ADMX-backed policies) for Windows PCs via the [Policy configuration service provider (CSP)](policy-configuration-service-provider.md). Configuring ADMX-backed policies in Policy CSP is different from the typical way you configure a traditional MDM policy.
Summary of steps to enable a policy:
- Find the policy from the list ADMX-backed policies.
- Find the Group Policy related information from the MDM policy description.
- Use the Group Policy Editor to determine whether there are parameters necessary to enable the policy.
- Create the data payload for the SyncML.
- Find the policy from the list ADMX-backed policies.
- Find the Group Policy related information from the MDM policy description.
- Use the Group Policy Editor to determine whether there are parameters necessary to enable the policy.
- Create the data payload for the SyncML.
See [Support Tip: Ingesting Office ADMX-backed policies using Microsoft Intune](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Ingesting-Office-ADMX-Backed-policies-using/ba-p/354824) for a walk-through using Intune.
See [Support Tip: Ingesting Office ADMX-backed policies using Microsoft Intune](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Ingesting-Office-ADMX-Backed-policies-using/ba-p/354824) and [Deploying ADMX-Backed policies using Microsoft Intune](https://blogs.technet.microsoft.com/senthilkumar/2018/05/21/intune-deploying-admx-backed-policies-using-microsoft-intune/) for a walk-through using Intune.
>[!TIP]
>Intune has added a number of ADMX-backed administrative templates in public preview. Check if the policy settings you need are available in a template before using the SyncML method described below. [Learn more about Intune's administrative templates.](https://docs.microsoft.com/intune/administrative-templates-windows)
## Enable a policy
> [!NOTE]
> See [Understanding ADMX-backed policies](https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies).
1. Find the policy from the list [ADMX-backed policies](policy-configuration-service-provider.md#admx-backed-policies). You need the following information listed in the policy description.
- GP English name
- GP English name
- GP name
- GP ADMX file name
- GP path

18
windows/client-management/mdm/esim-enterprise-management.md
View File

@ -14,13 +14,13 @@ ms.topic:
# How Mobile Device Management Providers support eSIM Management on Windows
The eSIM Profile Management Solution puts the Mobile Device Management (MDM) Provider in the front and center. The whole idea is to leverage an already existing solution that customers are familiar with and that they use to manage devices. The expectations from an MDM are that it will leverage the same sync mechanism that it uses for device policies to push any policy to the eSIM profile, and be able to use Groups and Users the same way. This way, the eSIM profile download and installation happens on the background and not impacting the end user. Similarly, the IT admin would use the same method of managing the eSIM profiles (Assignment/de-assignment, etc.) the same way as they currently do device management.
If you are a Mobile Device Management (MDM) Provider and would like to support eSIM Management on Windows, you should do the following:
- Onboard to Azure Active Directory
- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, please contact them and learn more about their onboarding. If you would like to support multiple mobile operators, [orchestrator providers]( https://www.idemia.com/esim-management-facilitation) are there to act as a proxy that will handle MDM onboarding as well as mobile operator onboarding. Their main [role]( https://www.idemia.com/smart-connect-hub) is to enable the process to be as painless but scalable to all parties.
- Assess solution type that you would like to provide your customers
- Batch/offline solution
- IT Admin can manually import a flat file containing list of eSIM activation codes, and provision eSIM on LTE enabled devices.
- Operator does not have visibility over status of the eSIM profiles and device eSIM has been downloaded and installed to
- Real-time solution
- MDM automatically syncs with the Operator backend system for subscription pool and eSIM management, via sim vendor solution component. IT Admin can view subscription pool and provision eSIM in real time.
- Operator is notified of the status of each eSIM profile and has visibility on which devices are being used
- Onboard to Azure Active Directory
- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, please contact them and learn more about their onboarding. If you would like to support multiple mobile operators, [orchestrator providers]( https://www.idemia.com/esim-management-facilitation) are there to act as a proxy that will handle MDM onboarding as well as mobile operator onboarding. Their main [role]( https://www.idemia.com/smart-connect-hub) is to enable the process to be as painless but scalable to all parties.
- Assess solution type that you would like to provide your customers
- Batch/offline solution
- IT Admin can manually import a flat file containing list of eSIM activation codes, and provision eSIM on LTE enabled devices.
- Operator does not have visibility over status of the eSIM profiles and device eSIM has been downloaded and installed to
- Real-time solution
- MDM automatically syncs with the Operator backend system for subscription pool and eSIM management, via sim vendor solution component. IT Admin can view subscription pool and provision eSIM in real time.
- Operator is notified of the status of each eSIM profile and has visibility on which devices are being used
**Note:** The solution type is not noticeable to the end-user. The choice between the two is made between the MDM and the Mobile Operator.

2
windows/client-management/mdm/index.md
View File

@ -44,7 +44,7 @@ The MDM security baseline includes policies that cover the following areas:
For more details about the MDM policies defined in the MDM security baseline and what Microsoft’s recommended baseline policy values are, see:
- [MDM Security baseline for Windows 10, version 1903](https://download.microsoft.com/download/2/C/4/2C418EC7-31E0-4A74-8928-6DCD512F9A46/1903-MDM-SecurityBaseLine-Document.zip)
- [MDM Security baseline for Windows 10, version 1809](https://download.microsoft.com/download/2/C/4/2C418EC7-31E0-4A74-8928-6DCD512F9A46/1809-MDM-SecurityBaseLine-Document-[Preview].zip)
- [MDM Security baseline for Windows 10, version 1809](https://download.microsoft.com/download/2/C/4/2C418EC7-31E0-4A74-8928-6DCD512F9A46/1809-MDM-SecurityBaseLine-Document-[Preview].zip)
For information about the MDM policies defined in the Intune security baseline public preview, see [Windows security baseline settings for Intune](https://docs.microsoft.com/intune/security-baseline-settings-windows)

10
windows/client-management/mdm/networkqospolicy-csp.md
View File

@ -16,13 +16,13 @@ manager: dansimp
The NetworkQoSPolicy configuration service provider creates network Quality of Service (QoS) policies. A QoS policy performs a set of actions on network traffic based on a set of matching conditions. This CSP was added in Windows 10, version 1703.
The following conditions are supported:
- Network traffic from a specific application name
- Network traffic from specific source or destination ports
- Network traffic from a specific IP protocol (TCP, UDP, or both)
- Network traffic from a specific application name
- Network traffic from specific source or destination ports
- Network traffic from a specific IP protocol (TCP, UDP, or both)
The following actions are supported:
- Layer 2 tagging using a IEEE 802.1p priority value
- Layer 3 tagging using a differentiated services code point (DSCP) value
- Layer 2 tagging using a IEEE 802.1p priority value
- Layer 3 tagging using a differentiated services code point (DSCP) value
> [!NOTE]
> The NetworkQoSPolicy configuration service provider is supported only in Microsoft Surface Hub.

2
windows/client-management/mdm/policy-csp-applicationmanagement.md
View File

@ -537,7 +537,7 @@ Added in Windows 10, version 1607. Boolean value that disables the launch of al
<!--/Description-->
<!--ADMXMapped-->
ADMX Info:
- GP English name: *Disable all apps from Microsoft Store *
- GP English name: *Disable all apps from Microsoft Store*
- GP name: *DisableStoreApps*
- GP path: *Windows Components/Store*
- GP ADMX file name: *WindowsStore.admx*

6
windows/client-management/mdm/policy-csp-browser.md
View File

@ -629,9 +629,9 @@ ADMX Info:
<!--SupportedValues-->
Supported values:
- Blank (default) - Do not send tracking information but let users choose to send tracking information to sites they visit.
- 0 - Never send tracking information.
- 1 - Send tracking information.
- Blank (default) - Do not send tracking information but let users choose to send tracking information to sites they visit.
- 0 - Never send tracking information.
- 1 - Send tracking information.
Most restricted value: 1
<!--/SupportedValues-->

12
windows/client-management/mdm/policy-csp-devicelock.md
View File

@ -387,12 +387,12 @@ Specifies whether device lock is enabled.
> [!Important]
> **DevicePasswordEnabled** should not be set to Enabled (0) when WMI is used to set the EAS DeviceLock policies given that it is Enabled by default in Policy CSP for back compat with Windows 8.x. If **DevicePasswordEnabled** is set to Enabled(0) then Policy CSP will return an error stating that **DevicePasswordEnabled** already exists. Windows 8.x did not support DevicePassword policy. When disabling **DevicePasswordEnabled** (1) then this should be the only policy set from the DeviceLock group of policies listed below:
> - **DevicePasswordEnabled** is the parent policy of the following:
> - AllowSimpleDevicePassword
> - MinDevicePasswordLength
> - AlphanumericDevicePasswordRequired
> - MinDevicePasswordComplexCharacters 
> - DevicePasswordExpiration
> - DevicePasswordHistory
> - AllowSimpleDevicePassword
> - MinDevicePasswordLength
> - AlphanumericDevicePasswordRequired
> - MinDevicePasswordComplexCharacters 
> - DevicePasswordExpiration
> - DevicePasswordHistory
> - MaxDevicePasswordFailedAttempts
> - MaxInactivityTimeDeviceLock

4
windows/client-management/mdm/policy-csp-internetexplorer.md
View File

@ -13428,7 +13428,7 @@ For more information, see "Outdated ActiveX Controls" in the Internet Explorer T
<!--ADMXBacked-->
ADMX Info:
- GP English name: *Remove "Run this time" button for outdated ActiveX controls in Internet Explorer *
- GP English name: *Remove "Run this time" button for outdated ActiveX controls in Internet Explorer*
- GP name: *VerMgmtDisableRunThisTime*
- GP path: *Windows Components/Internet Explorer/Security Features/Add-on Management*
- GP ADMX file name: *inetres.admx*
@ -16504,7 +16504,7 @@ Also, see the "Security zones: Do not allow users to change policies" policy.
<!--ADMXBacked-->
ADMX Info:
- GP English name: *Security Zones: Use only machine settings *
- GP English name: *Security Zones: Use only machine settings*
- GP name: *Security_HKLM_only*
- GP path: *Windows Components/Internet Explorer*
- GP ADMX file name: *inetres.admx*

2
windows/client-management/mdm/policy-csp-remotemanagement.md
View File

@ -365,7 +365,7 @@ If you disable or do not configure this policy setting, the WinRM service will n
The service listens on the addresses specified by the IPv4 and IPv6 filters. The IPv4 filter specifies one or more ranges of IPv4 addresses, and the IPv6 filter specifies one or more ranges of IPv6addresses. If specified, the service enumerates the available IP addresses on the computer and uses only addresses that fall within one of the filter ranges.
You should use an asterisk (*) to indicate that the service listens on all available IP addresses on the computer. When * is used, other ranges in the filter are ignored. If the filter is left blank, the service does not listen on any addresses.
You should use an asterisk (\*) to indicate that the service listens on all available IP addresses on the computer. When \* is used, other ranges in the filter are ignored. If the filter is left blank, the service does not listen on any addresses.
For example, if you want the service to listen only on IPv4 addresses, leave the IPv6 filter empty.

10
windows/client-management/mdm/policy-csp-settings.md
View File

@ -806,11 +806,11 @@ If the policy is not specified, the behavior will be that no pages are affected.
The format of the PageVisibilityList value is as follows:
- The value is a unicode string up to 10,000 characters long, which will be used without case sensitivity.
- There are two variants: one that shows only the given pages and one which hides the given pages.
- The first variant starts with the string "showonly:" and the second with the string "hide:".
- Following the variant identifier is a semicolon-delimited list of page identifiers, which must not have any extra whitespace.
- Each page identifier is the ms-settings:xyz URI for the page, minus the ms-settings: prefix, so the identifier for the page with URI "ms-settings:network-wifi" would be just "network-wifi".
- The value is a unicode string up to 10,000 characters long, which will be used without case sensitivity.
- There are two variants: one that shows only the given pages and one which hides the given pages.
- The first variant starts with the string "showonly:" and the second with the string "hide:".
- Following the variant identifier is a semicolon-delimited list of page identifiers, which must not have any extra whitespace.
- Each page identifier is the ms-settings:xyz URI for the page, minus the ms-settings: prefix, so the identifier for the page with URI "ms-settings:network-wifi" would be just "network-wifi".
The default value for this setting is an empty string, which is interpreted as show everything.

4
windows/client-management/mdm/policy-csp-system.md
View File

@ -1068,7 +1068,7 @@ If you disable or don't configure this policy setting, the Delete diagnostic dat
<!--/Description-->
<!--ADMXMapped-->
ADMX Info:
- GP English name: *Disable deleting diagnostic data *
- GP English name: *Disable deleting diagnostic data*
- GP name: *DisableDeviceDelete*
- GP element: *DisableDeviceDelete*
- GP path: *Data Collection and Preview Builds*
@ -1131,7 +1131,7 @@ If you disable or don't configure this policy setting, the Diagnostic Data Viewe
<!--/Description-->
<!--ADMXMapped-->
ADMX Info:
- GP English name: *Disable diagnostic data viewer. *
- GP English name: *Disable diagnostic data viewer.*
- GP name: *DisableDiagnosticDataViewer*
- GP element: *DisableDiagnosticDataViewer*
- GP path: *Data Collection and Preview Builds*

6
windows/client-management/mdm/policy-csp-update.md
View File

@ -1053,7 +1053,7 @@ Supported values:
<!--/Scope-->
<!--Description-->
Added in Windows 10, version 1607. Allows the IT admin to set which branch a device receives their updates from.
Added in Windows 10, version 1607. Allows the IT admin to set which branch a device receives their updates from. As of 1903, the branch readiness levels of Semi-Annual Channel (Targeted) and Semi-Annual Channel have been combined into one Semi-Annual Channel set with a value of 16. For devices on 1903 and later releases, the value of 32 is not a supported value.
<!--/Description-->
<!--ADMXMapped-->
@ -1071,8 +1071,8 @@ The following list shows the supported values:
- 2 {0x2} - Windows Insider build - Fast (added in Windows 10, version 1709)
- 4 {0x4} - Windows Insider build - Slow (added in Windows 10, version 1709)
- 8 {0x8} - Release Windows Insider build (added in Windows 10, version 1709)
- 16 {0x10} - (default) Semi-annual Channel (Targeted). Device gets all applicable feature updates from Semi-annual Channel (Targeted).
- 32 {0x20} - Semi-annual Channel. Device gets feature updates from Semi-annual Channel.
- 16 {0x10} - (default) Semi-annual Channel (Targeted). Device gets all applicable feature updates from Semi-annual Channel (Targeted).
- 32 {0x20} - Semi-annual Channel. Device gets feature updates from Semi-annual Channel. (*Only applicable to releases prior to 1903)
<!--/SupportedValues-->
<!--/Policy-->

22
windows/client-management/mdm/understanding-admx-backed-policies.md
View File

@ -23,8 +23,8 @@ In addition to standard policies, the Policy CSP can now also handle ADMX-backed
ADMX files can either describe operating system (OS) Group Policies that are shipped with Windows or they can describe settings of applications, which are separate from the OS and can usually be downloaded and installed on a PC.
Depending on the specific category of the settings that they control (OS or application), the administrative template settings are found in the following two locations in the Local Group Policy Editor:
- OS settings: Computer Configuration/Administrative Templates
- Application settings: User Configuration/Administrative Templates
- OS settings: Computer Configuration/Administrative Templates
- Application settings: User Configuration/Administrative Templates
In a domain controller/Group Policy ecosystem, Group Policies are automatically added to the registry of the client computer or user profile by the Administrative Templates Client Side Extension (CSE) whenever the client computer processes a Group Policy. Conversely, in an MDM-managed client, ADMX files are leveraged to define policies independent of Group Policies. Therefore, in an MDM-managed client, a Group Policy infrastructure, including the Group Policy Service (gpsvc.exe), is not required.
@ -42,17 +42,17 @@ To capture the end-to-end MDM handling of ADMX Group Policies, an IT administrat
The ADMX file that the MDM ISV uses to determine what UI to display to the IT administrator is the same ADMX file that the client uses for the policy definition. The ADMX file is processed either by the OS at build time or set by the client at OS runtime. In either case, the client and the MDM ISV must be synchronized with the ADMX policy definitions. Each ADMX file corresponds to a Group Policy category and typically contains several policy definitions, each of which represents a single Group Policy. For example, the policy definition for the “Publishing Server 2 Settings” is contained in the appv.admx file, which holds the policy definitions for the Microsoft Application Virtualization (App-V) Group Policy category.
Group Policy option button setting:
- If **Enabled** is selected, the necessary data entry controls are displayed for the user in the UI. When IT administrator enters the data and clicks **Apply**, the following events occur:
- The MDM ISV server sets up a Replace SyncML command with a payload that contains the user-entered data.
- The MDM client stack receives this data, which causes the Policy CSP to update the device’s registry per the ADMX-backed policy definition.
- If **Enabled** is selected, the necessary data entry controls are displayed for the user in the UI. When IT administrator enters the data and clicks **Apply**, the following events occur:
- The MDM ISV server sets up a Replace SyncML command with a payload that contains the user-entered data.
- The MDM client stack receives this data, which causes the Policy CSP to update the device’s registry per the ADMX-backed policy definition.
- If **Disabled** is selected and you click **Apply**, the following events occur:
- The MDM ISV server sets up a Replace SyncML command with a payload set to `<disabled\>`.
- The MDM client stack receives this command, which causes the Policy CSP to either delete the device’s registry settings, set the registry keys, or both, per the state change directed by the ADMX-backed policy definition.
- If **Disabled** is selected and you click **Apply**, the following events occur:
- The MDM ISV server sets up a Replace SyncML command with a payload set to `<disabled\>`.
- The MDM client stack receives this command, which causes the Policy CSP to either delete the device’s registry settings, set the registry keys, or both, per the state change directed by the ADMX-backed policy definition.
- If **Not Configured** is selected and you click **Apply**, the following events occur:
- MDM ISV server sets up a Delete SyncML command.
- The MDM client stack receives this command, which causes the Policy CSP to delete the device’s registry settings per the ADMX-backed policy definition.
- If **Not Configured** is selected and you click **Apply**, the following events occur:
- MDM ISV server sets up a Delete SyncML command.
- The MDM client stack receives this command, which causes the Policy CSP to delete the device’s registry settings per the ADMX-backed policy definition.
The following diagram shows the main display for the Group Policy Editor.

12
windows/client-management/mdm/windowslicensing-csp.md
View File

@ -196,7 +196,7 @@ Values:
**CheckApplicability**
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Exec>
@ -223,7 +223,7 @@ Values:
**Edition**
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Get>
@ -241,7 +241,7 @@ Values:
**LicenseKeyType**
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Get>
@ -259,7 +259,7 @@ Values:
**Status**
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Get>
@ -277,7 +277,7 @@ Values:
**UpgradeEditionWithProductKey**
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Exec>
@ -304,7 +304,7 @@ Values:
**UpgradeEditionWithLicense**
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Exec>

2
windows/client-management/mdm/windowssecurityauditing-csp.md
View File

@ -39,7 +39,7 @@ Supported operations are Get and Replace.
Enable logging of audit events.
``` syntax
```xml
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>

2
windows/client-management/troubleshoot-inaccessible-boot-device.md
View File

@ -171,7 +171,7 @@ Run the following command to verify the Windows update installation and dates:
Dism /Image:<Specify the OS drive>: /Get-packages
```
After you run this command, you will see the **Install pending** and **Uninstall Pending ** packages:
After you run this command, you will see the **Install pending** and **Uninstall Pending** packages:
![Dism output](images/pendingupdate.png)

4
windows/client-management/troubleshoot-stop-errors.md
View File

@ -107,8 +107,8 @@ You can use the Microsoft DumpChk (Crash Dump File Checker) tool to verify that
More information on how to use Dumpchk.exe to check your dump files:
- [Using DumpChk]( https://docs.microsoft.com/windows-hardware/drivers/debugger/dumpchk)
- [Download DumpCheck](https://developer.microsoft.com/windows/downloads/windows-10-sdk)
- [Using DumpChk]( https://docs.microsoft.com/windows-hardware/drivers/debugger/dumpchk)
- [Download DumpCheck](https://developer.microsoft.com/windows/downloads/windows-10-sdk)
### Pagefile Settings

4
windows/client-management/troubleshoot-windows-freeze.md
View File

@ -145,8 +145,8 @@ If the computer is no longer frozen and now is running in a good state, use the
Use the Dump Check Utility (Dumpchk.exe) to read a memory dump file or verify that the file was created correctly. You can use the Microsoft DumpChk (Crash Dump File Checker) tool to verify that the memory dump files are not corrupted or invalid.
- [Using DumpChk]( https://docs.microsoft.com/windows-hardware/drivers/debugger/dumpchk)
- [Download DumpCheck](https://developer.microsoft.com/windows/downloads/windows-10-sdk)
- [Using DumpChk]( https://docs.microsoft.com/windows-hardware/drivers/debugger/dumpchk)
- [Download DumpCheck](https://developer.microsoft.com/windows/downloads/windows-10-sdk)
Learn how to use Dumpchk.exe to check your dump files:

28
windows/client-management/windows-10-mobile-and-mdm.md
View File

@ -27,11 +27,11 @@ Employees increasingly depend on smartphones to complete daily work tasks, but t
Windows 10 supports end-to-end device lifecycle management to give companies control over their devices, data, and apps. Devices can easily be incorporated into standard lifecycle practices, from device enrollment, configuration, and application management to maintenance, monitoring, and retirement using a comprehensive mobile device management solution.
**In this article**
- [Deploy](#deploy)
- [Configure](#configure)
- [Apps](#apps)
- [Manage](#manage)
- [Retire](#retire)
- [Deploy](#deploy)
- [Configure](#configure)
- [Apps](#apps)
- [Manage](#manage)
- [Retire](#retire)
## Deploy
@ -365,18 +365,18 @@ You can define and deploy APN profiles in MDM systems that configure cellular da
- **APN name** The APN name
- *IP connection type* The IP connection type; set to one of the following values:
- IPv4 only
- IPv6 only
- IPv4 and IPv6 concurrently
- IPv6 with IPv4 provided by 46xlat
- IPv4 only
- IPv6 only
- IPv4 and IPv6 concurrently
- IPv6 with IPv4 provided by 46xlat
- **LTE attached** Whether the APN should be attached as part of an LTE Attach
- **APN class ID** The globally unique identifier that defines the APN class to the modem
- **APN authentication type** The APN authentication type; set to one of the following values:
- None
- Auto
- PAP
- CHAP
- MSCHAPv2
- None
- Auto
- PAP
- CHAP
- MSCHAPv2
- **User name** The user account when users select Password Authentication Protocol (PAP), CHAP, or MSCHAPv2 authentication in APN authentication type
- **Password** The password for the user account specified in User name
- **Integrated circuit card ID** The integrated circuit card ID associated with the cellular connection profile

2
windows/configuration/customize-and-export-start-layout.md
View File

@ -176,7 +176,7 @@ If the Start layout is applied by Group Policy or MDM, and the policy is removed
2. [Export the Start layout](#export-the-start-layout).
3. Open the layout .xml file. There is a `<DefaultLayoutOverride>` element. Add `LayoutCustomizationRestrictionType="OnlySpecifiedGroups"` to the **DefaultLayoutOverride** element as follows:
``` syntax
```xml
<DefaultLayoutOverride LayoutCustomizationRestrictionType="OnlySpecifiedGroups">
```

2
windows/configuration/guidelines-for-assigned-access-app.md
View File

@ -68,7 +68,7 @@ In Windows 10, version 1803 and later, you can install the **Kiosk Browser** app
Kiosk Browser settings | Use this setting to
--- | ---
Blocked URL Exceptions | Specify URLs that people can navigate to, even though the URL is in your blocked URL list. You can use wildcards. <br><br>For example, if you want people to be limited to `contoso.com` only, you would add `contoso.com` to blocked URL exception list and then block all other URLs.
Blocked URL Exceptions | Specify URLs that people can navigate to, even though the URL is in your blocked URL list. You can use wildcards. <br><br>For example, if you want people to be limited to `http://contoso.com` only, you would add `.contoso.com` to blocked URL exception list and then block all other URLs.
Blocked URLs | Specify URLs that people can't navigate to. You can use wildcards. <br><br>If you want to limit people to a specific site, add `https://*` to the blocked URL list, and then specify the site to be allowed in the blocked URL exceptions list.
Default URL | Specify the URL that Kiosk Browser will open with. **Tip!** Make sure your blocked URLs don't include your default URL.
Enable End Session Button | Show a button in Kiosk Browser that people can use to reset the browser. End Session will clear all browsing data and navigate back to the default URL.

12
windows/configuration/kiosk-xml.md
View File

@ -26,7 +26,7 @@ ms.topic: article
## Full XML sample
>[!NOTE]
>Updated for Windows 10, version 1903, and Windows 10 Prerelease
>Updated for Windows 10, version 1903, and Windows 10 Insider Preview (19H2, 20H1 builds).
```xml
<?xml version="1.0" encoding="utf-8" ?>
@ -255,7 +255,7 @@ This sample demonstrates that both UWP and Win32 apps can be configured to autom
```
## [Preview] Global Profile Sample XML
Global Profile is currently supported in Windows 10 Prerelease. Global Profile is designed for scenarios where a user does not have a designated profile, yet IT Admin still wants the user to run in lock down mode, or used as mitigation when a profile cannot be determined for an user.
Global Profile is currently supported in Windows 10 Insider Preview (19H2, 20H1 builds). Global Profile is designed for scenarios where a user does not have a designated profile, yet IT Admin still wants the user to run in lock down mode, or used as mitigation when a profile cannot be determined for an user.
This sample demonstrates that only a global profile is used, no active user configured. Global profile will be applied when every non-admin account logs in
```xml
@ -394,7 +394,7 @@ Below sample shows dedicated profile and global profile mixed usage, aauser woul
```
## [Preview] Folder Access sample xml
In Windows 10 1809 release, folder access is locked down that when common file dialog is opened, IT Admin can specify if user has access to the Downloads folder, or no access to any folder at all. This restriction has be redesigned for finer granulatity and easier use, available in current Windows 10 Prerelease.
In Windows 10, version 1809, folder access is locked down so that when common file dialog is opened, IT Admin can specify if the user has access to the Downloads folder, or no access to any folder at all. This restriction has been redesigned for finer granulatity and easier use, and is available in Windows 10 Insider Preview (19H2, 20H1 builds).
IT Admin now can specify user access to Downloads folder, Removable drives, or no restrictions at all. Note that Downloads and Removable Drives can be allowed at the same time.
@ -636,7 +636,7 @@ IT Admin now can specify user access to Downloads folder, Removable drives, or n
## XSD for AssignedAccess configuration XML
>[!NOTE]
>Updated for Windows 10, version 1903 and Windows 10 Prerelease.
>Updated for Windows 10, version 1903 and Windows 10 Insider Preview (19H2, 20H1 builds).
Below schema is for AssignedAccess Configuration up to Windows 10 1803 release.
```xml
@ -859,7 +859,7 @@ Here is the schema for new features introduced in Windows 10 1809 release
</xs:schema>
```
Schema for Windows 10 prerelease
Schema for Windows 10 Insider Preview (19H2, 20H1 builds)
```xml
<?xml version="1.0" encoding="utf-8"?>
<xs:schema
@ -889,7 +889,7 @@ Schema for Windows 10 prerelease
</xs:schema>
```
To authorize a compatible configuration XML that includes 1809 or prerelease elements and attributes, always include the namespace of these add-on schemas, and decorate the attributes and elements accordingly with the namespace alias. e.g. to configure auto-launch feature which is added in 1809 release, use below sample, notice an alias r1809 is given to the 201810 namespace for 1809 release, and the alias is tagged on AutoLaunch and AutoLaunchArguments inline.
To authorize a compatible configuration XML that includes elements and attributes from Windows 10, version 1809 or newer, always include the namespace of these add-on schemas, and decorate the attributes and elements accordingly with the namespace alias. For example, to configure the auto-launch feature which is added in Windows 10, version 1809, use the following sample. Notice an alias r1809 is given to the 201810 namespace for Windows 10, version 1809, and the alias is tagged on AutoLaunch and AutoLaunchArguments inline.
```xml
<AssignedAccessConfiguration
xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"

2
windows/configuration/mobile-devices/settings-that-can-be-locked-down.md
View File

@ -462,7 +462,7 @@ Quick action buttons are locked down in exactly the same way as Settings pages/g
You can specify the quick actions as follows:
``` syntax
```xml
<Settings>
<System name="QuickActions_Launcher_AllSettings" />
<System name="QuickActions_Launcher_DeviceDiscovery" />

3
windows/configuration/start-layout-xml-desktop.md
View File

@ -53,6 +53,7 @@ The XML schema for `LayoutModification.xml` requires the following order for tag
1. TopMFUApps
1. CustomTaskbarLayoutCollection
1. InkWorkspaceTopApps
1. StartLayoutCollection
Comments are not supported in the `LayoutModification.xml` file.
@ -66,6 +67,8 @@ Comments are not supported in the `LayoutModification.xml` file.
>- Do not add multiple rows of comments.
The following table lists the supported elements and attributes for the LayoutModification.xml file.
> [!NOTE]
> RequiredStartGroupsCollection and AppendGroup syntax only apply when the Import-StartLayout method is used for building and deploying Windows images.
| Element | Attributes | Description |
| --- | --- | --- |

18
windows/configuration/ue-v/uev-application-template-schema-reference.md
View File

@ -241,7 +241,7 @@ Version identifies the version of the settings location template for administrat
**Hint:** You can save notes about version changes using XML comment tags `<!-- -->`, for example:
``` syntax
```xml
<!--
Version History
@ -280,7 +280,7 @@ Author identifies the creator of the settings location template. Two optional ch
Processes contains at least one `<Process>` element, which in turn contains the following child elements: **Filename**, **Architecture**, **ProductName**, **FileDescription**, **ProductVersion**, and **FileVersion**. The Filename child element is mandatory and the others are optional. A fully populated element contains tags similar to this example:
``` syntax
```xml
<Process>
<Filename>MyApplication.exe</Filename>
<Architecture>Win64</Architecture>
@ -355,7 +355,7 @@ UE-V does not support ARM processors in this version.
ProductName is an optional element used to identify a product for administrative purposes or reporting. ProductName differs from Filename in that there are no regular expression restrictions on its value. This allows for more easily understood descriptions of a process where the executable name may not be obvious. For example:
``` syntax
```xml
<Process>
<Filename>MyApplication.exe</Filename>
<ProductName>My Application 6.x by Contoso.com</ProductName>
@ -375,7 +375,7 @@ FileDescription is an optional tag that allows for an administrative description
For example, in a suited application, it might be useful to provide reminders about the function of two executables (MyApplication.exe and MyApplicationHelper.exe), as shown here:
``` syntax
```xml
<Processes>
<Process>
@ -409,7 +409,7 @@ The product and file version elements may be left unspecified. Doing so makes th
Product version: 1.0 specified in the UE-V template generator produces the following XML:
``` syntax
```xml
<ProductVersion>
<Major Minimum="1" Maximum="1" />
<Minor Minimum="0" Maximum="0" />
@ -420,7 +420,7 @@ Product version: 1.0 specified in the UE-V template generator produces the follo
File version: 5.0.2.1000 specified in the UE-V template generator produces the following XML:
``` syntax
```xml
<FileVersion>
<Major Minimum="5" Maximum="5" />
<Minor Minimum="0" Maximum="0" />
@ -433,7 +433,7 @@ File version: 5.0.2.1000 specified in the UE-V template generator produces the f
Only the Minimum attribute is present. Maximum must be included in a range as well.
``` syntax
```xml
<ProductVersion>
<Major Minimum="2" />
</ProductVersion>
@ -443,7 +443,7 @@ Only the Minimum attribute is present. Maximum must be included in a range as we
Only the Minor element is present. Major must be included as well.
``` syntax
```xml
<ProductVersion>
<Minor Minimum="0" Maximum="0" />
</ProductVersion>
@ -463,7 +463,7 @@ Including a FileVersion element for an application allows for more granular fine
The child elements and syntax rules for FileVersion are identical to those of ProductVersion.
``` syntax
```xml
<Process>
<Filename>MSACCESS.EXE</Filename>
<Architecture>Win32</Architecture>

4
windows/configuration/ue-v/uev-manage-administrative-backup-and-restore.md
View File

@ -26,7 +26,7 @@ As an administrator of User Experience Virtualization (UE-V), you can restore ap
To restore settings when a user adopts a new device, you can put a settings location template in **backup** or **roam (default)** profile using the Set-UevTemplateProfile PowerShell cmdlet. This lets computer settings sync to the new computer, in addition to user settings. Templates assigned to the backup profile are backed up for that device and configured on a per-device basis. To backup settings for a template, use the following cmdlet in Windows PowerShell:
``` syntax
```powershell
Set-UevTemplateProfile -ID <TemplateID> -Profile <backup>
```
@ -38,7 +38,7 @@ When replacing a user’s device, UE-V automatically restores settings if the us
You can also use the Windows PowerShell cmdlet, Restore-UevBackup, to restore settings from a different device. To clone the settings packages for the new device, use the following cmdlet in Windows PowerShell:
``` syntax
```powershell
Restore-UevBackup -ComputerName <Computer name>
```

6
windows/configuration/ue-v/uev-managing-settings-location-templates-using-windows-powershell-and-wmi.md
View File

@ -172,7 +172,7 @@ The UE-V Windows PowerShell features enable you to manage a group of settings te
4. Unregister all the previously registered versions of the templates by typing the following command.
``` syntax
```powershell
Unregister-UevTemplate -All
```
@ -180,7 +180,7 @@ The UE-V Windows PowerShell features enable you to manage a group of settings te
5. Register the updated templates by typing the following command.
``` syntax
```powershell
Register-UevTemplate <path to template folder>\*.xml
```
@ -192,7 +192,7 @@ By listing a Windows app in the Windows app list, you specify whether that app i
To display the Package Family Name of installed Windows apps, at a Windows PowerShell command prompt, enter:
``` syntax
```powershell
Get-AppxPackage | Sort-Object PackageFamilyName | Format-Table PackageFamilyName
```

2
windows/configuration/ue-v/uev-synchronizing-microsoft-office-with-uev.md
View File

@ -131,7 +131,7 @@ You can deploy UE-V settings location template with the following methods:
- **Registering template with PowerShell**. If you use Windows PowerShell to manage computers, run the following Windows PowerShell command as Administrator to register this settings location template:
``` syntax
```powershell
Register-UevTemplate -Path <Path_to_Template>
```

6
windows/configuration/windows-10-accessibility-for-ITPros.md
View File

@ -19,9 +19,9 @@ Microsoft is dedicated to making its products and services accessible and usable
This topic helps IT administrators learn about built-in accessibility features, and includes a few recommendations for how to support people in your organization who use these features.
## General recommendations
- **Be aware of Ease of Access settings** – Understand how people in your organization might use these settings. Help people in your organization learn how they can customize Windows 10.
- **Do not block settings** – Avoid using Group Policy or MDM settings that override Ease of Access settings.
- **Encourage choice** – Allow people in your organization to customize their computers based on their needs. That might mean installing an add-on for their browser, or a non-Microsoft assistive technology.
- **Be aware of Ease of Access settings** – Understand how people in your organization might use these settings. Help people in your organization learn how they can customize Windows 10.
- **Do not block settings** – Avoid using Group Policy or MDM settings that override Ease of Access settings.
- **Encourage choice** – Allow people in your organization to customize their computers based on their needs. That might mean installing an add-on for their browser, or a non-Microsoft assistive technology.
## Vision

273
windows/deployment/deploy-windows-mdt/assign-applications-using-roles-in-mdt.md
View File

@ -1,136 +1,137 @@
---
title: Assign applications using roles in MDT (Windows 10)
description: This topic will show you how to add applications to a role in the MDT database and then assign that role to a computer.
ms.assetid: d82902e4-de9c-4bc4-afe0-41d649b83ce7
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: settings, database, deploy
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Assign applications using roles in MDT
This topic will show you how to add applications to a role in the MDT database and then assign that role to a computer. For the purposes of this topic, the application we are adding is Adobe Reader XI. In addition to using computer-specific entries in the database, you can use roles in MDT to group settings together.
## <a href="" id="sec01"></a>Create and assign a role entry in the database
1. On MDT01, using Deployment Workbench, in the MDT Production deployment share, expand **Advanced Configuration** and then expand **Database**.
2. In the **Database** node, right-click **Role**, select **New**, and create a role entry with the following settings:
1. Role name: Standard PC
2. Applications / Lite Touch Applications:
3. Install - Adobe Reader XI - x86
![figure 12](../images/mdt-09-fig12.png)
Figure 12. The Standard PC role with the application added
## <a href="" id="sec02"></a>Associate the role with a computer in the database
After creating the role, you can associate it with one or more computer entries.
1. Using Deployment Workbench, expand **MDT Production**, expand **Advanced Configuration**, expand **Database**, and select **Computers**.
2. In the **Computers** node, double-click the **PC00075** entry, and add the following setting:
- Roles: Standard PC
![figure 13](../images/mdt-09-fig13.png)
Figure 13. The Standard PC role added to PC00075 (having ID 1 in the database).
## <a href="" id="sec03"></a>Verify database access in the MDT simulation environment
When the database is populated, you can use the MDT simulation environment to simulate a deployment. The applications are not installed, but you can see which applications would be installed if you did a full deployment of the computer.
1. On PC0001, log on as **CONTOSO\\MDT\_BA**.
2. Modify the C:\\MDT\\CustomSettings.ini file to look like the following:
``` syntax
[Settings]
Priority=CSettings, CRoles, RApplications, Default
[Default]
_SMSTSORGNAME=Contoso
OSInstall=Y
UserDataLocation=AUTO
TimeZoneName=Pacific Standard Time
AdminPassword=P@ssw0rd
JoinDomain=contoso.com
DomainAdmin=CONTOSO\MDT_JD
DomainAdminPassword=P@ssw0rd
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
SLShare=\\MDT01\Logs$
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
HideShell=YES
ApplyGPOPack=NO
SkipAppsOnUpgrade=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=NO
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=NO
SkipBitLocker=YES
SkipSummary=YES
SkipCapture=YES
SkipFinalSummary=NO
EventService=http://MDT01:9800
[CSettings]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
[CRoles]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
[RApplications]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=RoleApplications
Parameters=Role
Order=Sequence
```
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press **Enter** after each command:
``` syntax
Set-Location C:\MDT
.\Gather.ps1
```
![figure 14](../images/mdt-09-fig14.png)
Figure 14. ZTIGather.log displaying the application GUID belonging to the Adobe Reader XI application that would have been installed if you deployed this machine.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
<BR>[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
<BR>[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
<BR>[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
<BR>[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
<BR>[Use web services in MDT](use-web-services-in-mdt.md)
<BR>[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
 
 
---
title: Assign applications using roles in MDT (Windows 10)
description: This topic will show you how to add applications to a role in the MDT database and then assign that role to a computer.
ms.assetid: d82902e4-de9c-4bc4-afe0-41d649b83ce7
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: settings, database, deploy
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Assign applications using roles in MDT
This topic will show you how to add applications to a role in the MDT database and then assign that role to a computer. For the purposes of this topic, the application we are adding is Adobe Reader XI. In addition to using computer-specific entries in the database, you can use roles in MDT to group settings together.
## <a href="" id="sec01"></a>Create and assign a role entry in the database
1. On MDT01, using Deployment Workbench, in the MDT Production deployment share, expand **Advanced Configuration** and then expand **Database**.
2. In the **Database** node, right-click **Role**, select **New**, and create a role entry with the following settings:
1. Role name: Standard PC
2. Applications / Lite Touch Applications:
3. Install - Adobe Reader XI - x86
![figure 12](../images/mdt-09-fig12.png)
Figure 12. The Standard PC role with the application added
## <a href="" id="sec02"></a>Associate the role with a computer in the database
After creating the role, you can associate it with one or more computer entries.
1. Using Deployment Workbench, expand **MDT Production**, expand **Advanced Configuration**, expand **Database**, and select **Computers**.
2. In the **Computers** node, double-click the **PC00075** entry, and add the following setting:
- Roles: Standard PC
![figure 13](../images/mdt-09-fig13.png)
Figure 13. The Standard PC role added to PC00075 (having ID 1 in the database).
## <a href="" id="sec03"></a>Verify database access in the MDT simulation environment
When the database is populated, you can use the MDT simulation environment to simulate a deployment. The applications are not installed, but you can see which applications would be installed if you did a full deployment of the computer.
1. On PC0001, log on as **CONTOSO\\MDT\_BA**.
2. Modify the C:\\MDT\\CustomSettings.ini file to look like the following:
```
[Settings]
Priority=CSettings, CRoles, RApplications, Default
[Default]
_SMSTSORGNAME=Contoso
OSInstall=Y
UserDataLocation=AUTO
TimeZoneName=Pacific Standard Time
AdminPassword=P@ssw0rd
JoinDomain=contoso.com
DomainAdmin=CONTOSO\MDT_JD
DomainAdminPassword=P@ssw0rd
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
SLShare=\\MDT01\Logs$
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
HideShell=YES
ApplyGPOPack=NO
SkipAppsOnUpgrade=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=NO
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=NO
SkipBitLocker=YES
SkipSummary=YES
SkipCapture=YES
SkipFinalSummary=NO
EventService=http://MDT01:9800
[CSettings]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
[CRoles]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
[RApplications]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=RoleApplications
Parameters=Role
Order=Sequence
```
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press **Enter** after each command:
``` powershell
Set-Location C:\MDT
.\Gather.ps1
```
![figure 14](../images/mdt-09-fig14.png)
Figure 14. ZTIGather.log displaying the application GUID belonging to the Adobe Reader XI application that would have been installed if you deployed this machine.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
<BR>[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
<BR>[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
<BR>[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
<BR>[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
<BR>[Use web services in MDT](use-web-services-in-mdt.md)
<BR>[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
 
 

457
windows/deployment/deploy-windows-mdt/build-a-distributed-environment-for-windows-10-deployment.md
View File

@ -1,228 +1,229 @@
---
title: Build a distributed environment for Windows 10 deployment (Windows 10)
description: In this topic, you will learn how to replicate your Windows 10 deployment shares to facilitate the deployment of Windows 10 in remote or branch locations.
ms.assetid: a6cd5657-6a16-4fff-bfb4-44760902d00c
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: replication, replicate, deploy, configure, remote
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Build a distributed environment for Windows 10 deployment
**Applies to**
- Windows 10
In this topic, you will learn how to replicate your Windows 10 deployment shares to facilitate the deployment of Windows 10 in remote or branch locations. If you work in a distributed environment, replicating the deployment shares is an important part of the deployment solution. With images reaching 5 GB in size or more, you can't deploy machines in a remote office over the wire. You need to replicate the content, so that the clients can do local deployments.
We will use four machines for this topic: DC01, MDT01, MDT02, and PC0006. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 standard server, and PC0006 is a blank machine to which you will deploy Windows 10. You will configure a second deployment server (MDT02) for a remote site (Stockholm) by replicating the deployment share in the original site (New York). MDT01, MDT02, and PC0006 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
![figure 1](../images/mdt-10-fig01.png)
Figure 1. The machines used in this topic.
## <a href="" id="sec01"></a>Replicate deployment shares
Replicating the content between MDT01 (New York) and MDT02 (Stockholm) can be done in a number of different ways. The most common content replication solutions with Microsoft Deployment Toolkit (MDT) use either the Linked Deployment Shares (LDS) feature or Distributed File System Replication (DFS-R). Some organizations have used a simple robocopy script for replication of the content.
**Note**  
Robocopy has options that allow for synchronization between folders. It has a simple reporting function; it supports transmission retry; and, by default, it will only copy/remove files from the source that are newer than files on the target.
### Linked deployment shares in MDT
LDS is a built-in feature in MDT for replicating content. However, LDS works best with strong connections such as LAN connections with low latency. For most WAN links, DFS-R is the better option.
### Why DFS-R is a better option
DFS-R is not only very fast and reliable, but it also offers central monitoring, bandwidth control, and a great delta replication engine. DFS-R will work equally well whether you have 2 sites or 90. When using DFS-R for MDT, we recommend running your deployment servers on Windows Server 2008 R2 or higher. From that version on, you can configure the replication target(s) as read-only, which is exactly what you want for MDT. This way, you can have your master deployment share centralized and replicate out changes as they happen. DFS-R will quickly pick up changes at the central deployment share in MDT01 and replicate the delta changes to MDT02.
## <a href="" id="sec02"></a>Set up Distributed File System Replication (DFS-R) for replication
Setting up DFS-R for replication is a quick and straightforward process. You prepare the deployment servers and then create a replication group. To complete the setup, you configure some replication settings.
### Prepare MDT01 for replication
1. On MDT01, using Server Manager, click **Add roles and features**.
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
3. On the **Select destination server** page, select **MDT01.contoso.com** and click **Next**.
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
![figure 2](../images/mdt-10-fig02.png)
Figure 2. Adding the DFS Replication role to MDT01.
6. On the **Select features** page, accept the default settings, and click **Next**.
7. On the **Confirm installation selections** page, click **Install**.
8. On the **Installation progress** page, click **Close**.
### Prepare MDT02 for replication
1. On MDT02, using Server Manager, click **Add roles and features**.
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
3. On the **Select destination server** page, select **MDT02.contoso.com** and click **Next**.
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
6. On the **Select features** page, accept the default settings, and click **Next**.
7. On the **Confirm installation selections** page, click **Install**.
8. On the **Installation progress** page, click **Close**.
### Create the MDTProduction folder on MDT02
1. On MDT02, using File Explorer, create the **E:\\MDTProduction** folder.
2. Share the **E:\\MDTProduction** folder as **MDTProduction$**. Use the default permissions.
![figure 3](../images/mdt-10-fig03.png)
Figure 3. Sharing the **E:\\MDTProduction folder** on MDT02.
### Configure the deployment share
When you have multiple deployment servers sharing the same content, you need to configure the Bootstrap.ini file with information about which server to connect to based on where the client is located. In MDT, that can be done by using the DefaultGateway property.
1. On MDT01, using Notepad, navigate to the **E:\\MDTProduction\\Control** folder and modify the Boostrap.ini file to look like this:
``` syntax
[Settings]
Priority=DefaultGateway, Default
[DefaultGateway]
192.168.1.1=NewYork
192.168.2.1=Stockholm
[NewYork]
DeployRoot=\\MDT01\MDTProduction$
[Stockholm]
DeployRoot=\\MDT02\MDTProduction$
[Default]
UserDomain=CONTOSO
UserID=MDT_BA
SkipBDDWelcome=YES
```
**Note**
The DeployRoot value needs to go into the Bootstrap.ini file, but you can use the same logic in the CustomSettings.ini file. For example, you can redirect the logs to the local deployment server (SLSHARE), or have the User State Migration Tool (USMT) migration store (UDDIR) local. To learn more about USMT, see [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md) and [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md).
2. Save the Bootstrap.ini file.
3. Using the Deployment Workbench, right-click the **MDT Production** deployment share and select **Update Deployment Share**.
![figure 4](../images/mdt-10-fig04.png)
Figure 4. Updating the MDT Production deployment share.
4. Use the default settings for the Update Deployment Share Wizard.
5. After the update is complete, use the Windows Deployment Services console. In the **Boot Images** node, right-click the **MDT Production x64** boot image and select **Replace Image**.
![figure 5](../images/mdt-10-fig05.png)
Figure 5. Replacing the updated boot image in WDS.
6. Browse and select the **E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim** boot image, and then complete Replace Boot Image Wizard using the default settings.
## <a href="" id="sec03"></a>Replicate the content
Once the MDT01 and MDT02 servers are prepared, you are ready to configure the actual replication.
### Create the replication group
7. On MDT01, using DFS Management, right-click **Replication**, and select **New Replication Group**.
8. On the **Replication Group Type** page, select **Multipurpose replication group**, and click **Next**.
9. On the **Name and Domain** page, assign the **MDTProduction** name, and click **Next**.
10. On the **Replication Group Members** page, click **Add**, add **MDT01** and **MDT02**, and then click **Next**.
![figure 6](../images/mdt-10-fig06.png)
Figure 6. Adding the Replication Group Members.
11. On the **Topology Selection** page, select the **Full mesh** option and click **Next**.
12. On the **Replication Group Schedule and Bandwidth** page, accept the default settings and click **Next**.
13. On the **Primary Member** page, select **MDT01** and click **Next**.
14. On the **Folders to Replicate** page, click **Add**, type in **E:\\MDTProduction** as the folder to replicate, click **OK**, and then click **Next**.
15. On the **Local Path of MDTProduction** on the **Other Members** page, select **MDT02**, and click **Edit**.
16. On the **Edit** page, select the **Enabled** option, type in **E:\\MDTProduction** as the local path of folder, select the **Make the selected replicated folder on this member read-only** check box, click **OK**, and then click **Next**.
![figure 7](../images/mdt-10-fig07.png)
Figure 7. Configure the MDT02 member.
17. On the **Review Settings and Create Replication Group** page, click **Create**.
18. On the **Confirmation** page, click **Close**.
### Configure replicated folders
19. On MDT01, using DFS Management, expand **Replication** and then select **MDTProduction**.
20. In the middle pane, right-click the **MDT01** member and select **Properties**.
21. On the **MDT01 (MDTProduction) Properties** page, configure the following and then click **OK**:
1. In the **Staging** tab, set the quota to **20480 MB**.
2. In the **Advanced** tab, set the quota to **8192 MB**.
In this scenario the size of the deployment share is known, but you might need to change the values for your environment. A good rule of thumb is to get the size of the 16 largest files and make sure they fit in the staging area. Here is a Windows PowerShell example that calculates the size of the 16 largest files in the E:\\MDTProduction deployment share:
``` syntax
(Get-ChildItem E:\MDTProduction -Recurse | Sort-Object Length -Descending | Select-Object -First 16 | Measure-Object -Property Length -Sum).Sum /1GB
```
![figure 8](../images/mdt-10-fig08.png)
Figure 8. Configure the Staging settings.
22. In the middle pane, right-click the **MDT02** member and select **Properties**.
23. On the **MDT02 (MDTProduction) Properties** page, configure the following and then click **OK**:
1. In the **Staging** tab, set the quota to **20480 MB**.
2. In the **Advanced** tab, set the quota to **8192 MB**.
**Note**  
It will take some time for the replication configuration to be picked up by the replication members (MDT01 and MDT02). The time for the initial sync will depend on the WAN link speed between the sites. After that, delta changes are replicated quickly.
### Verify replication
1. On MDT02, wait until you start to see content appear in the **E:\\MDTProduction** folder.
2. Using DFS Management, expand **Replication**, right-click **MDTProduction**, and select **Create Diagnostics Report**.
3. In the Diagnostics Report Wizard, on the **Type of Diagnostics Report or Test** page, select **Health report** and click **Next**.
4. On the **Path and Name** page, accept the default settings and click **Next**.
5. On the **Members to Include** page, accept the default settings and click **Next**.
6. On the **Options** page, accept the default settings and click **Next**.
7. On the **Review Settings and Create Report** page, click **Create**.
8. Open the report in Internet Explorer, and if necessary, select the **Allow blocked content** option.
![figure 9](../images/mdt-10-fig09.png)
Figure 9. The DFS Replication Health Report.
## <a href="" id="sec04"></a>Configure Windows Deployment Services (WDS) in a remote site
Like you did in the previous topic for MDT01, you need to add the MDT Production Lite Touch x64 Boot image to Windows Deployment Services on MDT02. For the following steps, we assume that WDS has already been installed on MDT02.
1. On MDT02, using the WDS console, right-click **Boot Images** and select **Add Boot Image**.
2. Browse to the E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim file and add the image with the default settings.
## <a href="" id="sec05"></a>Deploy the Windows 10 client to the remote site
Now you should have a solution ready for deploying the Windows 10 client to the remote site, Stockholm, connecting to the MDT Production deployment share replica on MDT02.
1. Create a virtual machine with the following settings:
1. Name: PC0006
2. Location: C:\\VMs
3. Generation: 2
4. Memory: 2048 MB
5. Hard disk: 60 GB (dynamic disk)
2. Start the PC0006 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
1. Password: P@ssw0rd
2. Select a task sequence to execute on this computer:
1. Windows 10 Enterprise x64 RTM Custom Image
2. Computer Name: PC0006
3. Applications: Select the Install - Adobe Reader XI - x86 application
4. The setup will now start and do the following:
1. Install the Windows 10 Enterprise operating system.
2. Install the added application.
3. Update the operating system via your local Windows Server Update Services (WSUS) server.
## Related topics
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT](deploy-a-windows-10-image-using-mdt.md)
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-settings.md)
---
title: Build a distributed environment for Windows 10 deployment (Windows 10)
description: In this topic, you will learn how to replicate your Windows 10 deployment shares to facilitate the deployment of Windows 10 in remote or branch locations.
ms.assetid: a6cd5657-6a16-4fff-bfb4-44760902d00c
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: replication, replicate, deploy, configure, remote
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Build a distributed environment for Windows 10 deployment
**Applies to**
- Windows 10
In this topic, you will learn how to replicate your Windows 10 deployment shares to facilitate the deployment of Windows 10 in remote or branch locations. If you work in a distributed environment, replicating the deployment shares is an important part of the deployment solution. With images reaching 5 GB in size or more, you can't deploy machines in a remote office over the wire. You need to replicate the content, so that the clients can do local deployments.
We will use four machines for this topic: DC01, MDT01, MDT02, and PC0006. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 standard server, and PC0006 is a blank machine to which you will deploy Windows 10. You will configure a second deployment server (MDT02) for a remote site (Stockholm) by replicating the deployment share in the original site (New York). MDT01, MDT02, and PC0006 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
![figure 1](../images/mdt-10-fig01.png)
Figure 1. The machines used in this topic.
## <a href="" id="sec01"></a>Replicate deployment shares
Replicating the content between MDT01 (New York) and MDT02 (Stockholm) can be done in a number of different ways. The most common content replication solutions with Microsoft Deployment Toolkit (MDT) use either the Linked Deployment Shares (LDS) feature or Distributed File System Replication (DFS-R). Some organizations have used a simple robocopy script for replication of the content.
**Note**  
Robocopy has options that allow for synchronization between folders. It has a simple reporting function; it supports transmission retry; and, by default, it will only copy/remove files from the source that are newer than files on the target.
### Linked deployment shares in MDT
LDS is a built-in feature in MDT for replicating content. However, LDS works best with strong connections such as LAN connections with low latency. For most WAN links, DFS-R is the better option.
### Why DFS-R is a better option
DFS-R is not only very fast and reliable, but it also offers central monitoring, bandwidth control, and a great delta replication engine. DFS-R will work equally well whether you have 2 sites or 90. When using DFS-R for MDT, we recommend running your deployment servers on Windows Server 2008 R2 or higher. From that version on, you can configure the replication target(s) as read-only, which is exactly what you want for MDT. This way, you can have your master deployment share centralized and replicate out changes as they happen. DFS-R will quickly pick up changes at the central deployment share in MDT01 and replicate the delta changes to MDT02.
## <a href="" id="sec02"></a>Set up Distributed File System Replication (DFS-R) for replication
Setting up DFS-R for replication is a quick and straightforward process. You prepare the deployment servers and then create a replication group. To complete the setup, you configure some replication settings.
### Prepare MDT01 for replication
1. On MDT01, using Server Manager, click **Add roles and features**.
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
3. On the **Select destination server** page, select **MDT01.contoso.com** and click **Next**.
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
![figure 2](../images/mdt-10-fig02.png)
Figure 2. Adding the DFS Replication role to MDT01.
6. On the **Select features** page, accept the default settings, and click **Next**.
7. On the **Confirm installation selections** page, click **Install**.
8. On the **Installation progress** page, click **Close**.
### Prepare MDT02 for replication
1. On MDT02, using Server Manager, click **Add roles and features**.
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
3. On the **Select destination server** page, select **MDT02.contoso.com** and click **Next**.
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
6. On the **Select features** page, accept the default settings, and click **Next**.
7. On the **Confirm installation selections** page, click **Install**.
8. On the **Installation progress** page, click **Close**.
### Create the MDTProduction folder on MDT02
1. On MDT02, using File Explorer, create the **E:\\MDTProduction** folder.
2. Share the **E:\\MDTProduction** folder as **MDTProduction$**. Use the default permissions.
![figure 3](../images/mdt-10-fig03.png)
Figure 3. Sharing the **E:\\MDTProduction folder** on MDT02.
### Configure the deployment share
When you have multiple deployment servers sharing the same content, you need to configure the Bootstrap.ini file with information about which server to connect to based on where the client is located. In MDT, that can be done by using the DefaultGateway property.
1. On MDT01, using Notepad, navigate to the **E:\\MDTProduction\\Control** folder and modify the Boostrap.ini file to look like this:
```
[Settings]
Priority=DefaultGateway, Default
[DefaultGateway]
192.168.1.1=NewYork
192.168.2.1=Stockholm
[NewYork]
DeployRoot=\\MDT01\MDTProduction$
[Stockholm]
DeployRoot=\\MDT02\MDTProduction$
[Default]
UserDomain=CONTOSO
UserID=MDT_BA
SkipBDDWelcome=YES
```
**Note**
The DeployRoot value needs to go into the Bootstrap.ini file, but you can use the same logic in the CustomSettings.ini file. For example, you can redirect the logs to the local deployment server (SLSHARE), or have the User State Migration Tool (USMT) migration store (UDDIR) local. To learn more about USMT, see [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md) and [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md).
2. Save the Bootstrap.ini file.
3. Using the Deployment Workbench, right-click the **MDT Production** deployment share and select **Update Deployment Share**.
![figure 4](../images/mdt-10-fig04.png)
Figure 4. Updating the MDT Production deployment share.
4. Use the default settings for the Update Deployment Share Wizard.
5. After the update is complete, use the Windows Deployment Services console. In the **Boot Images** node, right-click the **MDT Production x64** boot image and select **Replace Image**.
![figure 5](../images/mdt-10-fig05.png)
Figure 5. Replacing the updated boot image in WDS.
6. Browse and select the **E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim** boot image, and then complete Replace Boot Image Wizard using the default settings.
## <a href="" id="sec03"></a>Replicate the content
Once the MDT01 and MDT02 servers are prepared, you are ready to configure the actual replication.
### Create the replication group
7. On MDT01, using DFS Management, right-click **Replication**, and select **New Replication Group**.
8. On the **Replication Group Type** page, select **Multipurpose replication group**, and click **Next**.
9. On the **Name and Domain** page, assign the **MDTProduction** name, and click **Next**.
10. On the **Replication Group Members** page, click **Add**, add **MDT01** and **MDT02**, and then click **Next**.
![figure 6](../images/mdt-10-fig06.png)
Figure 6. Adding the Replication Group Members.
11. On the **Topology Selection** page, select the **Full mesh** option and click **Next**.
12. On the **Replication Group Schedule and Bandwidth** page, accept the default settings and click **Next**.
13. On the **Primary Member** page, select **MDT01** and click **Next**.
14. On the **Folders to Replicate** page, click **Add**, type in **E:\\MDTProduction** as the folder to replicate, click **OK**, and then click **Next**.
15. On the **Local Path of MDTProduction** on the **Other Members** page, select **MDT02**, and click **Edit**.
16. On the **Edit** page, select the **Enabled** option, type in **E:\\MDTProduction** as the local path of folder, select the **Make the selected replicated folder on this member read-only** check box, click **OK**, and then click **Next**.
![figure 7](../images/mdt-10-fig07.png)
Figure 7. Configure the MDT02 member.
17. On the **Review Settings and Create Replication Group** page, click **Create**.
18. On the **Confirmation** page, click **Close**.
### Configure replicated folders
19. On MDT01, using DFS Management, expand **Replication** and then select **MDTProduction**.
20. In the middle pane, right-click the **MDT01** member and select **Properties**.
21. On the **MDT01 (MDTProduction) Properties** page, configure the following and then click **OK**:
1. In the **Staging** tab, set the quota to **20480 MB**.
2. In the **Advanced** tab, set the quota to **8192 MB**.
In this scenario the size of the deployment share is known, but you might need to change the values for your environment. A good rule of thumb is to get the size of the 16 largest files and make sure they fit in the staging area. Here is a Windows PowerShell example that calculates the size of the 16 largest files in the E:\\MDTProduction deployment share:
``` powershell
(Get-ChildItem E:\MDTProduction -Recurse | Sort-Object Length -Descending | Select-Object -First 16 | Measure-Object -Property Length -Sum).Sum /1GB
```
![figure 8](../images/mdt-10-fig08.png)
Figure 8. Configure the Staging settings.
22. In the middle pane, right-click the **MDT02** member and select **Properties**.
23. On the **MDT02 (MDTProduction) Properties** page, configure the following and then click **OK**:
1. In the **Staging** tab, set the quota to **20480 MB**.
2. In the **Advanced** tab, set the quota to **8192 MB**.
**Note**  
It will take some time for the replication configuration to be picked up by the replication members (MDT01 and MDT02). The time for the initial sync will depend on the WAN link speed between the sites. After that, delta changes are replicated quickly.
### Verify replication
1. On MDT02, wait until you start to see content appear in the **E:\\MDTProduction** folder.
2. Using DFS Management, expand **Replication**, right-click **MDTProduction**, and select **Create Diagnostics Report**.
3. In the Diagnostics Report Wizard, on the **Type of Diagnostics Report or Test** page, select **Health report** and click **Next**.
4. On the **Path and Name** page, accept the default settings and click **Next**.
5. On the **Members to Include** page, accept the default settings and click **Next**.
6. On the **Options** page, accept the default settings and click **Next**.
7. On the **Review Settings and Create Report** page, click **Create**.
8. Open the report in Internet Explorer, and if necessary, select the **Allow blocked content** option.
![figure 9](../images/mdt-10-fig09.png)
Figure 9. The DFS Replication Health Report.
## <a href="" id="sec04"></a>Configure Windows Deployment Services (WDS) in a remote site
Like you did in the previous topic for MDT01, you need to add the MDT Production Lite Touch x64 Boot image to Windows Deployment Services on MDT02. For the following steps, we assume that WDS has already been installed on MDT02.
1. On MDT02, using the WDS console, right-click **Boot Images** and select **Add Boot Image**.
2. Browse to the E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim file and add the image with the default settings.
## <a href="" id="sec05"></a>Deploy the Windows 10 client to the remote site
Now you should have a solution ready for deploying the Windows 10 client to the remote site, Stockholm, connecting to the MDT Production deployment share replica on MDT02.
1. Create a virtual machine with the following settings:
1. Name: PC0006
2. Location: C:\\VMs
3. Generation: 2
4. Memory: 2048 MB
5. Hard disk: 60 GB (dynamic disk)
2. Start the PC0006 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
1. Password: P@ssw0rd
2. Select a task sequence to execute on this computer:
1. Windows 10 Enterprise x64 RTM Custom Image
2. Computer Name: PC0006
3. Applications: Select the Install - Adobe Reader XI - x86 application
4. The setup will now start and do the following:
1. Install the Windows 10 Enterprise operating system.
2. Install the added application.
3. Update the operating system via your local Windows Server Update Services (WSUS) server.
## Related topics
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT](deploy-a-windows-10-image-using-mdt.md)
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
[Configure MDT settings](configure-mdt-settings.md)

251
windows/deployment/deploy-windows-mdt/configure-mdt-deployment-share-rules.md
View File

@ -1,125 +1,126 @@
---
title: Configure MDT deployment share rules (Windows 10)
description: In this topic, you will learn how to configure the MDT rules engine to reach out to other resources, including external scripts, databases, and web services, for additional information instead of storing settings directly in the rules engine.
ms.assetid: b5ce2360-33cc-4b14-b291-16f75797391b
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: rules, configuration, automate, deploy
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Configure MDT deployment share rules
In this topic, you will learn how to configure the MDT rules engine to reach out to other resources, including external scripts, databases, and web services, for additional information instead of storing settings directly in the rules engine. The rules engine in MDT is powerful: most of the settings used for operating system deployments are retrieved and assigned via the rules engine. In its simplest form, the rules engine is the CustomSettings.ini text file.
## <a href="" id="sec01"></a>Assign settings
When using MDT, you can assign setting in three distinct ways:
- You can pre-stage the information before deployment.
- You can prompt the user or technician for information.
- You can have MDT generate the settings automatically.
In order illustrate these three options, let's look at some sample configurations.
## <a href="" id="sec02"></a>Sample configurations
Before adding the more advanced components like scripts, databases, and web services, consider the commonly used configurations below; they demonstrate the power of the rules engine.
### Set computer name by MAC Address
If you have a small test environment, or simply want to assign settings to a very limited number of machines, you can edit the rules to assign settings directly for a given MAC Address. If you have many machines, it makes sense to use the database instead.
``` syntax
[Settings]
Priority=MacAddress, Default
[Default]
OSInstall=YES
[00:15:5D:85:6B:00]
OSDComputerName=PC00075
```
In the preceding sample, you set the PC00075 computer name for a machine with a MAC Address of 00:15:5D:85:6B:00.
### Set computer name by serial number
Another way to assign a computer name is to identify the machine via its serial number.
``` syntax
[Settings]
Priority=SerialNumber, Default
[Default]
OSInstall=YES
[CND0370RJ7]
OSDComputerName=PC00075
```
In this sample, you set the PC00075 computer name for a machine with a serial number of CND0370RJ7.
### Generate a computer name based on a serial number
You also can configure the rules engine to use a known property, like a serial number, to generate a computer name on the fly.
``` syntax
[Settings]
Priority=Default
[Default]
OSInstall=YES
OSDComputerName=PC-%SerialNumber%
```
In this sample, you configure the rules to set the computer name to a prefix (PC-) and then the serial number. If the serial number of the machine is CND0370RJ7, the preceding configuration sets the computer name to PC-CND0370RJ7.
**Note**  
Be careful when using the serial number to assign computer names. A serial number can contain more than 15 characters, but the Windows setup limits a computer name to 15 characters.
 
### Generate a limited computer name based on a serial number
To avoid assigning a computer name longer than 15 characters, you can configure the rules in more detail by adding VBScript functions, as follows:
``` syntax
[Settings]
Priority=Default
[Default]
OSInstall=YES
OSDComputerName=PC-#Left("%SerialNumber%",12)#
```
In the preceding sample, you still configure the rules to set the computer name to a prefix (PC-) followed by the serial number. However, by adding the Left VBScript function, you configure the rule to use only the first 12 serial-number characters for the name.
### Add laptops to a different organizational unit (OU) in Active Directory
In the rules, you find built-in properties that use a Windows Management Instrumentation (WMI) query to determine whether the machine you are deploying is a laptop, desktop, or server. In this sample, we assume you want to add laptops to different OUs in Active Directory. Note that ByLaptopType is not a reserved word; rather, it is the name of the section to read.
``` syntax
[Settings]
Priority=ByLaptopType, Default
[Default]
MachineObjectOU=OU=Workstations,OU=Contoso,DC=contoso,DC=com
[ByLaptopType]
Subsection=Laptop-%IsLaptop%
[Laptop-True]
MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com
```
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
---
title: Configure MDT deployment share rules (Windows 10)
description: In this topic, you will learn how to configure the MDT rules engine to reach out to other resources, including external scripts, databases, and web services, for additional information instead of storing settings directly in the rules engine.
ms.assetid: b5ce2360-33cc-4b14-b291-16f75797391b
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: rules, configuration, automate, deploy
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Configure MDT deployment share rules
In this topic, you will learn how to configure the MDT rules engine to reach out to other resources, including external scripts, databases, and web services, for additional information instead of storing settings directly in the rules engine. The rules engine in MDT is powerful: most of the settings used for operating system deployments are retrieved and assigned via the rules engine. In its simplest form, the rules engine is the CustomSettings.ini text file.
## <a href="" id="sec01"></a>Assign settings
When using MDT, you can assign setting in three distinct ways:
- You can pre-stage the information before deployment.
- You can prompt the user or technician for information.
- You can have MDT generate the settings automatically.
In order illustrate these three options, let's look at some sample configurations.
## <a href="" id="sec02"></a>Sample configurations
Before adding the more advanced components like scripts, databases, and web services, consider the commonly used configurations below; they demonstrate the power of the rules engine.
### Set computer name by MAC Address
If you have a small test environment, or simply want to assign settings to a very limited number of machines, you can edit the rules to assign settings directly for a given MAC Address. If you have many machines, it makes sense to use the database instead.
```
[Settings]
Priority=MacAddress, Default
[Default]
OSInstall=YES
[00:15:5D:85:6B:00]
OSDComputerName=PC00075
```
In the preceding sample, you set the PC00075 computer name for a machine with a MAC Address of 00:15:5D:85:6B:00.
### Set computer name by serial number
Another way to assign a computer name is to identify the machine via its serial number.
```
[Settings]
Priority=SerialNumber, Default
[Default]
OSInstall=YES
[CND0370RJ7]
OSDComputerName=PC00075
```
In this sample, you set the PC00075 computer name for a machine with a serial number of CND0370RJ7.
### Generate a computer name based on a serial number
You also can configure the rules engine to use a known property, like a serial number, to generate a computer name on the fly.
```
[Settings]
Priority=Default
[Default]
OSInstall=YES
OSDComputerName=PC-%SerialNumber%
```
In this sample, you configure the rules to set the computer name to a prefix (PC-) and then the serial number. If the serial number of the machine is CND0370RJ7, the preceding configuration sets the computer name to PC-CND0370RJ7.
**Note**  
Be careful when using the serial number to assign computer names. A serial number can contain more than 15 characters, but the Windows setup limits a computer name to 15 characters.
 
### Generate a limited computer name based on a serial number
To avoid assigning a computer name longer than 15 characters, you can configure the rules in more detail by adding VBScript functions, as follows:
```
[Settings]
Priority=Default
[Default]
OSInstall=YES
OSDComputerName=PC-#Left("%SerialNumber%",12)#
```
In the preceding sample, you still configure the rules to set the computer name to a prefix (PC-) followed by the serial number. However, by adding the Left VBScript function, you configure the rule to use only the first 12 serial-number characters for the name.
### Add laptops to a different organizational unit (OU) in Active Directory
In the rules, you find built-in properties that use a Windows Management Instrumentation (WMI) query to determine whether the machine you are deploying is a laptop, desktop, or server. In this sample, we assume you want to add laptops to different OUs in Active Directory. Note that ByLaptopType is not a reserved word; rather, it is the name of the section to read.
```
[Settings]
Priority=ByLaptopType, Default
[Default]
MachineObjectOU=OU=Workstations,OU=Contoso,DC=contoso,DC=com
[ByLaptopType]
Subsection=Laptop-%IsLaptop%
[Laptop-True]
MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com
```
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)

147
windows/deployment/deploy-windows-mdt/configure-mdt-for-userexit-scripts.md
View File

@ -1,73 +1,74 @@
---
title: Configure MDT for UserExit scripts (Windows 10)
description: In this topic, you will learn how to configure the MDT rules engine to use a UserExit script to generate computer names based on a prefix and the computer MAC Address.
ms.assetid: 29a421d1-12d2-414e-86dc-25b62f5238a7
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: rules, script
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Configure MDT for UserExit scripts
In this topic, you will learn how to configure the MDT rules engine to use a UserExit script to generate computer names based on a prefix and the computer MAC Address. MDT supports calling external VBScripts as part of the Gather process; these scripts are referred to as UserExit scripts. The script also removes the colons in the MAC Address.
## Configure the rules to call a UserExit script
You can call a UserExit by referencing the script in your rules. Then you can configure a property to be set to the result of a function of the VBScript. In this example, we have a VBScript named Setname.vbs (provided in the book sample files, in the UserExit folder).
``` syntax
[Settings]
Priority=Default
[Default]
OSINSTALL=YES
UserExit=Setname.vbs
OSDComputerName=#SetName("%MACADDRESS%")#
```
The UserExit=Setname.vbs calls the script and then assigns the computer name to what the SetName function in the script returns. In this sample the %MACADDRESS% variable is passed to the script
## The Setname.vbs UserExit script
The Setname.vbs script takes the MAC Address passed from the rules. The script then does some string manipulation to add a prefix (PC) and remove the semicolons from the MAC Address.
``` syntax
Function UserExit(sType, sWhen, sDetail, bSkip)
UserExit = Success
End Function
Function SetName(sMac)
Dim re
Set re = new RegExp
re.IgnoreCase = true
re.Global = true
re.Pattern = ":"
SetName = "PC" & re.Replace(sMac, "")
End Function
```
The first three lines of the script make up a header that all UserExit scripts have. The interesting part is the lines between Function and End Function. Those lines add a prefix (PC), remove the colons from the MAC Address, and return the value to the rules by setting the SetName value.
**Note**  
The purpose of this sample is not to recommend that you use the MAC Address as a base for computer naming, but to show you how to take a variable from MDT, pass it to an external script, make some changes to it, and then return the new value to the deployment process.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
---
title: Configure MDT for UserExit scripts (Windows 10)
description: In this topic, you will learn how to configure the MDT rules engine to use a UserExit script to generate computer names based on a prefix and the computer MAC Address.
ms.assetid: 29a421d1-12d2-414e-86dc-25b62f5238a7
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: rules, script
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Configure MDT for UserExit scripts
In this topic, you will learn how to configure the MDT rules engine to use a UserExit script to generate computer names based on a prefix and the computer MAC Address. MDT supports calling external VBScripts as part of the Gather process; these scripts are referred to as UserExit scripts. The script also removes the colons in the MAC Address.
## Configure the rules to call a UserExit script
You can call a UserExit by referencing the script in your rules. Then you can configure a property to be set to the result of a function of the VBScript. In this example, we have a VBScript named Setname.vbs (provided in the book sample files, in the UserExit folder).
```
[Settings]
Priority=Default
[Default]
OSINSTALL=YES
UserExit=Setname.vbs
OSDComputerName=#SetName("%MACADDRESS%")#
```
The UserExit=Setname.vbs calls the script and then assigns the computer name to what the SetName function in the script returns. In this sample the %MACADDRESS% variable is passed to the script
## The Setname.vbs UserExit script
The Setname.vbs script takes the MAC Address passed from the rules. The script then does some string manipulation to add a prefix (PC) and remove the semicolons from the MAC Address.
```
Function UserExit(sType, sWhen, sDetail, bSkip)
UserExit = Success
End Function
Function SetName(sMac)
Dim re
Set re = new RegExp
re.IgnoreCase = true
re.Global = true
re.Pattern = ":"
SetName = "PC" & re.Replace(sMac, "")
End Function
```
The first three lines of the script make up a header that all UserExit scripts have. The interesting part is the lines between Function and End Function. Those lines add a prefix (PC), remove the colons from the MAC Address, and return the value to the rules by setting the SetName value.
**Note**  
The purpose of this sample is not to recommend that you use the MAC Address as a base for computer naming, but to show you how to take a variable from MDT, pass it to an external script, make some changes to it, and then return the new value to the deployment process.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)

1303
windows/deployment/deploy-windows-mdt/create-a-windows-10-reference-image.md
View File

File diff suppressed because it is too large Load Diff

1329
windows/deployment/deploy-windows-mdt/deploy-a-windows-10-image-using-mdt.md
View File

File diff suppressed because it is too large Load Diff

244
windows/deployment/deploy-windows-mdt/integrate-configuration-manager-with-mdt.md
View File

@ -1,120 +1,124 @@
---
title: Integrate Configuration Manager with MDT (Windows 10)
description: This topic will help you understand the benefits of integrating the Microsoft Deployment Toolkit with Microsoft System Center 2012 R2 Configuration Manager SP1 when you deploy a new or updated version of the Windows operating system.
ms.assetid: 3bd1cf92-81e5-48dc-b874-0f5d9472e5a5
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.pagetype: mdt
keywords: deploy, image, customize, task sequence
ms.prod: w10
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.topic: article
---
# Integrate Configuration Manager with MDT
**Applies to**
- Windows 10
This topic will help you understand the benefits of integrating the Microsoft Deployment Toolkit with Microsoft System Center 2012 R2 Configuration Manager SP1 when you deploy a new or updated version of the Windows operating system.
MDT is a free, supported download from Microsoft that adds approximately 280 enhancements to Windows operating system deployment with System Center 2012 R2 Configuration Manager SP1. It is, therefore, recommended that you utilize MDT when deploying the Windows operating system with Configuration Manager SP1. In addition to integrating MDT with Configuration Manager, we also recommend using MDT Lite Touch to create the Windows 10 reference images used in Configuration Manager. For more information on how to create a reference image, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
## <a href="" id="sec01"></a>Why integrate MDT with Configuration Manager
As noted above, MDT adds many enhancements to Configuration Manager. While these enhancements are called Zero Touch, that name does not reflect how deployment is conducted. The following sections provide a few samples of the 280 enhancements that MDT adds to Configuration Manager.
### MDT enables dynamic deployment
When MDT is integrated with Configuration Manager, the task sequence takes additional instructions from the MDT rules. In its most simple form, these settings are stored in a text file, the CustomSettings.ini file, but you can store the settings in Microsoft SQL Server databases, or have Microsoft Visual Basic Scripting Edition (VBScripts) or web services provide the settings used.
The task sequence uses instructions that allow you to reduce the number of task sequences in Configuration Manager and instead store settings outside the task sequence. Here are a few examples:
- The following settings instruct the task sequence to install the HP Hotkeys package, but only if the hardware is a HP EliteBook 8570w. Note that you don't have to add the package to the task sequence.
``` syntax
[Settings]
Priority=Model
[HP EliteBook 8570w]
Packages001=PS100010:Install HP Hotkeys
```
- The following settings instruct the task sequence to put laptops and desktops in different organizational units (OUs) during deployment, assign different computer names, and finally have the task sequence install the Cisco VPN client, but only if the machine is a laptop.
``` syntax
[Settings]
Priority= ByLaptopType, ByDesktopType
[ByLaptopType]
Subsection=Laptop-%IsLaptop%
[ByDesktopType]
Subsection=Desktop-%IsDesktop%
[Laptop-True]
Packages001=PS100012:Install Cisco VPN Client
OSDComputerName=LT-%SerialNumber%
MachineObjectOU=ou=laptops,ou=Contoso,dc=contoso,dc=com
[Desktop-True]
OSDComputerName=DT-%SerialNumber%
MachineObjectOU=ou=desktops,ou=Contoso,dc=contoso,dc=com
```
![figure 2](../images/fig2-gather.png)
Figure 2. The Gather action in the task sequence is reading the rules.
### MDT adds an operating system deployment simulation environment
When testing a deployment, it is important to be able to quickly test any changes you make to the deployment without needing to run through an entire deployment. MDT rules can be tested very quickly, saving significant testing time in a deployment project. For more information, see [Configure MDT settings](configure-mdt-settings.md).
![figure 3](../images/mdt-06-fig03.png)
Figure 3. The folder that contains the rules, a few scripts from MDT, and a custom script (Gather.ps1).
### MDT adds real-time monitoring
With MDT integration, you can follow your deployments in real time, and if you have access to Microsoft Diagnostics and Recovery Toolkit (DaRT), you can even remote into Windows Preinstallation Environment (Windows PE) during deployment. The real-time monitoring data can be viewed from within the MDT Deployment Workbench, via a web browser, Windows PowerShell, the Event Viewer, or Microsoft Excel 2013. In fact, any script or app that can read an Open Data (OData) feed can read the information.
![figure 4](../images/mdt-06-fig04.png)
Figure 4. View the real-time monitoring data with PowerShell.
### MDT adds an optional deployment wizard
For some deployment scenarios, you may need to prompt the user for information during deployment such as the computer name, the correct organizational unit (OU) for the computer, or which applications should be installed by the task sequence. With MDT integration, you can enable the User-Driven Installation (UDI) wizard to gather the required information, and customize the wizard using the UDI Wizard Designer.
![figure 5](../images/mdt-06-fig05.png)
Figure 5. The optional UDI wizard open in the UDI Wizard Designer.
MDT Zero Touch simply extends Configuration Manager with many useful built-in operating system deployment components. By providing well-established, supported solutions, MDT reduces the complexity of deployment in Configuration Manager.
## <a href="" id="sec02"></a>Why use MDT Lite Touch to create reference images
You can create reference images for Configuration Manager in Configuration Manager, but in general we recommend creating them in MDT Lite Touch for the following reasons:
- In a deployment project, it is typically much faster to create a reference image using MDT Lite Touch than Configuration Manager.
- You can use the same image for every type of operating system deployment - Microsoft Virtual Desktop Infrastructure (VDI), Microsoft System Center 2012 R2 Virtual Machine Manager (SCVMM), MDT, Configuration Manager, Windows Deployment Services (WDS), and more.
- Microsoft System Center 2012 R2 performs deployment in the LocalSystem context. This means that you cannot configure the Administrator account with all of the settings that you would like to be included in the image. MDT runs in the context of the Local Administrator, which means you can configure the look and feel of the configuration and then use the CopyProfile functionality to copy these changes to the default user during deployment.
- The Configuration Manager task sequence does not suppress user interface interaction.
- MDT Lite Touch supports a Suspend action that allows for reboots, which is useful when you need to perform a manual installation or check the reference image before it is automatically captured.
- MDT Lite Touch does not require any infrastructure and is easy to delegate.
## Related topics
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](../deploy-windows-sccm/prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
[Create a custom Windows PE boot image with Configuration Manager](../deploy-windows-sccm/create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
[Add a Windows 10 operating system image using Configuration Manager](../deploy-windows-sccm/add-a-windows-10-operating-system-image-using-configuration-manager.md)
[Create an application to deploy with Windows 10 using Configuration Manager](../deploy-windows-sccm/create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](../deploy-windows-sccm/add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
[Create a task sequence with Configuration Manager and MDT](../deploy-windows-mdt/create-a-task-sequence-with-configuration-manager-and-mdt.md)
[Deploy Windows 10 using PXE and Configuration Manager](../deploy-windows-sccm/deploy-windows-10-using-pxe-and-configuration-manager.md)
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](../deploy-windows-sccm/refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](../deploy-windows-sccm/replace-a-windows-7-client-with-windows-10-using-configuration-manager.md) 
---
title: Integrate Configuration Manager with MDT (Windows 10)
description: This topic will help you understand the benefits of integrating the Microsoft Deployment Toolkit with Microsoft System Center 2012 R2 Configuration Manager SP1 when you deploy a new or updated version of the Windows operating system.
ms.assetid: 3bd1cf92-81e5-48dc-b874-0f5d9472e5a5
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.pagetype: mdt
keywords: deploy, image, customize, task sequence
ms.prod: w10
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Integrate Configuration Manager with MDT
**Applies to**
- Windows 10
This topic will help you understand the benefits of integrating the Microsoft Deployment Toolkit with Microsoft System Center 2012 R2 Configuration Manager SP1 when you deploy a new or updated version of the Windows operating system.
MDT is a free, supported download from Microsoft that adds approximately 280 enhancements to Windows operating system deployment with System Center 2012 R2 Configuration Manager SP1. It is, therefore, recommended that you utilize MDT when deploying the Windows operating system with Configuration Manager SP1. In addition to integrating MDT with Configuration Manager, we also recommend using MDT Lite Touch to create the Windows 10 reference images used in Configuration Manager. For more information on how to create a reference image, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
## <a href="" id="sec01"></a>Why integrate MDT with Configuration Manager
As noted above, MDT adds many enhancements to Configuration Manager. While these enhancements are called Zero Touch, that name does not reflect how deployment is conducted. The following sections provide a few samples of the 280 enhancements that MDT adds to Configuration Manager.
> [!Note]
> Microsoft Deployment Toolkit requires you to install [Windows PowerShell 2.0 Engine](https://docs.microsoft.com/powershell/scripting/install/installing-the-windows-powershell-2.0-engine) on your server.
### MDT enables dynamic deployment
When MDT is integrated with Configuration Manager, the task sequence takes additional instructions from the MDT rules. In its most simple form, these settings are stored in a text file, the CustomSettings.ini file, but you can store the settings in Microsoft SQL Server databases, or have Microsoft Visual Basic Scripting Edition (VBScripts) or web services provide the settings used.
The task sequence uses instructions that allow you to reduce the number of task sequences in Configuration Manager and instead store settings outside the task sequence. Here are a few examples:
- The following settings instruct the task sequence to install the HP Hotkeys package, but only if the hardware is a HP EliteBook 8570w. Note that you don't have to add the package to the task sequence.
``` syntax
[Settings]
Priority=Model
[HP EliteBook 8570w]
Packages001=PS100010:Install HP Hotkeys
```
- The following settings instruct the task sequence to put laptops and desktops in different organizational units (OUs) during deployment, assign different computer names, and finally have the task sequence install the Cisco VPN client, but only if the machine is a laptop.
``` syntax
[Settings]
Priority= ByLaptopType, ByDesktopType
[ByLaptopType]
Subsection=Laptop-%IsLaptop%
[ByDesktopType]
Subsection=Desktop-%IsDesktop%
[Laptop-True]
Packages001=PS100012:Install Cisco VPN Client
OSDComputerName=LT-%SerialNumber%
MachineObjectOU=ou=laptops,ou=Contoso,dc=contoso,dc=com
[Desktop-True]
OSDComputerName=DT-%SerialNumber%
MachineObjectOU=ou=desktops,ou=Contoso,dc=contoso,dc=com
```
![figure 2](../images/fig2-gather.png)
Figure 2. The Gather action in the task sequence is reading the rules.
### MDT adds an operating system deployment simulation environment
When testing a deployment, it is important to be able to quickly test any changes you make to the deployment without needing to run through an entire deployment. MDT rules can be tested very quickly, saving significant testing time in a deployment project. For more information, see [Configure MDT settings](configure-mdt-settings.md).
![figure 3](../images/mdt-06-fig03.png)
Figure 3. The folder that contains the rules, a few scripts from MDT, and a custom script (Gather.ps1).
### MDT adds real-time monitoring
With MDT integration, you can follow your deployments in real time, and if you have access to Microsoft Diagnostics and Recovery Toolkit (DaRT), you can even remote into Windows Preinstallation Environment (Windows PE) during deployment. The real-time monitoring data can be viewed from within the MDT Deployment Workbench, via a web browser, Windows PowerShell, the Event Viewer, or Microsoft Excel 2013. In fact, any script or app that can read an Open Data (OData) feed can read the information.
![figure 4](../images/mdt-06-fig04.png)
Figure 4. View the real-time monitoring data with PowerShell.
### MDT adds an optional deployment wizard
For some deployment scenarios, you may need to prompt the user for information during deployment such as the computer name, the correct organizational unit (OU) for the computer, or which applications should be installed by the task sequence. With MDT integration, you can enable the User-Driven Installation (UDI) wizard to gather the required information, and customize the wizard using the UDI Wizard Designer.
![figure 5](../images/mdt-06-fig05.png)
Figure 5. The optional UDI wizard open in the UDI Wizard Designer.
MDT Zero Touch simply extends Configuration Manager with many useful built-in operating system deployment components. By providing well-established, supported solutions, MDT reduces the complexity of deployment in Configuration Manager.
## <a href="" id="sec02"></a>Why use MDT Lite Touch to create reference images
You can create reference images for Configuration Manager in Configuration Manager, but in general we recommend creating them in MDT Lite Touch for the following reasons:
- In a deployment project, it is typically much faster to create a reference image using MDT Lite Touch than Configuration Manager.
- You can use the same image for every type of operating system deployment - Microsoft Virtual Desktop Infrastructure (VDI), Microsoft System Center 2012 R2 Virtual Machine Manager (SCVMM), MDT, Configuration Manager, Windows Deployment Services (WDS), and more.
- Microsoft System Center 2012 R2 performs deployment in the LocalSystem context. This means that you cannot configure the Administrator account with all of the settings that you would like to be included in the image. MDT runs in the context of the Local Administrator, which means you can configure the look and feel of the configuration and then use the CopyProfile functionality to copy these changes to the default user during deployment.
- The Configuration Manager task sequence does not suppress user interface interaction.
- MDT Lite Touch supports a Suspend action that allows for reboots, which is useful when you need to perform a manual installation or check the reference image before it is automatically captured.
- MDT Lite Touch does not require any infrastructure and is easy to delegate.
## Related topics
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](../deploy-windows-sccm/prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
[Create a custom Windows PE boot image with Configuration Manager](../deploy-windows-sccm/create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
[Add a Windows 10 operating system image using Configuration Manager](../deploy-windows-sccm/add-a-windows-10-operating-system-image-using-configuration-manager.md)
[Create an application to deploy with Windows 10 using Configuration Manager](../deploy-windows-sccm/create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](../deploy-windows-sccm/add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
[Create a task sequence with Configuration Manager and MDT](../deploy-windows-mdt/create-a-task-sequence-with-configuration-manager-and-mdt.md)
[Deploy Windows 10 using PXE and Configuration Manager](../deploy-windows-sccm/deploy-windows-10-using-pxe-and-configuration-manager.md)
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](../deploy-windows-sccm/refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](../deploy-windows-sccm/replace-a-windows-7-client-with-windows-10-using-configuration-manager.md) 

259
windows/deployment/deploy-windows-mdt/prepare-for-windows-deployment-with-mdt.md
View File

@ -1,129 +1,130 @@
---
title: Prepare for deployment with MDT (Windows 10)
description: This topic will walk you through the steps necessary to create the server structure required to deploy the Windows 10 operating system using the Microsoft Deployment Toolkit (MDT).
ms.assetid: 5103c418-0c61-414b-b93c-a8e8207d1226
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, system requirements
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Prepare for deployment with MDT
**Applies to**
- Windows 10
This topic will walk you through the steps necessary to create the server structure required to deploy the Windows 10 operating system using the Microsoft Deployment Toolkit (MDT). It covers the installation of the necessary system prerequisites, the creation of shared folders and service accounts, and the configuration of security permissions in the files system and in Active Directory.
For the purposes of this topic, we will use two machines: DC01 and MDT01. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. MDT01 is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
## <a href="" id="sec01"></a>System requirements
MDT requires the following components:
- Any of the following operating systems:
- Windows 7
- Windows 8
- Windows 8.1
- Windows 10
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Assessment and Deployment Kit (ADK) for Windows 10
- Windows PowerShell
- Microsoft .NET Framework
## <a href="" id="sec02"></a>Install Windows ADK for Windows 10
These steps assume that you have the MDT01 member server installed and configured and that you have downloaded [Windows ADK for Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=526803) to the E:\\Downloads\\ADK folder.
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of <strong>P@ssw0rd</strong>.
2. Start the **ADK Setup** (E:\\Downloads\\ADK\\adksetup.exe), and on the first wizard page, click **Continue**.
3. On the **Select the features you want to change** page, select the features below and complete the wizard using the default settings:
1. Deployment Tools
2. Windows Preinstallation Environment (Windows PE)
3. User State Migration Tool (USMT)
>[!IMPORTANT]
>Starting with Windows 10, version 1809, Windows PE is released separately from the ADK. See [Download and install the Windows ADK](https://docs.microsoft.com/windows-hardware/get-started/adk-install) for more information.
## <a href="" id="sec03"></a>Install MDT
These steps assume that you have downloaded [MDT](https://go.microsoft.com/fwlink/p/?LinkId=618117 ) to the E:\\Downloads\\MDT folder on MDT01.
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of <strong>P@ssw0rd</strong>.
2. Install **MDT** (E:\\Downloads\\MDT\\MicrosoftDeploymentToolkit\_x64.msi) with the default settings.
## <a href="" id="sec04"></a>Create the OU structure
If you do not have an organizational unit (OU) structure in your Active Directory, you should create one. In this section, you create an OU structure and a service account for MDT.
1. On DC01, using Active Directory User and Computers, in the contoso.com domain level, create a top-level OU named **Contoso**.
2. In the **Contoso** OU, create the following OUs:
1. Accounts
2. Computers
3. Groups
3. In the **Contoso / Accounts** OU, create the following underlying OUs:
1. Admins
2. Service Accounts
3. Users
4. In the **Contoso / Computers** OU, create the following underlying OUs:
1. Servers
2. Workstations
5. In the **Contoso / Groups** OU, create the following OU:
- Security Groups
![figure 6](../images/mdt-05-fig07.png)
Figure 6. A sample of how the OU structure will look after all the OUs are created.
## <a href="" id="sec05"></a>Create the MDT service account
When creating a reference image, you need an account for MDT. The MDT Build Account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01.
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
2. Select the **Service Accounts** OU and create the **MDT\_BA** account using the following settings:
1. Name: MDT\_BA
2. User logon name: MDT\_BA
3. Password: P@ssw0rd
4. User must change password at next logon: Clear
5. User cannot change password: Selected
6. Password never expires: Selected
## <a href="" id="sec06"></a>Create and share the logs folder
By default MDT stores the log files locally on the client. In order to capture a reference image, you will need to enable server-side logging and, to do that, you will need to have a folder in which to store the logs. For more information, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create and share the **E:\\Logs** folder by running the following commands in an elevated Windows PowerShell prompt:
``` syntax
New-Item -Path E:\Logs -ItemType directory
New-SmbShare -Name Logs$ -Path E:\Logs -ChangeAccess EVERYONE
icacls E:\Logs /grant '"MDT_BA":(OI)(CI)(M)'
```
![figure 7](../images/mdt-05-fig08.png)
Figure 7. The Sharing tab of the E:\\Logs folder after sharing it with PowerShell.
## <a href="" id="sec07"></a>Use CMTrace to read log files (optional)
The log files in MDT Lite Touch are formatted to be read by Configuration Manager Trace (CMTrace), which is available as part [of Microsoft System Center 2012 R2 Configuration Manager Toolkit](https://go.microsoft.com/fwlink/p/?LinkId=734717). You can use Notepad, but CMTrace formatting makes the logs easier to read.
![figure 8](../images/mdt-05-fig09.png)
Figure 8. An MDT log file opened in Notepad.
![figure 9](../images/mdt-05-fig10.png)
Figure 9. The same log file, opened in CMTrace, is much easier to read.
## Related topics
[Key features in MDT](key-features-in-mdt.md)
[MDT Lite Touch components](mdt-lite-touch-components.md)
---
title: Prepare for deployment with MDT (Windows 10)
description: This topic will walk you through the steps necessary to create the server structure required to deploy the Windows 10 operating system using the Microsoft Deployment Toolkit (MDT).
ms.assetid: 5103c418-0c61-414b-b93c-a8e8207d1226
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, system requirements
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Prepare for deployment with MDT
**Applies to**
- Windows 10
This topic will walk you through the steps necessary to create the server structure required to deploy the Windows 10 operating system using the Microsoft Deployment Toolkit (MDT). It covers the installation of the necessary system prerequisites, the creation of shared folders and service accounts, and the configuration of security permissions in the files system and in Active Directory.
For the purposes of this topic, we will use two machines: DC01 and MDT01. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. MDT01 is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
## <a href="" id="sec01"></a>System requirements
MDT requires the following components:
- Any of the following operating systems:
- Windows 7
- Windows 8
- Windows 8.1
- Windows 10
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Assessment and Deployment Kit (ADK) for Windows 10
- Windows PowerShell
- Microsoft .NET Framework
## <a href="" id="sec02"></a>Install Windows ADK for Windows 10
These steps assume that you have the MDT01 member server installed and configured and that you have downloaded [Windows ADK for Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=526803) to the E:\\Downloads\\ADK folder.
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of <strong>P@ssw0rd</strong>.
2. Start the **ADK Setup** (E:\\Downloads\\ADK\\adksetup.exe), and on the first wizard page, click **Continue**.
3. On the **Select the features you want to change** page, select the features below and complete the wizard using the default settings:
1. Deployment Tools
2. Windows Preinstallation Environment (Windows PE)
3. User State Migration Tool (USMT)
>[!IMPORTANT]
>Starting with Windows 10, version 1809, Windows PE is released separately from the ADK. See [Download and install the Windows ADK](https://docs.microsoft.com/windows-hardware/get-started/adk-install) for more information.
## <a href="" id="sec03"></a>Install MDT
These steps assume that you have downloaded [MDT](https://go.microsoft.com/fwlink/p/?LinkId=618117 ) to the E:\\Downloads\\MDT folder on MDT01.
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of <strong>P@ssw0rd</strong>.
2. Install **MDT** (E:\\Downloads\\MDT\\MicrosoftDeploymentToolkit\_x64.msi) with the default settings.
## <a href="" id="sec04"></a>Create the OU structure
If you do not have an organizational unit (OU) structure in your Active Directory, you should create one. In this section, you create an OU structure and a service account for MDT.
1. On DC01, using Active Directory User and Computers, in the contoso.com domain level, create a top-level OU named **Contoso**.
2. In the **Contoso** OU, create the following OUs:
1. Accounts
2. Computers
3. Groups
3. In the **Contoso / Accounts** OU, create the following underlying OUs:
1. Admins
2. Service Accounts
3. Users
4. In the **Contoso / Computers** OU, create the following underlying OUs:
1. Servers
2. Workstations
5. In the **Contoso / Groups** OU, create the following OU:
- Security Groups
![figure 6](../images/mdt-05-fig07.png)
Figure 6. A sample of how the OU structure will look after all the OUs are created.
## <a href="" id="sec05"></a>Create the MDT service account
When creating a reference image, you need an account for MDT. The MDT Build Account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01.
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
2. Select the **Service Accounts** OU and create the **MDT\_BA** account using the following settings:
1. Name: MDT\_BA
2. User logon name: MDT\_BA
3. Password: P@ssw0rd
4. User must change password at next logon: Clear
5. User cannot change password: Selected
6. Password never expires: Selected
## <a href="" id="sec06"></a>Create and share the logs folder
By default MDT stores the log files locally on the client. In order to capture a reference image, you will need to enable server-side logging and, to do that, you will need to have a folder in which to store the logs. For more information, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create and share the **E:\\Logs** folder by running the following commands in an elevated Windows PowerShell prompt:
``` powershell
New-Item -Path E:\Logs -ItemType directory
New-SmbShare -Name Logs$ -Path E:\Logs -ChangeAccess EVERYONE
icacls E:\Logs /grant '"MDT_BA":(OI)(CI)(M)'
```
![figure 7](../images/mdt-05-fig08.png)
Figure 7. The Sharing tab of the E:\\Logs folder after sharing it with PowerShell.
## <a href="" id="sec07"></a>Use CMTrace to read log files (optional)
The log files in MDT Lite Touch are formatted to be read by Configuration Manager Trace (CMTrace), which is available as part [of Microsoft System Center 2012 R2 Configuration Manager Toolkit](https://go.microsoft.com/fwlink/p/?LinkId=734717). You can use Notepad, but CMTrace formatting makes the logs easier to read.
![figure 8](../images/mdt-05-fig09.png)
Figure 8. An MDT log file opened in Notepad.
![figure 9](../images/mdt-05-fig10.png)
Figure 9. The same log file, opened in CMTrace, is much easier to read.
## Related topics
[Key features in MDT](key-features-in-mdt.md)
[MDT Lite Touch components](mdt-lite-touch-components.md)

303
windows/deployment/deploy-windows-mdt/replace-a-windows-7-computer-with-a-windows-10-computer.md
View File

@ -1,151 +1,152 @@
---
title: Replace a Windows 7 computer with a Windows 10 computer (Windows 10)
description: A computer replace scenario for Windows 10 is quite similar to a computer refresh for Windows 10; however, because you are replacing a machine, you cannot store the backup on the old computer.
ms.assetid: acf091c9-f8f4-4131-9845-625691c09a2a
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, deployment, replace
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Replace a Windows 7 computer with a Windows 10 computer
**Applies to**
- Windows 10
A computer replace scenario for Windows 10 is quite similar to a computer refresh for Windows 10; however, because you are replacing a machine, you cannot store the backup on the old computer. Instead you need to store the backup to a location where the new computer can read it.
For the purposes of this topic, we will use four machines: DC01, MDT01, PC0002, and PC0007. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. PC0002 is an old machine running Windows 7 SP1. It is going to be replaced by a new Windows 10 machine, PC0007. User State Migration Tool (USMT) will be used to backup and restore data and settings. MDT01, PC0002, and PC0007 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
![The machines used in this topic](../images/mdt-03-fig01.png "The machines used in this topic")
Figure 1. The machines used in this topic.
## <a href="" id="sec01"></a>Prepare for the computer replace
When preparing for the computer replace, you need to create a folder in which to store the backup, and a backup only task sequence that you run on the old computer.
### Configure the rules on the Microsoft Deployment Toolkit (MDT) Production share
1. On MDT01, using the Deployment Workbench, update the MDT Production deployment share rules.
2. Change the **SkipUserData=YES** option to **NO**, and click **OK**.
### Create and share the MigData folder
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create and share the **E:\\MigData** folder by running the following three commands in an elevated Windows PowerShell prompt:
``` syntax
New-Item -Path E:\MigData -ItemType directory
New-SmbShare ?Name MigData$ ?Path E:\MigData
-ChangeAccess EVERYONE
icacls E:\MigData /grant '"MDT_BA":(OI)(CI)(M)'
```
### Create a backup only (replace) task sequence
3. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the **Task Sequences** node and create a new folder named **Other**.
4. Right-click the **Other** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
* Task sequence ID: REPLACE-001
* Task sequence name: Backup Only Task Sequence
* Task sequence comments: Run USMT to backup user data and settings
* Template: Standard Client Replace Task Sequence
5. In the **Other** folder, double-click **Backup Only Task Sequence**, and then in the **Task Sequence** tab, review the sequence. Notice that it only contains a subset of the normal client task sequence actions.
![The Backup Only Task Sequence action list](../images/mdt-03-fig02.png "The Backup Only Task Sequence action list")
Figure 2. The Backup Only Task Sequence action list.
## <a href="" id="sec02"></a>Perform the computer replace
During a computer replace, these are the high-level steps that occur:
1. On the computer you are replacing, a special replace task sequence runs the USMT backup and, if you configured it, runs the optional full Window Imaging (WIM) backup.
2. On the new machine, you perform a standard bare-metal deployment. At the end of the bare-metal deployment, the USMT backup from the old computer is restored.
### Execute the replace task sequence
1. On PC0002, log on as **CONTOSO\\Administrator**.
2. Verify that you have write access to the **\\\\MDT01\\MigData$** share.
3. Execute **\\\\MDT01\\MDTProduction$\\Scripts\\LiteTouch.vbs**.
4. Complete the Windows Deployment Wizard using the following settings:
1. Select a task sequence to execute on this computer: Backup Only Task Sequence
* Specify where to save your data and settings: Specify a location
* Location: \\\\MDT01\\MigData$\\PC0002
>[!NOTE]
>If you are replacing the computer at a remote site you should create the MigData folder on MDT02 and use that share instead.
2. Specify where to save a complete computer backup: Do not back up the existing computer
3. Password: P@ssw0rd
The task sequence will now run USMT (Scanstate.exe) to capture user data and settings of the machine.
![The new task sequence](../images/mdt-03-fig03.png "The new task sequence")
Figure 3. The new task sequence running the Capture User State action on PC0002.
5. On MDT01, verify that you have an USMT.MIG compressed backup file in the **E:\\MigData\\PC0002\\USMT** folder.
![The USMT backup](../images/mdt-03-fig04.png "The USMT backup")
Figure 4. The USMT backup of PC0002.
### Deploy the PC0007 virtual machine
1. Create a virtual machine with the following settings:
* Name: PC0007
* Location: C:\\VMs
* Generation: 2
* Memory: 2048 MB
* Hard disk: 60 GB (dynamic disk)
2. Start the PC0007 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
![The initial PXE boot process](../images/mdt-03-fig05.png "The initial PXE boot process")
Figure 5. The initial PXE boot process of PC0005.
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
* Password: P@ssw0rd
* Select a task sequence to execute on this computer:
* Windows 10 Enterprise x64 RTM Custom Image
* Computer Name: PC0007
* Applications: Select the Install - Adobe Reader XI - x86 application.
4. The setup now starts and does the following:
* Installs the Windows 10 Enterprise operating system.
* Installs the added application.
* Updates the operating system via your local Windows Server Update Services (WSUS) server.
* Restores the USMT backup from PC0002.
## Related topics
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT](deploy-a-windows-10-image-using-mdt.md)
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-10-deployment.md)
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
[Configure MDT settings](configure-mdt-settings.md)
---
title: Replace a Windows 7 computer with a Windows 10 computer (Windows 10)
description: A computer replace scenario for Windows 10 is quite similar to a computer refresh for Windows 10; however, because you are replacing a machine, you cannot store the backup on the old computer.
ms.assetid: acf091c9-f8f4-4131-9845-625691c09a2a
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, deployment, replace
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Replace a Windows 7 computer with a Windows 10 computer
**Applies to**
- Windows 10
A computer replace scenario for Windows 10 is quite similar to a computer refresh for Windows 10; however, because you are replacing a machine, you cannot store the backup on the old computer. Instead you need to store the backup to a location where the new computer can read it.
For the purposes of this topic, we will use four machines: DC01, MDT01, PC0002, and PC0007. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard server. PC0002 is an old machine running Windows 7 SP1. It is going to be replaced by a new Windows 10 machine, PC0007. User State Migration Tool (USMT) will be used to backup and restore data and settings. MDT01, PC0002, and PC0007 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
![The machines used in this topic](../images/mdt-03-fig01.png "The machines used in this topic")
Figure 1. The machines used in this topic.
## <a href="" id="sec01"></a>Prepare for the computer replace
When preparing for the computer replace, you need to create a folder in which to store the backup, and a backup only task sequence that you run on the old computer.
### Configure the rules on the Microsoft Deployment Toolkit (MDT) Production share
1. On MDT01, using the Deployment Workbench, update the MDT Production deployment share rules.
2. Change the **SkipUserData=YES** option to **NO**, and click **OK**.
### Create and share the MigData folder
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create and share the **E:\\MigData** folder by running the following three commands in an elevated Windows PowerShell prompt:
``` powershell
New-Item -Path E:\MigData -ItemType directory
New-SmbShare ?Name MigData$ ?Path E:\MigData
-ChangeAccess EVERYONE
icacls E:\MigData /grant '"MDT_BA":(OI)(CI)(M)'
```
### Create a backup only (replace) task sequence
3. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the **Task Sequences** node and create a new folder named **Other**.
4. Right-click the **Other** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
* Task sequence ID: REPLACE-001
* Task sequence name: Backup Only Task Sequence
* Task sequence comments: Run USMT to backup user data and settings
* Template: Standard Client Replace Task Sequence
5. In the **Other** folder, double-click **Backup Only Task Sequence**, and then in the **Task Sequence** tab, review the sequence. Notice that it only contains a subset of the normal client task sequence actions.
![The Backup Only Task Sequence action list](../images/mdt-03-fig02.png "The Backup Only Task Sequence action list")
Figure 2. The Backup Only Task Sequence action list.
## <a href="" id="sec02"></a>Perform the computer replace
During a computer replace, these are the high-level steps that occur:
1. On the computer you are replacing, a special replace task sequence runs the USMT backup and, if you configured it, runs the optional full Window Imaging (WIM) backup.
2. On the new machine, you perform a standard bare-metal deployment. At the end of the bare-metal deployment, the USMT backup from the old computer is restored.
### Execute the replace task sequence
1. On PC0002, log on as **CONTOSO\\Administrator**.
2. Verify that you have write access to the **\\\\MDT01\\MigData$** share.
3. Execute **\\\\MDT01\\MDTProduction$\\Scripts\\LiteTouch.vbs**.
4. Complete the Windows Deployment Wizard using the following settings:
1. Select a task sequence to execute on this computer: Backup Only Task Sequence
* Specify where to save your data and settings: Specify a location
* Location: \\\\MDT01\\MigData$\\PC0002
>[!NOTE]
>If you are replacing the computer at a remote site you should create the MigData folder on MDT02 and use that share instead.
2. Specify where to save a complete computer backup: Do not back up the existing computer
3. Password: P@ssw0rd
The task sequence will now run USMT (Scanstate.exe) to capture user data and settings of the machine.
![The new task sequence](../images/mdt-03-fig03.png "The new task sequence")
Figure 3. The new task sequence running the Capture User State action on PC0002.
5. On MDT01, verify that you have an USMT.MIG compressed backup file in the **E:\\MigData\\PC0002\\USMT** folder.
![The USMT backup](../images/mdt-03-fig04.png "The USMT backup")
Figure 4. The USMT backup of PC0002.
### Deploy the PC0007 virtual machine
1. Create a virtual machine with the following settings:
* Name: PC0007
* Location: C:\\VMs
* Generation: 2
* Memory: 2048 MB
* Hard disk: 60 GB (dynamic disk)
2. Start the PC0007 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
![The initial PXE boot process](../images/mdt-03-fig05.png "The initial PXE boot process")
Figure 5. The initial PXE boot process of PC0005.
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
* Password: P@ssw0rd
* Select a task sequence to execute on this computer:
* Windows 10 Enterprise x64 RTM Custom Image
* Computer Name: PC0007
* Applications: Select the Install - Adobe Reader XI - x86 application.
4. The setup now starts and does the following:
* Installs the Windows 10 Enterprise operating system.
* Installs the added application.
* Updates the operating system via your local Windows Server Update Services (WSUS) server.
* Restores the USMT backup from PC0002.
## Related topics
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT](deploy-a-windows-10-image-using-mdt.md)
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-10-deployment.md)
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
[Configure MDT settings](configure-mdt-settings.md)

329
windows/deployment/deploy-windows-mdt/set-up-mdt-for-bitlocker.md
View File

@ -1,163 +1,166 @@
---
title: Set up MDT for BitLocker (Windows 10)
ms.assetid: 386e6713-5c20-4d2a-a220-a38d94671a38
ms.reviewer:
manager: laurawi
ms.author: greglin
description:
keywords: disk, encryption, TPM, configure, secure, script
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Set up MDT for BitLocker
This topic will show you how to configure your environment for BitLocker, the disk volume encryption built into Windows 10 Enterprise and Windows 10 Pro, using MDT. BitLocker in Windows 10 has two requirements in regard to an operating system deployment:
- A protector, which can either be stored in the Trusted Platform Module (TPM) chip, or stored as a password. Technically, you also can use a USB stick to store the protector, but it's not a practical approach as the USB stick can be lost or stolen. We, therefore, recommend that you instead use a TPM chip and/or a password.
- Multiple partitions on the hard drive.
To configure your environment for BitLocker, you will need to do the following:
1. Configure Active Directory for BitLocker.
2. Download the various BitLocker scripts and tools.
3. Configure the operating system deployment task sequence for BitLocker.
4. Configure the rules (CustomSettings.ini) for BitLocker.
>[!NOTE]
>Even though it is not a BitLocker requirement, we recommend configuring BitLocker to store the recovery key and TPM owner information in Active Directory. For additional information about these features, see [Backing Up BitLocker and TPM Recovery Information to AD DS](https://go.microsoft.com/fwlink/p/?LinkId=619548). If you have access to Microsoft BitLocker Administration and Monitoring (MBAM), which is part of Microsoft Desktop Optimization Pack (MDOP), you have additional management features for BitLocker.
For the purposes of this topic, we will use DC01, a domain controller that is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
## <a href="" id="sec01"></a>Configure Active Directory for BitLocker
To enable BitLocker to store the recovery key and TPM information in Active Directory, you need to create a Group Policy for it in Active Directory. For this section, we are running Windows Server 2012 R2, so you do not need to extend the Schema. You do, however, need to set the appropriate permissions in Active Directory.
>[!NOTE]
>Depending on the Active Directory Schema version, you might need to update the Schema before you can store BitLocker information in Active Directory.
In Windows Server 2012 R2 (as well as in Windows Server 2008 R2 and Windows Server 2012), you have access to the BitLocker Drive Encryption Administration Utilities features, which will help you manage BitLocker. When you install the features, the BitLocker Active Directory Recovery Password Viewer is included, and it extends Active Directory Users and Computers with BitLocker Recovery information.
![figure 2](../images/mdt-09-fig02.png)
Figure 2. The BitLocker Recovery information on a computer object in the contoso.com domain.
### Add the BitLocker Drive Encryption Administration Utilities
The BitLocker Drive Encryption Administration Utilities are added as features via Server Manager (or Windows PowerShell):
1. On DC01, log on as **CONTOSO\\Administrator**, and, using Server Manager, click **Add roles and features**.
2. On the **Before you begin** page, click **Next**.
3. On the **Select installation type** page, select **Role-based or feature-based installation**, and click **Next**.
4. On the **Select destination server** page, select **DC01.contoso.com** and click **Next**.
5. On the **Select server roles** page, click **Next**.
6. On the **Select features** page, expand **Remote Server Administration Tools**, expand **Feature Administration Tools**, select the following features, and then click **Next**:
1. BitLocker Drive Encryption Administration Utilities
2. BitLocker Drive Encryption Tools
3. BitLocker Recovery Password Viewer
7. On the **Confirm installation selections** page, click **Install** and then click **Close**.
![figure 3](../images/mdt-09-fig03.png)
Figure 3. Selecting the BitLocker Drive Encryption Administration Utilities.
### Create the BitLocker Group Policy
Following these steps, you enable the backup of BitLocker and TPM recovery information to Active Directory. You also enable the policy for the TPM validation profile.
1. On DC01, using Group Policy Management, right-click the **Contoso** organizational unit (OU), and select **Create a GPO in this domain, and Link it here**.
2. Assign the name **BitLocker Policy** to the new Group Policy.
3. Expand the **Contoso** OU, right-click the **BitLocker Policy**, and select **Edit**. Configure the following policy settings:
Computer Configuration / Policies / Administrative Templates / Windows Components / BitLocker Drive Encryption / Operating System Drives
1. Enable the **Choose how BitLocker-protected operating system drives can be recovered** policy, and configure the following settings:
1. Allow data recovery agent (default)
2. Save BitLocker recovery information to Active Directory Domain Services (default)
3. Do not enable BitLocker until recovery information is stored in AD DS for operating system drives
2. Enable the **Configure TPM platform validation profile for BIOS-based firmware configurations** policy.
3. Enable the **Configure TPM platform validation profile for native UEFI firmware configurations** policy.
Computer Configuration / Policies / Administrative Templates / System / Trusted Platform Module Services
4. Enable the **Turn on TPM backup to Active Directory Domain Services** policy.
>[!NOTE]
>If you consistently get the error "Windows BitLocker Drive Encryption Information. The system boot information has changed since BitLocker was enabled. You must supply a BitLocker recovery password to start this system." after encrypting a computer with BitLocker, you might have to change the various "Configure TPM platform validation profile" Group Policies, as well. Whether or not you need to do this will depend on the hardware you are using.
### Set permissions in Active Directory for BitLocker
In addition to the Group Policy created previously, you need to configure permissions in Active Directory to be able to store the TPM recovery information. In these steps, we assume you have downloaded the [Add-TPMSelfWriteACE.vbs script](https://go.microsoft.com/fwlink/p/?LinkId=167133) from Microsoft to C:\\Setup\\Scripts on DC01.
1. On DC01, start an elevated PowerShell prompt (run as Administrator).
2. Configure the permissions by running the following command:
``` syntax
cscript C:\Setup\Scripts\Add-TPMSelfWriteACE.vbs
```
![figure 4](../images/mdt-09-fig04.png)
Figure 4. Running the Add-TPMSelfWriteACE.vbs script on DC01.
## <a href="" id="sec02"></a>Add BIOS configuration tools from Dell, HP, and Lenovo
If you want to automate enabling the TPM chip as part of the deployment process, you need to download the vendor tools and add them to your task sequences, either directly or in a script wrapper.
### Add tools from Dell
The Dell tools are available via the Dell Client Configuration Toolkit (CCTK). The executable file from Dell is named cctk.exe. Here is a sample command to enable TPM and set a BIOS password using the cctk.exe tool:
``` syntax
cctk.exe --tpm=on --valsetuppwd=Password1234
```
### Add tools from HP
The HP tools are part of HP System Software Manager. The executable file from HP is named BiosConfigUtility.exe. This utility uses a configuration file for the BIOS settings. Here is a sample command to enable TPM and set a BIOS password using the BiosConfigUtility.exe tool:
``` syntax
BIOSConfigUtility.EXE /SetConfig:TPMEnable.REPSET /NewAdminPassword:Password1234
```
And the sample content of the TPMEnable.REPSET file:
``` syntax
English
Activate Embedded Security On Next Boot
*Enable
Embedded Security Activation Policy
*No prompts
F1 to Boot
Allow user to reject
Embedded Security Device Availability
*Available
```
### Add tools from Lenovo
The Lenovo tools are a set of VBScripts available as part of the Lenovo BIOS Setup using Windows Management Instrumentation Deployment Guide. Lenovo also provides a separate download of the scripts. Here is a sample command to enable TPM using the Lenovo tools:
``` syntax
cscript.exe SetConfig.vbs SecurityChip Active
```
## <a href="" id="sec03"></a>Configure the Windows 10 task sequence to enable BitLocker
When configuring a task sequence to run any BitLocker tool, either directly or using a custom script, it is helpful if you also add some logic to detect whether the BIOS is already configured on the machine. In this task sequence, we are using a sample script (ZTICheckforTPM.wsf) from the Deployment Guys web page to check the status on the TPM chip. You can download this script from the Deployment Guys Blog post, [Check to see if the TPM is enabled](https://go.microsoft.com/fwlink/p/?LinkId=619549). In the following task sequence, we have added five actions:
- **Check TPM Status.** Runs the ZTICheckforTPM.wsf script to determine if TPM is enabled. Depending on the status, the script will set the TPMEnabled and TPMActivated properties to either true or false.
- **Configure BIOS for TPM.** Runs the vendor tools (in this case, HP, Dell, and Lenovo). To ensure this action is run only when necessary, add a condition so the action is run only when the TPM chip is not already activated. Use the properties from the ZTICheckforTPM.wsf.
**Note**  
It is common for organizations wrapping these tools in scripts to get additional logging and error handling.
- **Restart computer.** Self-explanatory, reboots the computer.
- **Check TPM Status.** Runs the ZTICheckforTPM.wsf script one more time.
- **Enable BitLocker.** Runs the built-in action to activate BitLocker.
## Related topics
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
---
title: Set up MDT for BitLocker (Windows 10)
ms.assetid: 386e6713-5c20-4d2a-a220-a38d94671a38
ms.reviewer:
manager: laurawi
ms.author: greglin
description:
keywords: disk, encryption, TPM, configure, secure, script
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Set up MDT for BitLocker
This topic will show you how to configure your environment for BitLocker, the disk volume encryption built into Windows 10 Enterprise and Windows 10 Pro, using MDT. BitLocker in Windows 10 has two requirements in regard to an operating system deployment:
- A protector, which can either be stored in the Trusted Platform Module (TPM) chip, or stored as a password. Technically, you also can use a USB stick to store the protector, but it's not a practical approach as the USB stick can be lost or stolen. We, therefore, recommend that you instead use a TPM chip and/or a password.
- Multiple partitions on the hard drive.
To configure your environment for BitLocker, you will need to do the following:
1. Configure Active Directory for BitLocker.
2. Download the various BitLocker scripts and tools.
3. Configure the operating system deployment task sequence for BitLocker.
4. Configure the rules (CustomSettings.ini) for BitLocker.
>[!NOTE]
>Even though it is not a BitLocker requirement, we recommend configuring BitLocker to store the recovery key and TPM owner information in Active Directory. For additional information about these features, see [Backing Up BitLocker and TPM Recovery Information to AD DS](https://go.microsoft.com/fwlink/p/?LinkId=619548). If you have access to Microsoft BitLocker Administration and Monitoring (MBAM), which is part of Microsoft Desktop Optimization Pack (MDOP), you have additional management features for BitLocker.
For the purposes of this topic, we will use DC01, a domain controller that is a member of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
## <a href="" id="sec01"></a>Configure Active Directory for BitLocker
To enable BitLocker to store the recovery key and TPM information in Active Directory, you need to create a Group Policy for it in Active Directory. For this section, we are running Windows Server 2012 R2, so you do not need to extend the Schema. You do, however, need to set the appropriate permissions in Active Directory.
>[!NOTE]
>Depending on the Active Directory Schema version, you might need to update the Schema before you can store BitLocker information in Active Directory.
In Windows Server 2012 R2 (as well as in Windows Server 2008 R2 and Windows Server 2012), you have access to the BitLocker Drive Encryption Administration Utilities features, which will help you manage BitLocker. When you install the features, the BitLocker Active Directory Recovery Password Viewer is included, and it extends Active Directory Users and Computers with BitLocker Recovery information.
![figure 2](../images/mdt-09-fig02.png)
Figure 2. The BitLocker Recovery information on a computer object in the contoso.com domain.
### Add the BitLocker Drive Encryption Administration Utilities
The BitLocker Drive Encryption Administration Utilities are added as features via Server Manager (or Windows PowerShell):
1. On DC01, log on as **CONTOSO\\Administrator**, and, using Server Manager, click **Add roles and features**.
2. On the **Before you begin** page, click **Next**.
3. On the **Select installation type** page, select **Role-based or feature-based installation**, and click **Next**.
4. On the **Select destination server** page, select **DC01.contoso.com** and click **Next**.
5. On the **Select server roles** page, click **Next**.
6. On the **Select features** page, expand **Remote Server Administration Tools**, expand **Feature Administration Tools**, select the following features, and then click **Next**:
1. BitLocker Drive Encryption Administration Utilities
2. BitLocker Drive Encryption Tools
3. BitLocker Recovery Password Viewer
7. On the **Confirm installation selections** page, click **Install** and then click **Close**.
![figure 3](../images/mdt-09-fig03.png)
Figure 3. Selecting the BitLocker Drive Encryption Administration Utilities.
### Create the BitLocker Group Policy
Following these steps, you enable the backup of BitLocker and TPM recovery information to Active Directory. You also enable the policy for the TPM validation profile.
1. On DC01, using Group Policy Management, right-click the **Contoso** organizational unit (OU), and select **Create a GPO in this domain, and Link it here**.
2. Assign the name **BitLocker Policy** to the new Group Policy.
3. Expand the **Contoso** OU, right-click the **BitLocker Policy**, and select **Edit**. Configure the following policy settings:
Computer Configuration / Policies / Administrative Templates / Windows Components / BitLocker Drive Encryption / Operating System Drives
1. Enable the **Choose how BitLocker-protected operating system drives can be recovered** policy, and configure the following settings:
1. Allow data recovery agent (default)
2. Save BitLocker recovery information to Active Directory Domain Services (default)
3. Do not enable BitLocker until recovery information is stored in AD DS for operating system drives
2. Enable the **Configure TPM platform validation profile for BIOS-based firmware configurations** policy.
3. Enable the **Configure TPM platform validation profile for native UEFI firmware configurations** policy.
Computer Configuration / Policies / Administrative Templates / System / Trusted Platform Module Services
4. Enable the **Turn on TPM backup to Active Directory Domain Services** policy.
>[!NOTE]
>If you consistently get the error "Windows BitLocker Drive Encryption Information. The system boot information has changed since BitLocker was enabled. You must supply a BitLocker recovery password to start this system." after encrypting a computer with BitLocker, you might have to change the various "Configure TPM platform validation profile" Group Policies, as well. Whether or not you need to do this will depend on the hardware you are using.
### Set permissions in Active Directory for BitLocker
In addition to the Group Policy created previously, you need to configure permissions in Active Directory to be able to store the TPM recovery information. In these steps, we assume you have downloaded the [Add-TPMSelfWriteACE.vbs script](https://go.microsoft.com/fwlink/p/?LinkId=167133) from Microsoft to C:\\Setup\\Scripts on DC01.
1. On DC01, start an elevated PowerShell prompt (run as Administrator).
2. Configure the permissions by running the following command:
``` syntax
cscript C:\Setup\Scripts\Add-TPMSelfWriteACE.vbs
```
![figure 4](../images/mdt-09-fig04.png)
Figure 4. Running the Add-TPMSelfWriteACE.vbs script on DC01.
## <a href="" id="sec02"></a>Add BIOS configuration tools from Dell, HP, and Lenovo
If you want to automate enabling the TPM chip as part of the deployment process, you need to download the vendor tools and add them to your task sequences, either directly or in a script wrapper.
### Add tools from Dell
The Dell tools are available via the Dell Client Configuration Toolkit (CCTK). The executable file from Dell is named cctk.exe. Here is a sample command to enable TPM and set a BIOS password using the cctk.exe tool:
``` syntax
cctk.exe --tpm=on --valsetuppwd=Password1234
```
### Add tools from HP
The HP tools are part of HP System Software Manager. The executable file from HP is named BiosConfigUtility.exe. This utility uses a configuration file for the BIOS settings. Here is a sample command to enable TPM and set a BIOS password using the BiosConfigUtility.exe tool:
``` syntax
BIOSConfigUtility.EXE /SetConfig:TPMEnable.REPSET /NewAdminPassword:Password1234
```
And the sample content of the TPMEnable.REPSET file:
``` syntax
English
Activate Embedded Security On Next Boot
*Enable
Embedded Security Activation Policy
*No prompts
F1 to Boot
Allow user to reject
Embedded Security Device Availability
*Available
```
### Add tools from Lenovo
The Lenovo tools are a set of VBScripts available as part of the Lenovo BIOS Setup using Windows Management Instrumentation Deployment Guide. Lenovo also provides a separate download of the scripts. Here is a sample command to enable TPM using the Lenovo tools:
``` syntax
cscript.exe SetConfig.vbs SecurityChip Active
```
## <a href="" id="sec03"></a>Configure the Windows 10 task sequence to enable BitLocker
When configuring a task sequence to run any BitLocker tool, either directly or using a custom script, it is helpful if you also add some logic to detect whether the BIOS is already configured on the machine. In the following task sequence, we are using a sample script (ZTICheckforTPM.wsf) from the Deployment Guys web page to check the status on the TPM chip. You can download this script from the Deployment Guys Blog post, [Check to see if the TPM is enabled](https://go.microsoft.com/fwlink/p/?LinkId=619549).
In the following task sequence, we added five actions:
- **Check TPM Status.** Runs the ZTICheckforTPM.wsf script to determine if TPM is enabled. Depending on the status, the script will set the TPMEnabled and TPMActivated properties to either true or false.
- **Configure BIOS for TPM.** Runs the vendor tools (in this case, HP, Dell, and Lenovo). To ensure this action is run only when necessary, add a condition so the action is run only when the TPM chip is not already activated. Use the properties from the ZTICheckforTPM.wsf.
**Note**  
It is common for organizations to wrap these tools in scripts to get additional logging and error handling.
- **Restart computer.** Self-explanatory, reboots the computer.
- **Check TPM Status.** Runs the ZTICheckforTPM.wsf script one more time.
- **Enable BitLocker.** Runs the built-in action to activate BitLocker.
## Related topics
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)

139
windows/deployment/deploy-windows-mdt/simulate-a-windows-10-deployment-in-a-test-environment.md
View File

@ -1,69 +1,70 @@
---
title: Simulate a Windows 10 deployment in a test environment (Windows 10)
description: This topic will walk you through the process of creating a simulated environment on which to test your Windows 10 deployment using MDT.
ms.assetid: 2de86c55-ced9-4078-b280-35e0329aea9c
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, script
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro author: greg-lindsay
ms.topic: article
---
# Simulate a Windows 10 deployment in a test environment
This topic will walk you through the process of creating a simulated environment on which to test your Windows 10 deployment using MDT. When working with advanced settings and rules, especially those like database calls, it is most efficient to be able to test the settings without having to run through a complete deployment. Luckily, MDT enables you to perform a simulated deployment by running the Gather process by itself. The simulation works best when you are using a domain-joined machine (client or server). In the following example, you use the PC0001 Windows 10 client.
For the purposes of this topic, you already will have either downloaded and installed the free Microsoft System Center 2012 R2 Configuration Manager Toolkit, or copied Configuration Manager Trace (CMTrace) if you have access to the System Center 2012 R2 Configuration Manager media. We also assume that you have downloaded the [sample Gather.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619361) from the TechNet gallery.
1. On PC0001, log on as **CONTOSO\\Administrator** using the password <strong>P@ssw0rd</strong>.
2. Using Computer Management, add the **CONTOSO\\MDT\_BA** user account to the local **Administrators** group.
3. Log off, and then log on to PC0001 as **CONTOSO\\MDT\_BA**.
4. Using File Explorer, create a folder named **C:\\MDT**.
5. Copy the downloaded Gather.ps1 script to the **C:\\MDT** folder.
6. From the **\\\\MDT01\\MDTProduction$\\Scripts** folder, copy the following files to **C:\\MDT**:
1. ZTIDataAccess.vbs
2. ZTIGather.wsf
3. ZTIGather.xml
4. ZTIUtility.vbs
7. From the **\\\\MDT01\\MDTProduction$\\Control** folder, copy the CustomSettings.ini file to **C:\\MDT**.
8. In the **C:\\MDT** folder, create a subfolder named **X64**.
9. From the **\\\\MDT01\\MDTProduction$\\Tools\\X64** folder, copy the Microsoft.BDD.Utility.dll file to **C:\\MDT\\X64**.
![figure 6](../images/mdt-09-fig06.png)
Figure 6. The C:\\MDT folder with the files added for the simulation environment.
10. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press Enter after each command:
``` syntax
Set-Location C:\MDT
.\Gather.ps1
```
11. Review the ZTIGather.log in the **C:\\MININT\\SMSOSD\\OSDLOGS** folder.
**Note**
Warnings or errors with regard to the Wizard.hta are expected. If the log file looks okay, you are ready to try a real deployment.
![figure 7](../images/mdt-09-fig07.png)
Figure 7. The ZTIGather.log file from PC0001, displaying some of its hardware capabilities.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
---
title: Simulate a Windows 10 deployment in a test environment (Windows 10)
description: This topic will walk you through the process of creating a simulated environment on which to test your Windows 10 deployment using MDT.
ms.assetid: 2de86c55-ced9-4078-b280-35e0329aea9c
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, script
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.sitesec: library
ms.pagetype: mdt
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Simulate a Windows 10 deployment in a test environment
This topic will walk you through the process of creating a simulated environment on which to test your Windows 10 deployment using MDT. When working with advanced settings and rules, especially those like database calls, it is most efficient to be able to test the settings without having to run through a complete deployment. Luckily, MDT enables you to perform a simulated deployment by running the Gather process by itself. The simulation works best when you are using a domain-joined machine (client or server). In the following example, you use the PC0001 Windows 10 client.
For the purposes of this topic, you already will have either downloaded and installed the free Microsoft System Center 2012 R2 Configuration Manager Toolkit, or copied Configuration Manager Trace (CMTrace) if you have access to the System Center 2012 R2 Configuration Manager media. We also assume that you have downloaded the [sample Gather.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619361) from the TechNet gallery.
1. On PC0001, log on as **CONTOSO\\Administrator** using the password <strong>P@ssw0rd</strong>.
2. Using Computer Management, add the **CONTOSO\\MDT\_BA** user account to the local **Administrators** group.
3. Log off, and then log on to PC0001 as **CONTOSO\\MDT\_BA**.
4. Using File Explorer, create a folder named **C:\\MDT**.
5. Copy the downloaded Gather.ps1 script to the **C:\\MDT** folder.
6. From the **\\\\MDT01\\MDTProduction$\\Scripts** folder, copy the following files to **C:\\MDT**:
1. ZTIDataAccess.vbs
2. ZTIGather.wsf
3. ZTIGather.xml
4. ZTIUtility.vbs
7. From the **\\\\MDT01\\MDTProduction$\\Control** folder, copy the CustomSettings.ini file to **C:\\MDT**.
8. In the **C:\\MDT** folder, create a subfolder named **X64**.
9. From the **\\\\MDT01\\MDTProduction$\\Tools\\X64** folder, copy the Microsoft.BDD.Utility.dll file to **C:\\MDT\\X64**.
![figure 6](../images/mdt-09-fig06.png)
Figure 6. The C:\\MDT folder with the files added for the simulation environment.
10. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press Enter after each command:
``` powershell
Set-Location C:\MDT
.\Gather.ps1
```
11. Review the ZTIGather.log in the **C:\\MININT\\SMSOSD\\OSDLOGS** folder.
**Note**
Warnings or errors with regard to the Wizard.hta are expected. If the log file looks okay, you are ready to try a real deployment.
![figure 7](../images/mdt-09-fig07.png)
Figure 7. The ZTIGather.log file from PC0001, displaying some of its hardware capabilities.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use web services in MDT](use-web-services-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)

273
windows/deployment/deploy-windows-mdt/use-web-services-in-mdt.md
View File

@ -1,136 +1,137 @@
---
title: Use web services in MDT (Windows 10)
description: In this topic, you will learn how to create a simple web service that generates computer names and then configure MDT to use that service during your Windows 10 deployment.
ms.assetid: 8f47535e-0551-4ccb-8f02-bb97539c6522
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, web apps
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.pagetype: mdt
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.topic: article
---
# Use web services in MDT
In this topic, you will learn how to create a simple web service that generates computer names and then configure MDT to use that service during your Windows 10 deployment. Web services provide a powerful way to assign settings during a deployment. Simply put, web services are web applications that run code on the server side, and MDT has built-in functions to call these web services.
Using a web service in MDT is straightforward, but it does require that you have enabled the Web Server (IIS) role on the server. Developing web services involves a little bit of coding, but for most web services used with MDT, you can use the free Microsoft Visual Studio Express 2013 for Web.
## <a href="" id="sec01"></a>Create a sample web service
In these steps we assume you have installed Microsoft Visual Studio Express 2013 for Web on PC0001 (the Windows 10 client) and downloaded the [MDT Sample Web Service](https://go.microsoft.com/fwlink/p/?LinkId=619363) from the Microsoft Download Center and extracted it to C:\\Projects.
1. On PC0001, using Visual Studio Express 2013 for Web, open the C:\\Projects\\MDTSample\\ MDTSample.sln solution file.
2. On the ribbon bar, verify that Release is selected.
3. In the **Debug** menu, select the **Build MDTSample** action.
4. On MDT01, create a folder structure for **E:\\MDTSample\\bin**.
5. From PC0001, copy the C:\\Projects\\MDTSample\\obj\\Release\\MDTSample.dll file to the **E:\\MDTSample\\bin** folder on MDT01.
6. From PC0001, copy the following files from C:\\Projects\\MDTSample file to the **E:\\MDTSample** folder on MDT01:
1. Web.config
2. mdtsample.asmx
![figure 15](../images/mdt-09-fig15.png)
Figure 15. The sample project in Microsoft Visual Studio Express 2013 for Web.
## <a href="" id="sec02"></a>Create an application pool for the web service
This section assumes that you have enabled the Web Server (IIS) role on MDT01.
1. On MDT01, using Server Manager, install the **IIS Management Console** role (available under Web Server (IIS) / Management Tools).
2. Using Internet Information Services (IIS) Manager, expand the **MDT01 (CONTOSO\\Administrator)** node. If prompted with the "Do you want to get started with Microsoft Web Platform?" question, select the **Do not show this message** check box and then click **No**.
3. Right-click **Application Pools**, select **Add Application Pool**, and configure the new application pool with the following settings:
1. Name: MDTSample
2. .NET Framework version: .NET Framework 4.0.30319
3. Manage pipeline mode: Integrated
4. Select the **Start application pool immediately** check box.
5. Click **OK**.
![figure 16](../images/mdt-09-fig16.png)
Figure 16. The new MDTSample application.
## <a href="" id="sec03"></a>Install the web service
1. On MDT01, using Internet Information Services (IIS) Manager, expand **Sites**, right-click **Default Web Site**, and select **Add Application**. Use the following settings for the application:
1. Alias: MDTSample
2. Application pool: MDTSample
3. Physical Path: E:\\MDTSample
![figure 17](../images/mdt-09-fig17.png)
Figure 17. Adding the MDTSample web application.
2. In the **Default Web Site** node, select the MDTSample web application, and in the right pane, double-click **Authentication**. Use the following settings for the **Authentication** dialog box:
1. Anonymous Authentication: Enabled
2. ASP.NET Impersonation: Disabled
![figure 18](../images/mdt-09-fig18.png)
Figure 18. Configuring Authentication for the MDTSample web service.
## <a href="" id="sec04"></a>Test the web service in Internet Explorer
1. On PC0001, using Internet Explorer, navigate to: **http://MDT01/MDTSample/mdtsample.asmx**.
2. Click the **GetComputerName** link.
![figure 19](../images/mdt-09-fig19.png)
Figure 19. The MDT Sample web service.
3. On the **GetComputerName** page, type in the following settings, and click **Invoke**:
1. Model: Hewlett-Packard
2. SerialNumber: 123456789
![figure 20](../images/mdt-09-fig20.png)
Figure 20. The result from the MDT Sample web service.
## <a href="" id="sec05"></a>Test the web service in the MDT simulation environment
After verifying the web service using Internet Explorer, you are ready to do the same test in the MDT simulation environment.
1. On PC0001, edit the CustomSettings.ini file in the **C:\\MDT** folder to look like the following:
``` syntax
[Settings]
Priority=Default, GetComputerName
[Default]
OSInstall=YES
[GetComputerName]
WebService=http://mdt01/MDTSample/mdtsample.asmx/GetComputerName
Parameters=Model,SerialNumber
OSDComputerName=string
```
![figure 21](../images/mdt-09-fig21.png)
Figure 21. The updated CustomSettings.ini file.
2. Save the CustomSettings.ini file.
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press **Enter** after each command:
``` syntax
Set-Location C:\MDT
.\Gather.ps1
```
4. Review the ZTIGather.log in the **C:\\MININT\\SMSOSD\\OSDLOGS** folder.
![figure 22](../images/mdt-09-fig22.png)
Figure 22. The OSDCOMPUTERNAME value obtained from the web service.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
---
title: Use web services in MDT (Windows 10)
description: In this topic, you will learn how to create a simple web service that generates computer names and then configure MDT to use that service during your Windows 10 deployment.
ms.assetid: 8f47535e-0551-4ccb-8f02-bb97539c6522
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: deploy, web apps
ms.prod: w10
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.pagetype: mdt
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Use web services in MDT
In this topic, you will learn how to create a simple web service that generates computer names and then configure MDT to use that service during your Windows 10 deployment. Web services provide a powerful way to assign settings during a deployment. Simply put, web services are web applications that run code on the server side, and MDT has built-in functions to call these web services.
Using a web service in MDT is straightforward, but it does require that you have enabled the Web Server (IIS) role on the server. Developing web services involves a little bit of coding, but for most web services used with MDT, you can use the free Microsoft Visual Studio Express 2013 for Web.
## <a href="" id="sec01"></a>Create a sample web service
In these steps we assume you have installed Microsoft Visual Studio Express 2013 for Web on PC0001 (the Windows 10 client) and downloaded the [MDT Sample Web Service](https://go.microsoft.com/fwlink/p/?LinkId=619363) from the Microsoft Download Center and extracted it to C:\\Projects.
1. On PC0001, using Visual Studio Express 2013 for Web, open the C:\\Projects\\MDTSample\\ MDTSample.sln solution file.
2. On the ribbon bar, verify that Release is selected.
3. In the **Debug** menu, select the **Build MDTSample** action.
4. On MDT01, create a folder structure for **E:\\MDTSample\\bin**.
5. From PC0001, copy the C:\\Projects\\MDTSample\\obj\\Release\\MDTSample.dll file to the **E:\\MDTSample\\bin** folder on MDT01.
6. From PC0001, copy the following files from C:\\Projects\\MDTSample file to the **E:\\MDTSample** folder on MDT01:
1. Web.config
2. mdtsample.asmx
![figure 15](../images/mdt-09-fig15.png)
Figure 15. The sample project in Microsoft Visual Studio Express 2013 for Web.
## <a href="" id="sec02"></a>Create an application pool for the web service
This section assumes that you have enabled the Web Server (IIS) role on MDT01.
1. On MDT01, using Server Manager, install the **IIS Management Console** role (available under Web Server (IIS) / Management Tools).
2. Using Internet Information Services (IIS) Manager, expand the **MDT01 (CONTOSO\\Administrator)** node. If prompted with the "Do you want to get started with Microsoft Web Platform?" question, select the **Do not show this message** check box and then click **No**.
3. Right-click **Application Pools**, select **Add Application Pool**, and configure the new application pool with the following settings:
1. Name: MDTSample
2. .NET Framework version: .NET Framework 4.0.30319
3. Manage pipeline mode: Integrated
4. Select the **Start application pool immediately** check box.
5. Click **OK**.
![figure 16](../images/mdt-09-fig16.png)
Figure 16. The new MDTSample application.
## <a href="" id="sec03"></a>Install the web service
1. On MDT01, using Internet Information Services (IIS) Manager, expand **Sites**, right-click **Default Web Site**, and select **Add Application**. Use the following settings for the application:
1. Alias: MDTSample
2. Application pool: MDTSample
3. Physical Path: E:\\MDTSample
![figure 17](../images/mdt-09-fig17.png)
Figure 17. Adding the MDTSample web application.
2. In the **Default Web Site** node, select the MDTSample web application, and in the right pane, double-click **Authentication**. Use the following settings for the **Authentication** dialog box:
1. Anonymous Authentication: Enabled
2. ASP.NET Impersonation: Disabled
![figure 18](../images/mdt-09-fig18.png)
Figure 18. Configuring Authentication for the MDTSample web service.
## <a href="" id="sec04"></a>Test the web service in Internet Explorer
1. On PC0001, using Internet Explorer, navigate to: **http://MDT01/MDTSample/mdtsample.asmx**.
2. Click the **GetComputerName** link.
![figure 19](../images/mdt-09-fig19.png)
Figure 19. The MDT Sample web service.
3. On the **GetComputerName** page, type in the following settings, and click **Invoke**:
1. Model: Hewlett-Packard
2. SerialNumber: 123456789
![figure 20](../images/mdt-09-fig20.png)
Figure 20. The result from the MDT Sample web service.
## <a href="" id="sec05"></a>Test the web service in the MDT simulation environment
After verifying the web service using Internet Explorer, you are ready to do the same test in the MDT simulation environment.
1. On PC0001, edit the CustomSettings.ini file in the **C:\\MDT** folder to look like the following:
```
[Settings]
Priority=Default, GetComputerName
[Default]
OSInstall=YES
[GetComputerName]
WebService=http://mdt01/MDTSample/mdtsample.asmx/GetComputerName
Parameters=Model,SerialNumber
OSDComputerName=string
```
![figure 21](../images/mdt-09-fig21.png)
Figure 21. The updated CustomSettings.ini file.
2. Save the CustomSettings.ini file.
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press **Enter** after each command:
```
Set-Location C:\MDT
.\Gather.ps1
```
4. Review the ZTIGather.log in the **C:\\MININT\\SMSOSD\\OSDLOGS** folder.
![figure 22](../images/mdt-09-fig22.png)
Figure 22. The OSDCOMPUTERNAME value obtained from the web service.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)

387
windows/deployment/deploy-windows-sccm/finalize-the-os-configuration-for-windows-10-deployment-with-configuration-manager.md
View File

@ -1,193 +1,194 @@
---
title: Finalize the operating system configuration for Windows 10 deployment with Configuration Manager (Windows 10)
description: This topic walks you through the steps to finalize the configuration of your Windows 10 operating deployment, which includes enablement of the optional Microsoft Deployment Toolkit (MDT) monitoring for Microsoft System Center 2012 R2 Configuration Manager, logs folder creation, rules configuration, content distribution, and deployment of the previously created task sequence.
ms.assetid: 38b55fa8-e717-4689-bd43-8348751d493e
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: configure, deploy, upgrade
ms.prod: w10
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.topic: article
---
# Finalize the operating system configuration for Windows 10 deployment with Configuration Manager
**Applies to**
- Windows 10 versions 1507, 1511
>[!IMPORTANT]
>For instructions to deploy the most recent version of Windows 10 with Configuration Manager, see [Scenarios to deploy enterprise operating systems with System Center Configuration Manager](https://docs.microsoft.com/sccm/osd/deploy-use/scenarios-to-deploy-enterprise-operating-systems).
>Configuration Manager 2012 and 2012 R2 provide support for Windows 10 versions 1507 and 1511 only. Later versions of Windows 10 require an updated Configuration Manager release. For a list of Configuration Manager versions and the corresponding Windows 10 client versions that are supported, see [Support for Windows 10 for System Center Configuration Manager](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10).
This topic walks you through the steps to finalize the configuration of your Windows 10 operating deployment, which includes enablement of the optional Microsoft Deployment Toolkit (MDT) monitoring for Microsoft System Center 2012 R2 Configuration Manager, logs folder creation, rules configuration, content distribution, and deployment of the previously created task sequence.
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. Both are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](../deploy-windows-mdt/deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
## <a href="" id="sec01"></a>Enable MDT monitoring
This section will walk you through the process of creating the E:\\MDTProduction deployment share using the MDT Deployment Workbench to enable monitoring for Configuration Manager.
1. On CM01, using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**. Use the following settings for the New Deployment Share Wizard:
* Deployment share path: E:\\MDTProduction
* Share name: MDTProduction$
* Deployment share description: MDT Production
* Options: &lt;default settings&gt;
2. Right-click the **MDT Production** deployment share, and select **Properties**. In the **Monitoring** tab, select the **Enable monitoring for this deployment share** check box, and click **OK**.
![Enable MDT monitoring for Configuration Manager](../images/mdt-06-fig31.png)
*Figure 26. Enable MDT monitoring for Configuration Manager*
## <a href="" id="sec02"></a>Create and share the Logs folder
To support additional server-side logging in Configuration Manager, you create and share the E:\\Logs folder on CM01 using Windows PowerShell. Then in the next step, you enable server-side logging by modifying the CustomSettings.ini file used by the Configuration Manager task sequence.
1. On CM01, start an elevated Windows PowerShell prompt (run as Administrator).
2. Type the following commands, pressing **Enter** after each one:
``` syntax
New-Item -Path E:\Logs -ItemType directory
New-SmbShare -Name Logs$ -Path E:\Logs -ChangeAccess EVERYONE
icacls E:\Logs /grant '"CM_NAA":(OI)(CI)(M)'
```
## <a href="" id="sec03"></a>Configure the rules (Windows 10 x64 Settings package)
This section will show you how to configure the rules (the Windows 10 x64 Settings package) to support the Contoso environment.
1. On CM01, using File Explorer, navigate to the **E:\\Sources\\OSD\\Settings\\Windows 10 x64 Settings** folder.
2. Using Notepad, edit the CustomSetting.ini file with the following settings:
``` syntax
[Settings]
Priority=Default
Properties=OSDMigrateConfigFiles,OSDMigrateMode
[Default]
DoCapture=NO
ComputerBackupLocation=NONE
MachineObjectOU=ou=Workstations,ou=Computers,ou=Contoso,dc=contoso,dc=com
OSDMigrateMode=Advanced
OSDMigrateAdditionalCaptureOptions=/ue:*\* /ui:CONTOSO\*
OSDMigrateConfigFiles=Miguser.xml,Migapp.xml
SLSHARE=\\CM01\Logs$
EventService=http://CM01:9800
ApplyGPOPack=NO
```
![Settings package during deployment](../images/fig30-settingspack.png)
*Figure 27. The Settings package, holding the rules and the Unattend.xml template used during deployment*
3. Update the distribution point for the **Windows 10 x64 Settings** package by right-clicking the **Windows 10 x64 Settings** package and selecting **Update Distribution Points**.
>[!NOTE]
>Although you have not yet added a distribution point, you still need to select Update Distribution Points. That process also updates the Configuration Manager 2012 content library with changes.
## <a href="" id="sec04"></a>Distribute content to the CM01 distribution portal
In Configuration Manager, you can distribute all packages needed by a task sequence in a single task. In this section, you distribute packages that have not yet been distributed to the CM01 distribution point.
1. **On CM01, using the Configuration Manager Console**, select **Task Sequences**, right-click the **Windows 10 Enterprise x64 RTM** task sequence, and select **Distribute Content.**
2. In the Distribute Content Wizard, add the CM01 distribution point, and complete the wizard.
3. Using Configuration Manager Trace, verify the distribution to the CM01 distribution point by reviewing the distmgr.log file, or use the Distribution Status / Content Status option in the Monitoring workspace. Do not continue until you see all the new packages being distributed successfully.
## <a href="" id="sec05"></a>Create a deployment for the task sequence
This sections provides steps to help you create a deployment for the task sequence.
1. On CM01, using the Configuration Manager Console, select **Task Sequences**, right-click **Windows 10 Enterprise x64 RTM**, and then select **Deploy**.
2. On the **General** page, select the **All Unknown Computers** collection and click **Next**.
3. On the **Deployment Settings** page, use the following settings and then click **Next**:
* Purpose: Available
* Make available to the following: Only media and PXE
![Configure the deployment settings](../images/mdt-06-fig33.png)
*Figure 28. Configure the deployment settings*
4. On the **Scheduling** page, accept the default settings and click **Next**.
5. On the **User Experience** page, accept the default settings and click **Next**.
6. On the **Alerts** page, accept the default settings and click **Next**.
7. On the **Distribution Points** page, accept the default settings, click **Next** twice, and then click **Close**.
![Task sequence deployed](../images/fig32-deploywiz.png)
*Figure 29. The Windows 10 Enterprise x64 RTM task sequence deployed to the All Unknown Computers collections available for media and PXE*
## <a href="" id="sec06"></a>Configure Configuration Manager to prompt for the computer name during deployment (optional)
You can have Configuration Manager prompt you for a computer name or you can use rules to generate a computer name. For more details on how to do this, see [Configure MDT settings](../deploy-windows-mdt/configure-mdt-settings.md).
This section provides steps to help you configure the All Unknown Computers collection to have Configuration Manager prompt for computer names.
1. Using the Configuration Manager Console, in the Asset and Compliance workspace, select **Device Collections**, right-click **All Unknown Computers**, and select **Properties**.
2. In the **Collection Variables** tab, create a new variable with the following settings:
* Name: OSDComputerName
* Clear the **Do not display this value in the Configuration Manager console** check box.
3. Click **OK**.
>[!NOTE]
>Configuration Manager can prompt for information in many ways. Using a collection variable with an empty value is just one of them. Another option is the User-Driven Installation (UDI) wizard.
![Configure a collection variable](../images/mdt-06-fig35.png)
*Figure 30. Configure a collection variable*
## Related topics
[Integrate Configuration Manager with MDT](../deploy-windows-mdt/integrate-configuration-manager-with-mdt.md)
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
[Create a task sequence with Configuration Manager and MDT](../deploy-windows-mdt/create-a-task-sequence-with-configuration-manager-and-mdt.md)
[Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md)
---
title: Finalize the operating system configuration for Windows 10 deployment with Configuration Manager (Windows 10)
description: This topic walks you through the steps to finalize the configuration of your Windows 10 operating deployment, which includes enablement of the optional Microsoft Deployment Toolkit (MDT) monitoring for Microsoft System Center 2012 R2 Configuration Manager, logs folder creation, rules configuration, content distribution, and deployment of the previously created task sequence.
ms.assetid: 38b55fa8-e717-4689-bd43-8348751d493e
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: configure, deploy, upgrade
ms.prod: w10
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Finalize the operating system configuration for Windows 10 deployment with Configuration Manager
**Applies to**
- Windows 10 versions 1507, 1511
>[!IMPORTANT]
>For instructions to deploy the most recent version of Windows 10 with Configuration Manager, see [Scenarios to deploy enterprise operating systems with System Center Configuration Manager](https://docs.microsoft.com/sccm/osd/deploy-use/scenarios-to-deploy-enterprise-operating-systems).
>Configuration Manager 2012 and 2012 R2 provide support for Windows 10 versions 1507 and 1511 only. Later versions of Windows 10 require an updated Configuration Manager release. For a list of Configuration Manager versions and the corresponding Windows 10 client versions that are supported, see [Support for Windows 10 for System Center Configuration Manager](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10).
This topic walks you through the steps to finalize the configuration of your Windows 10 operating deployment, which includes enablement of the optional Microsoft Deployment Toolkit (MDT) monitoring for Microsoft System Center 2012 R2 Configuration Manager, logs folder creation, rules configuration, content distribution, and deployment of the previously created task sequence.
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. Both are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](../deploy-windows-mdt/deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
## <a href="" id="sec01"></a>Enable MDT monitoring
This section will walk you through the process of creating the E:\\MDTProduction deployment share using the MDT Deployment Workbench to enable monitoring for Configuration Manager.
1. On CM01, using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**. Use the following settings for the New Deployment Share Wizard:
* Deployment share path: E:\\MDTProduction
* Share name: MDTProduction$
* Deployment share description: MDT Production
* Options: &lt;default settings&gt;
2. Right-click the **MDT Production** deployment share, and select **Properties**. In the **Monitoring** tab, select the **Enable monitoring for this deployment share** check box, and click **OK**.
![Enable MDT monitoring for Configuration Manager](../images/mdt-06-fig31.png)
*Figure 26. Enable MDT monitoring for Configuration Manager*
## <a href="" id="sec02"></a>Create and share the Logs folder
To support additional server-side logging in Configuration Manager, you create and share the E:\\Logs folder on CM01 using Windows PowerShell. Then in the next step, you enable server-side logging by modifying the CustomSettings.ini file used by the Configuration Manager task sequence.
1. On CM01, start an elevated Windows PowerShell prompt (run as Administrator).
2. Type the following commands, pressing **Enter** after each one:
```
New-Item -Path E:\Logs -ItemType directory
New-SmbShare -Name Logs$ -Path E:\Logs -ChangeAccess EVERYONE
icacls E:\Logs /grant '"CM_NAA":(OI)(CI)(M)'
```
## <a href="" id="sec03"></a>Configure the rules (Windows 10 x64 Settings package)
This section will show you how to configure the rules (the Windows 10 x64 Settings package) to support the Contoso environment.
1. On CM01, using File Explorer, navigate to the **E:\\Sources\\OSD\\Settings\\Windows 10 x64 Settings** folder.
2. Using Notepad, edit the CustomSetting.ini file with the following settings:
```
[Settings]
Priority=Default
Properties=OSDMigrateConfigFiles,OSDMigrateMode
[Default]
DoCapture=NO
ComputerBackupLocation=NONE
MachineObjectOU=ou=Workstations,ou=Computers,ou=Contoso,dc=contoso,dc=com
OSDMigrateMode=Advanced
OSDMigrateAdditionalCaptureOptions=/ue:*\* /ui:CONTOSO\*
OSDMigrateConfigFiles=Miguser.xml,Migapp.xml
SLSHARE=\\CM01\Logs$
EventService=http://CM01:9800
ApplyGPOPack=NO
```
![Settings package during deployment](../images/fig30-settingspack.png)
*Figure 27. The Settings package, holding the rules and the Unattend.xml template used during deployment*
3. Update the distribution point for the **Windows 10 x64 Settings** package by right-clicking the **Windows 10 x64 Settings** package and selecting **Update Distribution Points**.
>[!NOTE]
>Although you have not yet added a distribution point, you still need to select Update Distribution Points. That process also updates the Configuration Manager 2012 content library with changes.
## <a href="" id="sec04"></a>Distribute content to the CM01 distribution portal
In Configuration Manager, you can distribute all packages needed by a task sequence in a single task. In this section, you distribute packages that have not yet been distributed to the CM01 distribution point.
1. **On CM01, using the Configuration Manager Console**, select **Task Sequences**, right-click the **Windows 10 Enterprise x64 RTM** task sequence, and select **Distribute Content.**
2. In the Distribute Content Wizard, add the CM01 distribution point, and complete the wizard.
3. Using Configuration Manager Trace, verify the distribution to the CM01 distribution point by reviewing the distmgr.log file, or use the Distribution Status / Content Status option in the Monitoring workspace. Do not continue until you see all the new packages being distributed successfully.
## <a href="" id="sec05"></a>Create a deployment for the task sequence
This sections provides steps to help you create a deployment for the task sequence.
1. On CM01, using the Configuration Manager Console, select **Task Sequences**, right-click **Windows 10 Enterprise x64 RTM**, and then select **Deploy**.
2. On the **General** page, select the **All Unknown Computers** collection and click **Next**.
3. On the **Deployment Settings** page, use the following settings and then click **Next**:
* Purpose: Available
* Make available to the following: Only media and PXE
![Configure the deployment settings](../images/mdt-06-fig33.png)
*Figure 28. Configure the deployment settings*
4. On the **Scheduling** page, accept the default settings and click **Next**.
5. On the **User Experience** page, accept the default settings and click **Next**.
6. On the **Alerts** page, accept the default settings and click **Next**.
7. On the **Distribution Points** page, accept the default settings, click **Next** twice, and then click **Close**.
![Task sequence deployed](../images/fig32-deploywiz.png)
*Figure 29. The Windows 10 Enterprise x64 RTM task sequence deployed to the All Unknown Computers collections available for media and PXE*
## <a href="" id="sec06"></a>Configure Configuration Manager to prompt for the computer name during deployment (optional)
You can have Configuration Manager prompt you for a computer name or you can use rules to generate a computer name. For more details on how to do this, see [Configure MDT settings](../deploy-windows-mdt/configure-mdt-settings.md).
This section provides steps to help you configure the All Unknown Computers collection to have Configuration Manager prompt for computer names.
1. Using the Configuration Manager Console, in the Asset and Compliance workspace, select **Device Collections**, right-click **All Unknown Computers**, and select **Properties**.
2. In the **Collection Variables** tab, create a new variable with the following settings:
* Name: OSDComputerName
* Clear the **Do not display this value in the Configuration Manager console** check box.
3. Click **OK**.
>[!NOTE]
>Configuration Manager can prompt for information in many ways. Using a collection variable with an empty value is just one of them. Another option is the User-Driven Installation (UDI) wizard.
![Configure a collection variable](../images/mdt-06-fig35.png)
*Figure 30. Configure a collection variable*
## Related topics
[Integrate Configuration Manager with MDT](../deploy-windows-mdt/integrate-configuration-manager-with-mdt.md)
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
[Create a task sequence with Configuration Manager and MDT](../deploy-windows-mdt/create-a-task-sequence-with-configuration-manager-and-mdt.md)
[Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md)

569
windows/deployment/deploy-windows-sccm/prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md
View File

@ -1,284 +1,285 @@
---
title: Prepare for Zero Touch Installation of Windows 10 with Configuration Manager (Windows 10)
description: This topic will walk you through the process of integrating Microsoft System Center 2012 R2 Configuration Manager SP1 with Microsoft Deployment Toolkit (MDT) 2013 Update 2, as well as the other preparations needed to deploying Windows 10 via Zero Touch Installation. Additional preparations include the installation of hotfixes as well as activities that speed up the Pre-Boot Execution Environment (PXE).
ms.assetid: 06e3a221-31ef-47a5-b4da-3b927cb50d08
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: install, configure, deploy, deployment
ms.prod: w10
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.topic: article
---
# Prepare for Zero Touch Installation of Windows 10 with Configuration Manager
**Applies to**
- Windows 10 versions 1507, 1511
>[!IMPORTANT]
>For instructions to deploy the most recent version of Windows 10 with Configuration Manager, see [Scenarios to deploy enterprise operating systems with System Center Configuration Manager](https://docs.microsoft.com/sccm/osd/deploy-use/scenarios-to-deploy-enterprise-operating-systems).
>Configuration Manager 2012 and 2012 R2 provide support for Windows 10 versions 1507 and 1511 only. Later versions of Windows 10 require an updated Configuration Manager release. For a list of Configuration Manager versions and the corresponding Windows 10 client versions that are supported, see [Support for Windows 10 for System Center Configuration Manager](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10).
This topic will walk you through the process of integrating Microsoft System Center 2012 R2 Configuration Manager SP1 with Microsoft Deployment Toolkit (MDT) 2013 Update 2, as well as the other preparations needed to deploying Windows 10 via Zero Touch Installation. Additional preparations include the installation of hotfixes as well as activities that speed up the Pre-Boot Execution Environment (PXE).
## Prerequisites
In this topic, you will use an existing Configuration Manager server structure to prepare for operating system deployment. In addition to the base setup, the following configurations should be made in the Configuration Manager environment:
- Active Directory Schema has been extended and System Management container created.
- Active Directory Forest Discovery and Active Directory System Discovery have been enabled.
- IP range boundaries and a boundary group for content and site assignment have been created.
- The Configuration Manager reporting services point role has been added and configured
- A file system folder structure for packages has been created.
- A Configuration Manager console folder structure for packages has been created.
- System Center 2012 R2 Configuration Manager SP1 and any additional Windows 10 prerequisites are installed.
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. DC01 and CM01 are both members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](../deploy-windows-mdt/deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
## <a href="" id="sec01"></a>Create the Configuration Manager service accounts
To configure permissions for the various service accounts needed for operating system deployment in Configuration Manager, you use a role-based model. To create the Configuration Manager Join Domain account as well as the Configuration Manager Network Access account, follow these steps:
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
2. Select the Service Accounts OU and create the CM\_JD account using the following settings:
* Name: CM\_JD
* User logon name: CM\_JD
* Password: P@ssw0rd
* User must change password at next logon: Clear
* User cannot change password: Select
* Password never expires: Select
3. Repeat the step, but for the CM\_NAA account.
4. After creating the accounts, assign the following descriptions:
* CM\_JD: Configuration Manager Join Domain Account
* CM\_NAA: Configuration Manager Network Access Account
![figure 6](../images/mdt-06-fig06.png)
Figure 6. The Configuration Manager service accounts used for operating system deployment.
## <a href="" id="sec02"></a>Configure Active Directory permissions
In order for the Configuration Manager Join Domain Account (CM\_JD) to join machines into the contoso.com domain you need to configure permissions in Active Directory. These steps assume you have downloaded the sample [Set-OUPermissions.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619362) and copied it to C:\\Setup\\Scripts on DC01.
1. On DC01, log on as Administrator in the CONTOSO domain using the password <strong>P@ssw0rd</strong>.
2. In an elevated Windows PowerShell prompt (run as Administrator), run the following commands, pressing **Enter** after each command:
``` syntax
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
Set-Location C:\Setup\Scripts
.\Set-OUPermissions.ps1 -Account CM_JD
-TargetOU "OU=Workstations,OU=Computers,OU=Contoso"
```
3. The Set-OUPermissions.ps1 script allows the CM\_JD user account permissions to manage computer accounts in the Contoso / Computers / Workstations OU. The following is a list of the permissions being granted:
* Scope: This object and all descendant objects
* Create Computer objects
* Delete Computer objects
* Scope: Descendant Computer objects
* Read All Properties
* Write All Properties
* Read Permissions
* Modify Permissions
* Change Password
* Reset Password
* Validated write to DNS host name
* Validated write to service principal name
## <a href="" id="sec03"></a>Review the Sources folder structure
To support the packages you create in this section, the following folder structure should be created on the Configuration Manager primary site server (CM01):
>[!NOTE]
>In most production environments, the packages are stored on a Distributed File System (DFS) share or a "normal" server share, but in a lab environment you can store them on the site server.
- E:\\Sources
- E:\\Sources\\OSD
- E:\\Sources\\OSD\\Boot
- E:\\Sources\\OSD\\DriverPackages
- E:\\Sources\\OSD\\DriverSources
- E:\\Sources\\OSD\\MDT
- E:\\Sources\\OSD\\OS
- E:\\Sources\\OSD\\Settings
- E:\\Sources\\Software
- E:\\Sources\\Software\\Adobe
- E:\\Sources\\Software\\Microsoft
![figure 7](../images/mdt-06-fig07.png)
Figure 7. The E:\\Sources\\OSD folder structure.
## <a href="" id="sec04"></a>Integrate Configuration Manager with MDT
To extend the Configuration Manager console with MDT wizards and templates, you install MDT in the default location and run the integration setup. In these steps, we assume you have downloaded MDT to the C:\\Setup\\MDT2013 folder on CM01.
1. On CM01, log on as Administrator in the CONTOSO domain using the password <strong>P@ssw0rd</strong>.
2. Make sure the Configuration Manager Console is closed before continuing.
3. Using File Explorer, navigate to the **C:\\Setup\\MDT** folder.
4. Run the MDT setup (MicrosoftDeploymentToolkit2013\_x64.msi), and use the default options in the setup wizard.
5. From the Start screen, run Configure ConfigManager Integration with the following settings:
* Site Server Name: CM01.contoso.com
* Site code: PS1
![figure 8](../images/mdt-06-fig08.png)
Figure 8. Set up the MDT integration with Configuration Manager.
## <a href="" id="sec06"></a>Configure the client settings
Most organizations want to display their name during deployment. In this section, you configure the default Configuration Manager client settings with the Contoso organization name.
1. On CM01, using the Configuration Manager Console, in the Administration workspace, select **Client Settings**.
2. In the right pane, right-click **Default Client Settings**, and select **Properties**.
3. In the **Computer Agent** node, in the **Organization name displayed in Software Center** text box, type in **Contoso** and click **OK**.
![figure 9](../images/mdt-06-fig10.png)
Figure 9. Configure the organization name in client settings.
![figure 10](../images/fig10-contosoinstall.png)
Figure 10. The Contoso organization name displayed during deployment.
## <a href="" id="sec07"></a>Configure the Network Access account
Configuration Manager uses the Network Access account during the Windows 10 deployment process to access content on the distribution point(s). In this section, you configure the Network Access account.
1. Using the Configuration Manager Console, in the Administration workspace, expand **Site Configuration** and select **Sites**.
2. Right-click **PS1 - Primary Site 1**, select **Configure Site Components**, and then select **Software Distribution**.
3. In the **Network Access Account** tab, configure the **CONTOSO\\CM\_NAA** user account (select New Account) as the Network Access account. Use the new **Verify** option to verify that the account can connect to the **\\\\DC01\\sysvol** network share.
![figure 11](../images/mdt-06-fig12.png)
Figure 11. Test the connection for the Network Access account.
## <a href="" id="sec08"></a>Enable PXE on the CM01 distribution point
Configuration Manager has many options for starting a deployment, but starting via PXE is certainly the most flexible in a large environment. In this section, you enable PXE on the CM01 distribution point.
1. In the Configuration Manager Console, in the Administration workspace, select **Distribution Points**.
2. Right-click the **\\\\CM01.CONTOSO.COM distribution point** and select **Properties**.
3. In the **PXE** tab, select the following settings:
* Enable PXE support for clients
* Allow this distribution point to respond to incoming PXE requests
* Enable unknown computer support
* Require a password when computers use PXE
* Password and Confirm password: Passw0rd!
![figure 12](../images/mdt-06-fig13.png)
Figure 12. Configure the CM01 distribution point for PXE.
4. Using the Configuration Manager Trace Log Tool, review the E:\\Program Files\\Microsoft Configuration Manager\\Logs\\distmgr.log file. Look for ConfigurePXE and CcmInstallPXE lines.
![figure 13](../images/mdt-06-fig14.png)
Figure 13. The distmgr.log displays a successful configuration of PXE on the distribution point.
5. Verify that you have seven files in each of the folders **E:\\RemoteInstall\\SMSBoot\\x86** and **E:\\RemoteInstall\\SMSBoot\\x64**.
![figure 14](../images/mdt-06-fig15.png)
Figure 14. The contents of the E:\\RemoteInstall\\SMSBoot\\x64 folder after you enable PXE.
## Related topics
[Integrate Configuration Manager with MDT](../deploy-windows-mdt/integrate-configuration-manager-with-mdt.md)
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
[Create a task sequence with Configuration Manager and MDT](../deploy-windows-mdt/create-a-task-sequence-with-configuration-manager-and-mdt.md)
[Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md)
---
title: Prepare for Zero Touch Installation of Windows 10 with Configuration Manager (Windows 10)
description: This topic will walk you through the process of integrating Microsoft System Center 2012 R2 Configuration Manager SP1 with Microsoft Deployment Toolkit (MDT) 2013 Update 2, as well as the other preparations needed to deploying Windows 10 via Zero Touch Installation. Additional preparations include the installation of hotfixes as well as activities that speed up the Pre-Boot Execution Environment (PXE).
ms.assetid: 06e3a221-31ef-47a5-b4da-3b927cb50d08
ms.reviewer:
manager: laurawi
ms.author: greglin
keywords: install, configure, deploy, deployment
ms.prod: w10
ms.localizationpriority: medium
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Prepare for Zero Touch Installation of Windows 10 with Configuration Manager
**Applies to**
- Windows 10 versions 1507, 1511
>[!IMPORTANT]
>For instructions to deploy the most recent version of Windows 10 with Configuration Manager, see [Scenarios to deploy enterprise operating systems with System Center Configuration Manager](https://docs.microsoft.com/sccm/osd/deploy-use/scenarios-to-deploy-enterprise-operating-systems).
>Configuration Manager 2012 and 2012 R2 provide support for Windows 10 versions 1507 and 1511 only. Later versions of Windows 10 require an updated Configuration Manager release. For a list of Configuration Manager versions and the corresponding Windows 10 client versions that are supported, see [Support for Windows 10 for System Center Configuration Manager](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10).
This topic will walk you through the process of integrating Microsoft System Center 2012 R2 Configuration Manager SP1 with Microsoft Deployment Toolkit (MDT) 2013 Update 2, as well as the other preparations needed to deploying Windows 10 via Zero Touch Installation. Additional preparations include the installation of hotfixes as well as activities that speed up the Pre-Boot Execution Environment (PXE).
## Prerequisites
In this topic, you will use an existing Configuration Manager server structure to prepare for operating system deployment. In addition to the base setup, the following configurations should be made in the Configuration Manager environment:
- Active Directory Schema has been extended and System Management container created.
- Active Directory Forest Discovery and Active Directory System Discovery have been enabled.
- IP range boundaries and a boundary group for content and site assignment have been created.
- The Configuration Manager reporting services point role has been added and configured
- A file system folder structure for packages has been created.
- A Configuration Manager console folder structure for packages has been created.
- System Center 2012 R2 Configuration Manager SP1 and any additional Windows 10 prerequisites are installed.
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. DC01 and CM01 are both members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](../deploy-windows-mdt/deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
## <a href="" id="sec01"></a>Create the Configuration Manager service accounts
To configure permissions for the various service accounts needed for operating system deployment in Configuration Manager, you use a role-based model. To create the Configuration Manager Join Domain account as well as the Configuration Manager Network Access account, follow these steps:
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
2. Select the Service Accounts OU and create the CM\_JD account using the following settings:
* Name: CM\_JD
* User logon name: CM\_JD
* Password: P@ssw0rd
* User must change password at next logon: Clear
* User cannot change password: Select
* Password never expires: Select
3. Repeat the step, but for the CM\_NAA account.
4. After creating the accounts, assign the following descriptions:
* CM\_JD: Configuration Manager Join Domain Account
* CM\_NAA: Configuration Manager Network Access Account
![figure 6](../images/mdt-06-fig06.png)
Figure 6. The Configuration Manager service accounts used for operating system deployment.
## <a href="" id="sec02"></a>Configure Active Directory permissions
In order for the Configuration Manager Join Domain Account (CM\_JD) to join machines into the contoso.com domain you need to configure permissions in Active Directory. These steps assume you have downloaded the sample [Set-OUPermissions.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619362) and copied it to C:\\Setup\\Scripts on DC01.
1. On DC01, log on as Administrator in the CONTOSO domain using the password <strong>P@ssw0rd</strong>.
2. In an elevated Windows PowerShell prompt (run as Administrator), run the following commands, pressing **Enter** after each command:
```
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
Set-Location C:\Setup\Scripts
.\Set-OUPermissions.ps1 -Account CM_JD
-TargetOU "OU=Workstations,OU=Computers,OU=Contoso"
```
3. The Set-OUPermissions.ps1 script allows the CM\_JD user account permissions to manage computer accounts in the Contoso / Computers / Workstations OU. The following is a list of the permissions being granted:
* Scope: This object and all descendant objects
* Create Computer objects
* Delete Computer objects
* Scope: Descendant Computer objects
* Read All Properties
* Write All Properties
* Read Permissions
* Modify Permissions
* Change Password
* Reset Password
* Validated write to DNS host name
* Validated write to service principal name
## <a href="" id="sec03"></a>Review the Sources folder structure
To support the packages you create in this section, the following folder structure should be created on the Configuration Manager primary site server (CM01):
>[!NOTE]
>In most production environments, the packages are stored on a Distributed File System (DFS) share or a "normal" server share, but in a lab environment you can store them on the site server.
- E:\\Sources
- E:\\Sources\\OSD
- E:\\Sources\\OSD\\Boot
- E:\\Sources\\OSD\\DriverPackages
- E:\\Sources\\OSD\\DriverSources
- E:\\Sources\\OSD\\MDT
- E:\\Sources\\OSD\\OS
- E:\\Sources\\OSD\\Settings
- E:\\Sources\\Software
- E:\\Sources\\Software\\Adobe
- E:\\Sources\\Software\\Microsoft
![figure 7](../images/mdt-06-fig07.png)
Figure 7. The E:\\Sources\\OSD folder structure.
## <a href="" id="sec04"></a>Integrate Configuration Manager with MDT
To extend the Configuration Manager console with MDT wizards and templates, you install MDT in the default location and run the integration setup. In these steps, we assume you have downloaded MDT to the C:\\Setup\\MDT2013 folder on CM01.
1. On CM01, log on as Administrator in the CONTOSO domain using the password <strong>P@ssw0rd</strong>.
2. Make sure the Configuration Manager Console is closed before continuing.
3. Using File Explorer, navigate to the **C:\\Setup\\MDT** folder.
4. Run the MDT setup (MicrosoftDeploymentToolkit2013\_x64.msi), and use the default options in the setup wizard.
5. From the Start screen, run Configure ConfigManager Integration with the following settings:
* Site Server Name: CM01.contoso.com
* Site code: PS1
![figure 8](../images/mdt-06-fig08.png)
Figure 8. Set up the MDT integration with Configuration Manager.
## <a href="" id="sec06"></a>Configure the client settings
Most organizations want to display their name during deployment. In this section, you configure the default Configuration Manager client settings with the Contoso organization name.
1. On CM01, using the Configuration Manager Console, in the Administration workspace, select **Client Settings**.
2. In the right pane, right-click **Default Client Settings**, and select **Properties**.
3. In the **Computer Agent** node, in the **Organization name displayed in Software Center** text box, type in **Contoso** and click **OK**.
![figure 9](../images/mdt-06-fig10.png)
Figure 9. Configure the organization name in client settings.
![figure 10](../images/fig10-contosoinstall.png)
Figure 10. The Contoso organization name displayed during deployment.
## <a href="" id="sec07"></a>Configure the Network Access account
Configuration Manager uses the Network Access account during the Windows 10 deployment process to access content on the distribution point(s). In this section, you configure the Network Access account.
1. Using the Configuration Manager Console, in the Administration workspace, expand **Site Configuration** and select **Sites**.
2. Right-click **PS1 - Primary Site 1**, select **Configure Site Components**, and then select **Software Distribution**.
3. In the **Network Access Account** tab, configure the **CONTOSO\\CM\_NAA** user account (select New Account) as the Network Access account. Use the new **Verify** option to verify that the account can connect to the **\\\\DC01\\sysvol** network share.
![figure 11](../images/mdt-06-fig12.png)
Figure 11. Test the connection for the Network Access account.
## <a href="" id="sec08"></a>Enable PXE on the CM01 distribution point
Configuration Manager has many options for starting a deployment, but starting via PXE is certainly the most flexible in a large environment. In this section, you enable PXE on the CM01 distribution point.
1. In the Configuration Manager Console, in the Administration workspace, select **Distribution Points**.
2. Right-click the **\\\\CM01.CONTOSO.COM distribution point** and select **Properties**.
3. In the **PXE** tab, select the following settings:
* Enable PXE support for clients
* Allow this distribution point to respond to incoming PXE requests
* Enable unknown computer support
* Require a password when computers use PXE
* Password and Confirm password: Passw0rd!
![figure 12](../images/mdt-06-fig13.png)
Figure 12. Configure the CM01 distribution point for PXE.
4. Using the Configuration Manager Trace Log Tool, review the E:\\Program Files\\Microsoft Configuration Manager\\Logs\\distmgr.log file. Look for ConfigurePXE and CcmInstallPXE lines.
![figure 13](../images/mdt-06-fig14.png)
Figure 13. The distmgr.log displays a successful configuration of PXE on the distribution point.
5. Verify that you have seven files in each of the folders **E:\\RemoteInstall\\SMSBoot\\x86** and **E:\\RemoteInstall\\SMSBoot\\x64**.
![figure 14](../images/mdt-06-fig15.png)
Figure 14. The contents of the E:\\RemoteInstall\\SMSBoot\\x64 folder after you enable PXE.
## Related topics
[Integrate Configuration Manager with MDT](../deploy-windows-mdt/integrate-configuration-manager-with-mdt.md)
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
[Create a task sequence with Configuration Manager and MDT](../deploy-windows-mdt/create-a-task-sequence-with-configuration-manager-and-mdt.md)
[Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-client-with-windows-10-using-configuration-manager.md)
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md)

2022
windows/deployment/deploy-windows-to-go.md
View File

File diff suppressed because it is too large Load Diff

343
windows/deployment/planning/compatibility-fix-database-management-strategies-and-deployment.md
View File

@ -1,171 +1,172 @@
---
title: Compatibility Fix Database Management Strategies and Deployment (Windows 10)
ms.assetid: fdfbf02f-c4c4-4739-a400-782204fd3c6c
ms.reviewer:
manager: laurawi
ms.author: greglin
description:
ms.prod: w10
ms.mktglfcycl: plan
ms.pagetype: appcompat
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Compatibility Fix Database Management Strategies and Deployment
**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
- Windows 7
- Windows Server 2012
- Windows Server 2008 R2
After you determine that you will use compatibility fixes in your application-compatibility mitigation strategy, you must define a strategy to manage your custom compatibility-fix database. Typically, you can use one of two approaches:
- Deploying your compatibility fixes as part of an application-installation package.
- Deploying your compatibility fixes through a centralized compatibility-fix database.
Regardless of which approach you decide to use in your organization, Microsoft provides the following general recommendations for improving the management of your custom compatibility-fix databases:
- **Define standards for when you will apply compatibility fixes.**
You must define the standards and scenarios for using compatibility fixes, based on your specific business and technology needs.
- **Define standards for your custom compatibility-fix databases.**
You must define how to associate your compatibility fixes to particular applications. For example, you might want to ensure that your compatibility fixes always include a version check, so that a fix will not be applied to newer versions of your applications.
- **Define your resources responsible for addressing questions and enforcing your standards.**
You must determine who will be responsible for staying current with the technology and standards related to your compatibility fixes and custom compatibility-fix databases. As your databases are managed over time, you must ensure that someone in your organization stays current with the relevant technology.
## Strategies for Deploying Your Compatibility Fixes
We recommend that you use one of two strategies to deploy your compatibility fixes into your organization. They are:
- Deploying your compatibility fixes as part of an application-installation package.
- Deploying your compatibility fixes through a centralized compatibility-fix database.
You must determine which method best meets your organization's deployment needs.
### Deploying Fixes as Part of an Application-Installation Package
One strategy for deploying compatibility fixes is to create a custom compatibility-fix database that contains a single entry that is applied directly to the application-installation package. While this is the most straightforward method of deployment, it has been shown that this method can become overly complex, especially if you are fixing a large number of applications.
If the following considerations apply to your organization, you should avoid this strategy and instead consider using a centralized compatibility-fix database, as described in the next section.
- **How many applications require compatibility fixes?**
Custom compatibility-fix databases are actual databases. Therefore, if you have 1000 applications to be fixed, it will take longer to open and query 1000 single-row databases for a match, instead of a single database with 1000 rows.
- **Will you be able to track which applications are installed on which computer?**
You might determine that your initial set of compatibility fixes is not comprehensive, and that you must deploy an updated version of the compatibility-fix database to resolve the additional issues. If you deployed the initial set by using the application-installation package, you will be required to locate each client computer that is running the application and replace the compatibility fix.
### Deploying Fixes Through a Centralized Compatibility-Fix Database
The other recommended strategy for deploying compatibility fixes into your organization is to create and manage either a single custom compatibility-fix database, or else to create and manage several custom databases for large subsets of your organization. This strategy will help to enforce your company policy and to provide consistent updates for application fixes that you discover later.
This approach tends to work best for organizations that have a well-developed deployment infrastructure in place, with centralized ownership of the process. We recommend that you consider the following before using this approach:
- Does your organization have the tools required to deploy and update a compatibility-fix database for all of the effected computers?
If you intend to manage a centralized compatibility-fix database, you must verify that your organization has the required tools to deploy and update all of the affected computers in your organization.
- Do you have centralized resources that can manage and update the centralized compatibility-fix database?
You must ensure that you have identified the appropriate owners for the deployment process, for the applications, and for the database updates, in addition to determining the process by which compatibility issues can be deployed to specific computers.
### Merging Centralized Compatibility-Fix Databases
If you decide to use the centralized compatibility-fix database deployment strategy, you can merge any of your individual compatibility-fix databases. This enables you to create a single custom compatibility-fix database that can be used to search for and determine whether Windows® should apply a fix to a specific executable (.exe) file. We recommend merging your databases based on the following process.
**To merge your custom-compatibility databases**
1. Verify that your application-compatibility testers are performing their tests on computers with the latest version of your compatibility-fix database. For example, Custom DB1.
2. If the tester determines that an application requires an additional compatibility fix that is not a part of the original compatibility-fix database, he or she must create a new custom compatibility database with all of the required information for that single fix. For example, Custom DB2.
3. The tester applies the new Custom DB2 information to the application and then tests for both the functionality and integration, to ensure that the compatibility issues are addressed.
4. After the application passes all of the required functionality and integration tests, the tester can send Custom DB2 to the team that manages the central compatibility-fix database.
5. The team that manages the centralized database opens Custom DB1 and uses the Compatibility Administrator to include the new compatibility fixes that were included in Custom DB2.
**Note**
Custom DB1 contains a unique GUID that makes updating the database easier. For example, if you install a new version of the custom compatibility-fix database that uses the same GUID as the previous version, the computer will automatically uninstall the old version.
6. The centralized management team then redeploys the new version of Custom DB1 to all of the end users in your organization.
### Deploying Your Custom Compatibility-Fix Databases
Deploying your custom compatibility-fix database into your organization requires you to perform the following actions:
1. Store your custom compatibility-fix database (.sdb file) in a location that is accessible to all of your organization’s computers.
2. Use the Sdbinst.exe command-line tool to install the custom compatibility-fix database locally.
In order to meet the two requirements above, we recommend that you use one of the following two methods:
- **Using a Windows Installer package and a custom script**
You can package your .sdb file and a custom deployment script into an .msi file, and then deploy the .msi file into your organization.
**Important**
You must ensure that you mark your custom script so that it does not impersonate the calling user. For example, if you use Microsoft® Visual Basic® Scripting Edition (VBScript), the custom action type would be:
~~~
``` syntax
msidbCustomActionTypeVBScript + msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate = 0x0006 + 0x0400 + 0x0800 = 0x0C06 = 3078 decimal)
```
~~~
- **Using a network share and a custom script**
You can store your .sdb file on your network share and then call to a script that resides on your specified computers.
**Important**
You must ensure that you call the script at a time when it will receive elevated rights. For example, you should call the script by using computer startup scripts instead of a user logon script. You must also ensure that the installation of the custom compatibility-fix database occurs with Administrator rights.
### Example Script for an Installation of the .sdb File based on an .msi File
The following examples show an installation of a custom compatibility-fix database based on an .msi file.
``` syntax
'InstallSDB.vbs
Function Install
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "sdbinst.exe -q " & CHR(34) & "%ProgramFiles%\MyOrganizationSDB\MyOrg.sdb" & CHR(34), 0, true
WshShell.Run "cmd.exe /c " & CHR(34) & "del " & CHR(34) & "%ProgramFiles%\MyOrganizationSDB\MyOrg.sdb" & CHR(34) & CHR(34), 0
WshShell.Run "reg.exe delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{guidFromMyOrgsSdb}.sdb /f", 0
End Function
Function UnInstall
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "sdbinst.exe -q -u -g {guidFromMyOrgsSdb}", 0
End Function
```
### Initial Deployment and Updates
Most of your testing of application-compatibility issues will happen prior to the deployment of a new Windows operating system into your environment. As such, a common approach is to include the custom compatibility-fix database, which includes all of your known issues, in your corporate image. Then, as you update your compatibility-fix database, you can provide the updates by using one of the two mechanisms described in the "Deploying Your Custom Compatibility Fix Databases" section earlier in this topic.
## Related topics
[Managing Application-Compatibility Fixes and Custom Fix Databases](managing-application-compatibility-fixes-and-custom-fix-databases.md)
---
title: Compatibility Fix Database Management Strategies and Deployment (Windows 10)
ms.assetid: fdfbf02f-c4c4-4739-a400-782204fd3c6c
ms.reviewer:
manager: laurawi
ms.author: greglin
description:
ms.prod: w10
ms.mktglfcycl: plan
ms.pagetype: appcompat
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Compatibility Fix Database Management Strategies and Deployment
**Applies to**
- Windows 10
- Windows 8.1
- Windows 8
- Windows 7
- Windows Server 2012
- Windows Server 2008 R2
After you determine that you will use compatibility fixes in your application-compatibility mitigation strategy, you must define a strategy to manage your custom compatibility-fix database. Typically, you can use one of two approaches:
- Deploying your compatibility fixes as part of an application-installation package.
- Deploying your compatibility fixes through a centralized compatibility-fix database.
Regardless of which approach you decide to use in your organization, Microsoft provides the following general recommendations for improving the management of your custom compatibility-fix databases:
- **Define standards for when you will apply compatibility fixes.**
You must define the standards and scenarios for using compatibility fixes, based on your specific business and technology needs.
- **Define standards for your custom compatibility-fix databases.**
You must define how to associate your compatibility fixes to particular applications. For example, you might want to ensure that your compatibility fixes always include a version check, so that a fix will not be applied to newer versions of your applications.
- **Define your resources responsible for addressing questions and enforcing your standards.**
You must determine who will be responsible for staying current with the technology and standards related to your compatibility fixes and custom compatibility-fix databases. As your databases are managed over time, you must ensure that someone in your organization stays current with the relevant technology.
## Strategies for Deploying Your Compatibility Fixes
We recommend that you use one of two strategies to deploy your compatibility fixes into your organization. They are:
- Deploying your compatibility fixes as part of an application-installation package.
- Deploying your compatibility fixes through a centralized compatibility-fix database.
You must determine which method best meets your organization's deployment needs.
### Deploying Fixes as Part of an Application-Installation Package
One strategy for deploying compatibility fixes is to create a custom compatibility-fix database that contains a single entry that is applied directly to the application-installation package. While this is the most straightforward method of deployment, it has been shown that this method can become overly complex, especially if you are fixing a large number of applications.
If the following considerations apply to your organization, you should avoid this strategy and instead consider using a centralized compatibility-fix database, as described in the next section.
- **How many applications require compatibility fixes?**
Custom compatibility-fix databases are actual databases. Therefore, if you have 1000 applications to be fixed, it will take longer to open and query 1000 single-row databases for a match, instead of a single database with 1000 rows.
- **Will you be able to track which applications are installed on which computer?**
You might determine that your initial set of compatibility fixes is not comprehensive, and that you must deploy an updated version of the compatibility-fix database to resolve the additional issues. If you deployed the initial set by using the application-installation package, you will be required to locate each client computer that is running the application and replace the compatibility fix.
### Deploying Fixes Through a Centralized Compatibility-Fix Database
The other recommended strategy for deploying compatibility fixes into your organization is to create and manage either a single custom compatibility-fix database, or else to create and manage several custom databases for large subsets of your organization. This strategy will help to enforce your company policy and to provide consistent updates for application fixes that you discover later.
This approach tends to work best for organizations that have a well-developed deployment infrastructure in place, with centralized ownership of the process. We recommend that you consider the following before using this approach:
- Does your organization have the tools required to deploy and update a compatibility-fix database for all of the effected computers?
If you intend to manage a centralized compatibility-fix database, you must verify that your organization has the required tools to deploy and update all of the affected computers in your organization.
- Do you have centralized resources that can manage and update the centralized compatibility-fix database?
You must ensure that you have identified the appropriate owners for the deployment process, for the applications, and for the database updates, in addition to determining the process by which compatibility issues can be deployed to specific computers.
### Merging Centralized Compatibility-Fix Databases
If you decide to use the centralized compatibility-fix database deployment strategy, you can merge any of your individual compatibility-fix databases. This enables you to create a single custom compatibility-fix database that can be used to search for and determine whether Windows® should apply a fix to a specific executable (.exe) file. We recommend merging your databases based on the following process.
**To merge your custom-compatibility databases**
1. Verify that your application-compatibility testers are performing their tests on computers with the latest version of your compatibility-fix database. For example, Custom DB1.
2. If the tester determines that an application requires an additional compatibility fix that is not a part of the original compatibility-fix database, he or she must create a new custom compatibility database with all of the required information for that single fix. For example, Custom DB2.
3. The tester applies the new Custom DB2 information to the application and then tests for both the functionality and integration, to ensure that the compatibility issues are addressed.
4. After the application passes all of the required functionality and integration tests, the tester can send Custom DB2 to the team that manages the central compatibility-fix database.
5. The team that manages the centralized database opens Custom DB1 and uses the Compatibility Administrator to include the new compatibility fixes that were included in Custom DB2.
**Note**
Custom DB1 contains a unique GUID that makes updating the database easier. For example, if you install a new version of the custom compatibility-fix database that uses the same GUID as the previous version, the computer will automatically uninstall the old version.
6. The centralized management team then redeploys the new version of Custom DB1 to all of the end users in your organization.
### Deploying Your Custom Compatibility-Fix Databases
Deploying your custom compatibility-fix database into your organization requires you to perform the following actions:
1. Store your custom compatibility-fix database (.sdb file) in a location that is accessible to all of your organization’s computers.
2. Use the Sdbinst.exe command-line tool to install the custom compatibility-fix database locally.
In order to meet the two requirements above, we recommend that you use one of the following two methods:
- **Using a Windows Installer package and a custom script**
You can package your .sdb file and a custom deployment script into an .msi file, and then deploy the .msi file into your organization.
**Important**
You must ensure that you mark your custom script so that it does not impersonate the calling user. For example, if you use Microsoft® Visual Basic® Scripting Edition (VBScript), the custom action type would be:
~~~
```
msidbCustomActionTypeVBScript + msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate = 0x0006 + 0x0400 + 0x0800 = 0x0C06 = 3078 decimal)
```
~~~
- **Using a network share and a custom script**
You can store your .sdb file on your network share and then call to a script that resides on your specified computers.
**Important**
You must ensure that you call the script at a time when it will receive elevated rights. For example, you should call the script by using computer startup scripts instead of a user logon script. You must also ensure that the installation of the custom compatibility-fix database occurs with Administrator rights.
### Example Script for an Installation of the .sdb File based on an .msi File
The following examples show an installation of a custom compatibility-fix database based on an .msi file.
```
'InstallSDB.vbs
Function Install
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "sdbinst.exe -q " & CHR(34) & "%ProgramFiles%\MyOrganizationSDB\MyOrg.sdb" & CHR(34), 0, true
WshShell.Run "cmd.exe /c " & CHR(34) & "del " & CHR(34) & "%ProgramFiles%\MyOrganizationSDB\MyOrg.sdb" & CHR(34) & CHR(34), 0
WshShell.Run "reg.exe delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{guidFromMyOrgsSdb}.sdb /f", 0
End Function
Function UnInstall
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "sdbinst.exe -q -u -g {guidFromMyOrgsSdb}", 0
End Function
```
### Initial Deployment and Updates
Most of your testing of application-compatibility issues will happen prior to the deployment of a new Windows operating system into your environment. As such, a common approach is to include the custom compatibility-fix database, which includes all of your known issues, in your corporate image. Then, as you update your compatibility-fix database, you can provide the updates by using one of the two mechanisms described in the "Deploying Your Custom Compatibility Fix Databases" section earlier in this topic.
## Related topics
[Managing Application-Compatibility Fixes and Custom Fix Databases](managing-application-compatibility-fixes-and-custom-fix-databases.md)

481
windows/deployment/update/feature-update-user-install.md
View File

@ -1,239 +1,242 @@
---
title: Best practices - deploy feature updates for user-initiated installations
description: Learn how to manually deploy feature updates
ms.prod: w10
ms.mktglfcycl: manage
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.date: 07/10/2018
ms.reviewer:
manager: laurawi
ms.collection: M365-modern-desktop
ms.topic: article
---
# Deploy feature updates for user-initiated installations (during a fixed service window)
**Applies to**: Windows 10
Use the following steps to deploy a feature update for a user-initiated installation.
## Get ready to deploy feature updates
### Step 1: Enable Peer Cache
Use **Peer Cache** to help manage deployment of content to clients in remote locations. Peer Cache is a built-in Configuration Manager solution that enables clients to share content with other clients directly from their local cache.
[Enable Configuration Manager client in full OS to share content](https://docs.microsoft.com/sccm/core/clients/deploy/about-client-settings#enable-configuration-manager-client-in-full-os-to-share-content) if you have clients in remote locations that would benefit from downloading feature update content from a peer instead of downloading it from a distribution point (or Microsoft Update).
### Step 2: Override the default Windows setup priority (Windows 10, version 1709 and later)
If you’re deploying **Feature update to Windows 10, version 1709** or later, by default, portions of setup are configured to run at a lower priority. This can result in a longer total install time for the feature update. When deploying within a maintenance window, we recommend that you override this default behavior to benefit from faster total install times. To override the default priority, create a file called SetupConfig.ini on each machine to be upgraded in the below location containing the single section noted.
%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini
```
[SetupConfig]
Priority=Normal
```
You can use the new [Run Scripts](https://docs.microsoft.com/sccm/apps/deploy-use/create-deploy-scripts) feature to run a PowerShell script like the sample below to create the SetupConfig.ini on target devices.
```
#Parameters
Param(
[string] $PriorityValue = "Normal"
)
#Variable for ini file path
$iniFilePath = "$env:SystemDrive\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
#Variables for SetupConfig
$iniSetupConfigSlogan = "[SetupConfig]"
$iniSetupConfigKeyValuePair =@{"Priority"=$PriorityValue;}
#Init SetupConfig content
$iniSetupConfigContent = @"
$iniSetupConfigSlogan
"@
#Build SetupConfig content with settings
foreach ($k in $iniSetupConfigKeyValuePair.Keys)
{
$val = $iniSetupConfigKeyValuePair[$k]
$iniSetupConfigContent = $iniSetupConfigContent.Insert($iniSetupConfigContent.Length, "`r`n$k=$val")
}
#Write content to file
New-Item $iniFilePath -ItemType File -Value $iniSetupConfigContent -Force
Disclaimer
Sample scripts are not supported under any Microsoft standard support program or service. The sample scripts is
provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without
limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk
arising out of the use or performance of the sample script and documentation remains with you. In no event shall
Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable
for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption,
loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample script
or documentation, even if Microsoft has been advised of the possibility of such damages.
```
>[!NOTE]
>If you elect not to override the default setup priority, you will need to increase the [maximum run time](https://docs.microsoft.com/sccm/sum/get-started/manage-settings-for-software-updates#BKMK_SetMaxRunTime) value for Feature Update to Windows 10, version 1709 or higher from the default of 60 minutes. A value of 240 minutes may be required. Remember to ensure that your maintenance window duration is larger than your defined maximum run time value.
## Manually deploy feature updates in a user-initiated installation
The following sections provide the steps to manually deploy a feature update.
### Step 1: Specify search criteria for feature updates
There are potentially a thousand or more feature updates displayed in the Configuration Manager console. The first step in the workflow for manually deploying a feature update is to identify the feature updates that you want to deploy.
1. In the Configuration Manager console, click **Software Library**.
2. In the Software Library workspace, expand **Windows 10 Servicing**, and click **All Windows 10 Updates**. The synchronized feature updates are displayed.
3. In the search pane, filter to identify the feature updates that you need by using one or both of the following steps:
- In the **search** text box, type a search string that will filter the feature updates. For example, type the version number for a specific feature update, or enter a string that would appear in the title of the feature update.
- Click **Add Criteria**, select the criteria that you want to use to filter software updates, click **Add**, and then provide the values for the criteria. For example, Title contains 1803, **Required** is greater than or equal to 1, and **Language** equals English.
4. Save the search for future use.
### Step 2: Download the content for the feature update(s)
Before you deploy the feature updates, you can download the content as a separate step. Do this so you can verify that the content is available on the distribution points before you deploy the feature updates. This will help you to avoid any unexpected issues with the content delivery. Use the following procedure to download the content for feature updates before creating the deployment.
1. In the Configuration Manager console, navigate to **Software Library > Windows 10 Servicing**.
2. Choose the feature update(s) to download by using your saved search criteria. Select one or more of the feature updates returned, right click, and select **Download**.
The **Download Software Updates Wizard** opens.
3. On the **Deployment Package** page, configure the following settings:
**Create a new deployment package**: Select this setting to create a new deployment package for the software updates that are in the deployment. Configure the following settings:
- **Name**: Specifies the name of the deployment package. The package must have a unique name that briefly describes the package content. It is limited to 50 characters.
- **Description**: Specifies the description of the deployment package. The package description provides information about the package contents and is limited to 127 characters.
- **Package source**: Specifies the location of the feature update source files. Type a network path for the source location, for example, \\\server\sharename\path, or click **Browse** to find the network location. You must create the shared folder for the deployment package source files before you proceed to the next page.
>[!NOTE]
>The deployment package source location that you specify cannot be used by another software deployment package.
>[!IMPORTANT]
>The SMS Provider computer account and the user that is running the wizard to download the feature updates must both have Write NTFS permissions on the download location. You should carefully restrict access to the download location to reduce the risk of attackers tampering with the feature update source files.
>[!IMPORTANT]
>You can change the package source location in the deployment package properties after Configuration Manager creates the deployment package. But if you do so, you must first copy the content from the original package source to the new package source location.
Click **Next**.
4. On the **Distribution Points** page, specify the distribution points or distribution point groups that will host the feature update files, and then click **Next**. For more information about distribution points, see [Distribution point configurations](https://docs.microsoft.com/sccm/core/servers/deploy/configure/install-and-configure-distribution-points#bkmk_configs).
>[!NOTE]
>The Distribution Points page is available only when you create a new software update deployment package.
5. On the **Distribution Settings** page, specify the following settings:
- **Distribution priority**: Use this setting to specify the distribution priority for the deployment package. The distribution priority applies when the deployment package is sent to distribution points at child sites. Deployment packages are sent in priority order: **High**, **Medium**, or **Low**. Packages with identical priorities are sent in the order in which they were created. If there is no backlog, the package will process immediately regardless of its priority. By default, packages are sent using Medium priority.
- **Enable for on-demand distribution**: Use this setting to enable on-demand content distribution to preferred distribution points. When this setting is enabled, the management point creates a trigger for the distribution manager to distribute the content to all preferred distribution points when a client requests the content for the package and the content is not available on any preferred distribution points. For more information about preferred distribution points and on-demand content, see [Content source location scenarios](https://docs.microsoft.com/sccm/core/plan-design/hierarchy/content-source-location-scenarios).
- **Prestaged distribution point settings**: Use this setting to specify how you want to distribute content to prestaged distribution points. Choose one of the following options:
- **Automatically download content when packages are assigned to distribution points**: Use this setting to ignore the prestage settings and distribute content to the distribution point.
- **Download only content changes to the distribution point**: Use this setting to prestage the initial content to the distribution point, and then distribute content changes to the distribution point.
- **Manually copy the content in this package to the distribution point**: Use this setting to always prestage content on the distribution point. This is the default setting.
For more information about prestaging content to distribution points, see [Use Prestaged content](https://docs.microsoft.com/sccm/core/servers/deploy/configure/deploy-and-manage-content#bkmk_prestage).
Click **Next**.
6. On the **Download Location** page, specify location that Configuration Manager will use to download the software update source files. As needed, use the following options:
- **Download software updates from the Internet**: Select this setting to download the software updates from the location on the Internet. This is the default setting.
- **Download software updates from a location on the local network**: Select this setting to download software updates from a local folder or shared network folder. Use this setting when the computer running the wizard does not have Internet access.
>[!NOTE]
>When you use this setting, download the software updates from any computer with Internet access, and then copy the software updates to a location on the local network that is accessible from the computer running the wizard.
Click **Next**.
7. On the **Language Selection** page, specify the languages for which the selected feature updates are to be downloaded, and then click **Next**. Ensure that your language selection matches the language(s) of the feature updates selected for download. For example, if you selected English and German based feature updates for download, select those same languages on the language selection page.
8. On the **Summary** page, verify the settings that you selected in the wizard, and then click Next to download the software updates.
9. On the **Completion** page, verify that the software updates were successfully downloaded, and then click **Close**.
#### To monitor content status
1. To monitor the content status for the feature updates, click **Monitoring** in the Configuration Manager console.
2. In the Monitoring workspace, expand **Distribution Status**, and then click **Content Status**.
3. Select the feature update package that you previously identified to download the feature updates.
4. On the **Home** tab, in the Content group, click **View Status**.
### Step 3: Deploy the feature update(s)
After you determine which feature updates you intend to deploy, you can manually deploy the feature update(s). Use the following procedure to manually deploy the feature update(s).
1. In the Configuration Manager console, click **Software Library**.
2. In the Software Library workspace, expand **Windows 10 Servicing**, and click **All Windows 10 Updates**.
3. Choose the feature update(s) to deploy by using your saved search criteria. Select one or more of the feature updates returned, right click, and select **Deploy**.
The **Deploy Software Updates Wizard** opens.
4. On the General page, configure the following settings:
- **Name**: Specify the name for the deployment. The deployment must have a unique name that describes the purpose of the deployment and differentiates it from other deployments in the Configuration Manager site. By default, Configuration Manager automatically provides a name for the deployment in the following format: **Microsoft Software Updates - \<date\>\<time\>**
- **Description**: Specify a description for the deployment. The description provides an overview of the deployment and any other relevant information that helps to identify and differentiate the deployment among others in Configuration Manager site. The description field is optional, has a limit of 256 characters, and has a blank value by default.
- **Software Update/Software Update Group**: Verify that the displayed software update group, or software update, is correct.
- **Select Deployment Template**: Specify whether to apply a previously saved deployment template. You can configure a deployment template to contain multiple common software update deployment properties and then apply the template when you deploy subsequent software updates to ensure consistency across similar deployments and to save time.
- **Collection**: Specify the collection for the deployment, as applicable. Members of the collection receive the feature updates that are defined in the deployment.
5. On the Deployment Settings page, configure the following settings:
- **Type of deployment**: Specify the deployment type for the software update deployment. Select **Required** to create a mandatory software update deployment in which the feature updates are automatically installed on clients before a configured installation deadline.
>[!IMPORTANT]
> After you create the software update deployment, you cannot later change the type of deployment.
>[!NOTE]
>A software update group deployed as **Required** will be downloaded in background and honor BITS settings, if configured.
- **Use Wake-on-LAN to wake up clients for required deployments**: Specify whether to enable Wake On LAN at the deadline to send wake-up packets to computers that require one or more software updates in the deployment. Any computers that are in sleep mode at the installation deadline time will be awakened so the software update installation can initiate. Clients that are in sleep mode that do not require any software updates in the deployment are not started. By default, this setting is not enabled and is available only when **Type of deployment** is set to **Required**.
>[!WARNING]
>Before you can use this option, computers and networks must be configured for Wake On LAN.
- **Detail level**: Specify the level of detail for the state messages that are reported by client computers.
6. On the Scheduling page, configure the following settings:
- **Schedule evaluation**: Specify whether the available time and installation deadline times are evaluated according to UTC or the local time of the computer running the Configuration Manager console.
- **Software available time**: Select **Specific time** to specify when the software updates will be available to clients:
- **Specific time**: Select this setting to make the feature update in the deployment available to clients at a specific date and time. Specify a date and time that corresponds with the start of your fixed servicing window. When the deployment is created, the client policy is updated and clients are made aware of the deployment at their next client policy polling cycle. However, the feature update in the deployment is not available for installation until after the specified date and time are reached and the required content has been downloaded.
- **Installation deadline**: Select **Specific time** to specify the installation deadline for the software updates in the deployment.
>[!NOTE]
>You can configure the installation deadline setting only when **Type of deployment** is set to **Required** on the Deployment Settings page.
- **Specific time**: Select this setting to automatically install the software updates in the deployment at a specific date and time. However, for the purposes of the fixed servicing window, set the installation deadline date and time to a future value, well beyond the fixed servicing window.
Required deployments for software updates can benefit from functionality called advanced download. When the software available time is reached, clients will start downloading the content based on a randomized time. The feature update will not be displayed in Software Center for installation until the content is fully downloaded. This ensures that the feature update installation will start immediately when initiated.
7. On the User Experience page, configure the following settings:
- **User notifications**: Specify **Display in Software Center and show all notifications**.
- **Deadline behavior**: Available only when **Type of deployment** is set to **Required** on the Deployment Settings page. Specify the behavior that is to occur when the deadline is reached for the software update deployment. Specify whether to install the software updates in the deployment. Also specify whether to perform a system restart after software update installation regardless of a configured maintenance window.
>[!NOTE]
>Remember that the installation deadline date and time will be well into the future to allow plenty of time for the user-initiated install during a fixed servicing window.
- **Device restart behavior**: Available only when **Type of deployment** is set to **Required** on the Deployment Settings page. Specify whether to suppress a system restart on servers and workstations after software updates are installed and a system restart is required to complete the installation.
>[!IMPORTANT]
>Suppressing system restarts can be useful in server environments or for cases in which you do not want the computers that are installing the software updates to restart by default. However, doing so can leave computers in an insecure state, whereas allowing a forced restart helps to ensure immediate completion of the software update installation.
- **Write filter handling for Windows Embedded devices**: When you deploy software updates to Windows Embedded devices that are write filter enabled, you can specify to install the software update on the temporary overlay and either commit changes later or commit the changes at the installation deadline or during a maintenance window. When you commit changes at the installation deadline or during a maintenance window, a restart is required and the changes persist on the device.
>[!NOTE]
>When you deploy a software update to a Windows Embedded device, make sure that the device is a member of a collection that has a configured maintenance window.
- **Software updates deployment re-evaluation behavior upon restart**: Starting in Configuration Manager version 1606, select this setting to configure software updates deployments to have clients run a software updates compliance scan immediately after a client installs software updates and restarts. This enables the client to check for additional software updates that become applicable after the client restarts, and to then install them (and become compliant) during the same maintenance window.
8. On the Alerts page, configure how Configuration Manager and System Center Operations Manager will generate alerts for this deployment. You can configure alerts only when **Type of deployment** is set to **Required** on the Deployment Settings page.
>[!NOTE]
>You can review recent software updates alerts from the **Software Updates** node in the **Software Library** workspace.
9. On the Download Settings page, configure the following settings:
- Specify whether the client will download and install the software updates when a client is connected to a slow network or is using a fallback content location.
- Specify whether to have the client download and install the software updates from a fallback distribution point when the content for the software updates is not available on a preferred distribution point.
- **Allow clients to share content with other clients on the same subnet**: Specify whether to enable the use of BranchCache for content downloads. For more information about BranchCache, see [Fundamental concepts for content management](https://docs.microsoft.com/sccm/core/plan-design/hierarchy/fundamental-concepts-for-content-management#branchcache).
- **If software updates are not available on distribution point in current, neighbor or site groups, download content from Microsoft Updates**: Select this setting to have clients that are connected to the intranet download software updates from Microsoft Update if software updates are not available on distribution points. Internet-based clients can always go to Microsoft Update for software updates content.
- Specify whether to allow clients to download after an installation deadline when they use metered Internet connections. Internet providers sometimes charge by the amount of data that you send and receive when you are on a metered Internet connection.
>[!NOTE]
>Clients request the content location from a management point for the software updates in a deployment. The download behavior depends upon how you have configured the distribution point, the deployment package, and the settings on this page. For more information, see [Content source location scenarios](https://docs.microsoft.com/sccm/core/plan-design/hierarchy/content-source-location-scenarios).
10. On the Summary page, review the settings. To save the settings to a deployment template, click **Save As Template**, enter a name and select the settings that you want to include in the template, and then click **Save**. To change a configured setting, click the associated wizard page and change the setting.
11. Click **Next** to deploy the feature update(s).
### Step 4: Monitor the deployment status
After you deploy the feature update(s), you can monitor the deployment status. Use the following procedure to monitor the deployment status:
1. In the Configuration Manager console, navigate to **Monitoring > Overview > Deployments**.
2. Click the software update group or software update for which you want to monitor the deployment status.
3. On the **Home** tab, in the **Deployment** group, click **View Status**.
---
title: Best practices - deploy feature updates for user-initiated installations
description: Learn how to manually deploy feature updates
ms.prod: w10
ms.mktglfcycl: manage
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.date: 07/10/2018
ms.reviewer:
manager: laurawi
ms.collection: M365-modern-desktop
ms.topic: article
---
# Deploy feature updates for user-initiated installations (during a fixed service window)
**Applies to**: Windows 10
Use the following steps to deploy a feature update for a user-initiated installation.
## Get ready to deploy feature updates
### Step 1: Enable Peer Cache
Use **Peer Cache** to help manage deployment of content to clients in remote locations. Peer Cache is a built-in Configuration Manager solution that enables clients to share content with other clients directly from their local cache.
[Enable Configuration Manager client in full OS to share content](https://docs.microsoft.com/sccm/core/clients/deploy/about-client-settings#enable-configuration-manager-client-in-full-os-to-share-content) if you have clients in remote locations that would benefit from downloading feature update content from a peer instead of downloading it from a distribution point (or Microsoft Update).
### Step 2: Override the default Windows setup priority (Windows 10, version 1709 and later)
If you’re deploying **Feature update to Windows 10, version 1709** or later, by default, portions of setup are configured to run at a lower priority. This can result in a longer total install time for the feature update. When deploying within a maintenance window, we recommend that you override this default behavior to benefit from faster total install times. To override the default priority, create a file called SetupConfig.ini on each machine to be upgraded in the below location containing the single section noted.
%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini
```
[SetupConfig]
Priority=Normal
```
You can use the new [Run Scripts](https://docs.microsoft.com/sccm/apps/deploy-use/create-deploy-scripts) feature to run a PowerShell script like the sample below to create the SetupConfig.ini on target devices.
```
#Parameters
Param(
[string] $PriorityValue = "Normal"
)
#Variable for ini file path
$iniFilePath = "$env:SystemDrive\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini"
#Variables for SetupConfig
$iniSetupConfigSlogan = "[SetupConfig]"
$iniSetupConfigKeyValuePair =@{"Priority"=$PriorityValue;}
#Init SetupConfig content
$iniSetupConfigContent = @"
$iniSetupConfigSlogan
"@
#Build SetupConfig content with settings
foreach ($k in $iniSetupConfigKeyValuePair.Keys)
{
$val = $iniSetupConfigKeyValuePair[$k]
$iniSetupConfigContent = $iniSetupConfigContent.Insert($iniSetupConfigContent.Length, "`r`n$k=$val")
}
#Write content to file
New-Item $iniFilePath -ItemType File -Value $iniSetupConfigContent -Force
<#
Disclaimer
Sample scripts are not supported under any Microsoft standard support program or service. The sample scripts is
provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without
limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk
arising out of the use or performance of the sample script and documentation remains with you. In no event shall
Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable
for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption,
loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample script
or documentation, even if Microsoft has been advised of the possibility of such damages.
#>
```
>[!NOTE]
>If you elect not to override the default setup priority, you will need to increase the [maximum run time](https://docs.microsoft.com/sccm/sum/get-started/manage-settings-for-software-updates#BKMK_SetMaxRunTime) value for Feature Update to Windows 10, version 1709 or higher from the default of 60 minutes. A value of 240 minutes may be required. Remember to ensure that your maintenance window duration is larger than your defined maximum run time value.
## Manually deploy feature updates in a user-initiated installation
The following sections provide the steps to manually deploy a feature update.
### Step 1: Specify search criteria for feature updates
There are potentially a thousand or more feature updates displayed in the Configuration Manager console. The first step in the workflow for manually deploying a feature update is to identify the feature updates that you want to deploy.
1. In the Configuration Manager console, click **Software Library**.
2. In the Software Library workspace, expand **Windows 10 Servicing**, and click **All Windows 10 Updates**. The synchronized feature updates are displayed.
3. In the search pane, filter to identify the feature updates that you need by using one or both of the following steps:
- In the **search** text box, type a search string that will filter the feature updates. For example, type the version number for a specific feature update, or enter a string that would appear in the title of the feature update.
- Click **Add Criteria**, select the criteria that you want to use to filter software updates, click **Add**, and then provide the values for the criteria. For example, Title contains 1803, **Required** is greater than or equal to 1, and **Language** equals English.
4. Save the search for future use.
### Step 2: Download the content for the feature update(s)
Before you deploy the feature updates, you can download the content as a separate step. Do this so you can verify that the content is available on the distribution points before you deploy the feature updates. This will help you to avoid any unexpected issues with the content delivery. Use the following procedure to download the content for feature updates before creating the deployment.
1. In the Configuration Manager console, navigate to **Software Library > Windows 10 Servicing**.
2. Choose the feature update(s) to download by using your saved search criteria. Select one or more of the feature updates returned, right click, and select **Download**.
The **Download Software Updates Wizard** opens.
3. On the **Deployment Package** page, configure the following settings:
**Create a new deployment package**: Select this setting to create a new deployment package for the software updates that are in the deployment. Configure the following settings:
- **Name**: Specifies the name of the deployment package. The package must have a unique name that briefly describes the package content. It is limited to 50 characters.
- **Description**: Specifies the description of the deployment package. The package description provides information about the package contents and is limited to 127 characters.
- **Package source**: Specifies the location of the feature update source files. Type a network path for the source location, for example, \\\server\sharename\path, or click **Browse** to find the network location. You must create the shared folder for the deployment package source files before you proceed to the next page.
>[!NOTE]
>The deployment package source location that you specify cannot be used by another software deployment package.
>[!IMPORTANT]
>The SMS Provider computer account and the user that is running the wizard to download the feature updates must both have Write NTFS permissions on the download location. You should carefully restrict access to the download location to reduce the risk of attackers tampering with the feature update source files.
>[!IMPORTANT]
>You can change the package source location in the deployment package properties after Configuration Manager creates the deployment package. But if you do so, you must first copy the content from the original package source to the new package source location.
Click **Next**.
4. On the **Distribution Points** page, specify the distribution points or distribution point groups that will host the feature update files, and then click **Next**. For more information about distribution points, see [Distribution point configurations](https://docs.microsoft.com/sccm/core/servers/deploy/configure/install-and-configure-distribution-points#bkmk_configs).
>[!NOTE]
>The Distribution Points page is available only when you create a new software update deployment package.
5. On the **Distribution Settings** page, specify the following settings:
- **Distribution priority**: Use this setting to specify the distribution priority for the deployment package. The distribution priority applies when the deployment package is sent to distribution points at child sites. Deployment packages are sent in priority order: **High**, **Medium**, or **Low**. Packages with identical priorities are sent in the order in which they were created. If there is no backlog, the package will process immediately regardless of its priority. By default, packages are sent using Medium priority.
- **Enable for on-demand distribution**: Use this setting to enable on-demand content distribution to preferred distribution points. When this setting is enabled, the management point creates a trigger for the distribution manager to distribute the content to all preferred distribution points when a client requests the content for the package and the content is not available on any preferred distribution points. For more information about preferred distribution points and on-demand content, see [Content source location scenarios](https://docs.microsoft.com/sccm/core/plan-design/hierarchy/content-source-location-scenarios).
- **Prestaged distribution point settings**: Use this setting to specify how you want to distribute content to prestaged distribution points. Choose one of the following options:
- **Automatically download content when packages are assigned to distribution points**: Use this setting to ignore the prestage settings and distribute content to the distribution point.
- **Download only content changes to the distribution point**: Use this setting to prestage the initial content to the distribution point, and then distribute content changes to the distribution point.
- **Manually copy the content in this package to the distribution point**: Use this setting to always prestage content on the distribution point. This is the default setting.
For more information about prestaging content to distribution points, see [Use Prestaged content](https://docs.microsoft.com/sccm/core/servers/deploy/configure/deploy-and-manage-content#bkmk_prestage).
Click **Next**.
6. On the **Download Location** page, specify location that Configuration Manager will use to download the software update source files. As needed, use the following options:
- **Download software updates from the Internet**: Select this setting to download the software updates from the location on the Internet. This is the default setting.
- **Download software updates from a location on the local network**: Select this setting to download software updates from a local folder or shared network folder. Use this setting when the computer running the wizard does not have Internet access.
>[!NOTE]
>When you use this setting, download the software updates from any computer with Internet access, and then copy the software updates to a location on the local network that is accessible from the computer running the wizard.
Click **Next**.
7. On the **Language Selection** page, specify the languages for which the selected feature updates are to be downloaded, and then click **Next**. Ensure that your language selection matches the language(s) of the feature updates selected for download. For example, if you selected English and German based feature updates for download, select those same languages on the language selection page.
8. On the **Summary** page, verify the settings that you selected in the wizard, and then click Next to download the software updates.
9. On the **Completion** page, verify that the software updates were successfully downloaded, and then click **Close**.
#### To monitor content status
1. To monitor the content status for the feature updates, click **Monitoring** in the Configuration Manager console.
2. In the Monitoring workspace, expand **Distribution Status**, and then click **Content Status**.
3. Select the feature update package that you previously identified to download the feature updates.
4. On the **Home** tab, in the Content group, click **View Status**.
### Step 3: Deploy the feature update(s)
After you determine which feature updates you intend to deploy, you can manually deploy the feature update(s). Use the following procedure to manually deploy the feature update(s).
1. In the Configuration Manager console, click **Software Library**.
2. In the Software Library workspace, expand **Windows 10 Servicing**, and click **All Windows 10 Updates**.
3. Choose the feature update(s) to deploy by using your saved search criteria. Select one or more of the feature updates returned, right click, and select **Deploy**.
The **Deploy Software Updates Wizard** opens.
4. On the General page, configure the following settings:
- **Name**: Specify the name for the deployment. The deployment must have a unique name that describes the purpose of the deployment and differentiates it from other deployments in the Configuration Manager site. By default, Configuration Manager automatically provides a name for the deployment in the following format: **Microsoft Software Updates - \<date\>\<time\>**
- **Description**: Specify a description for the deployment. The description provides an overview of the deployment and any other relevant information that helps to identify and differentiate the deployment among others in Configuration Manager site. The description field is optional, has a limit of 256 characters, and has a blank value by default.
- **Software Update/Software Update Group**: Verify that the displayed software update group, or software update, is correct.
- **Select Deployment Template**: Specify whether to apply a previously saved deployment template. You can configure a deployment template to contain multiple common software update deployment properties and then apply the template when you deploy subsequent software updates to ensure consistency across similar deployments and to save time.
- **Collection**: Specify the collection for the deployment, as applicable. Members of the collection receive the feature updates that are defined in the deployment.
5. On the Deployment Settings page, configure the following settings:
- **Type of deployment**: Specify the deployment type for the software update deployment. Select **Required** to create a mandatory software update deployment in which the feature updates are automatically installed on clients before a configured installation deadline.
>[!IMPORTANT]
> After you create the software update deployment, you cannot later change the type of deployment.
>[!NOTE]
>A software update group deployed as **Required** will be downloaded in background and honor BITS settings, if configured.
- **Use Wake-on-LAN to wake up clients for required deployments**: Specify whether to enable Wake On LAN at the deadline to send wake-up packets to computers that require one or more software updates in the deployment. Any computers that are in sleep mode at the installation deadline time will be awakened so the software update installation can initiate. Clients that are in sleep mode that do not require any software updates in the deployment are not started. By default, this setting is not enabled and is available only when **Type of deployment** is set to **Required**.
>[!WARNING]
>Before you can use this option, computers and networks must be configured for Wake On LAN.
- **Detail level**: Specify the level of detail for the state messages that are reported by client computers.
6. On the Scheduling page, configure the following settings:
- **Schedule evaluation**: Specify whether the available time and installation deadline times are evaluated according to UTC or the local time of the computer running the Configuration Manager console.
- **Software available time**: Select **Specific time** to specify when the software updates will be available to clients:
- **Specific time**: Select this setting to make the feature update in the deployment available to clients at a specific date and time. Specify a date and time that corresponds with the start of your fixed servicing window. When the deployment is created, the client policy is updated and clients are made aware of the deployment at their next client policy polling cycle. However, the feature update in the deployment is not available for installation until after the specified date and time are reached and the required content has been downloaded.
- **Installation deadline**: Select **Specific time** to specify the installation deadline for the software updates in the deployment.
>[!NOTE]
>You can configure the installation deadline setting only when **Type of deployment** is set to **Required** on the Deployment Settings page.
- **Specific time**: Select this setting to automatically install the software updates in the deployment at a specific date and time. However, for the purposes of the fixed servicing window, set the installation deadline date and time to a future value, well beyond the fixed servicing window.
Required deployments for software updates can benefit from functionality called advanced download. When the software available time is reached, clients will start downloading the content based on a randomized time. The feature update will not be displayed in Software Center for installation until the content is fully downloaded. This ensures that the feature update installation will start immediately when initiated.
7. On the User Experience page, configure the following settings:
- **User notifications**: Specify **Display in Software Center and show all notifications**.
- **Deadline behavior**: Available only when **Type of deployment** is set to **Required** on the Deployment Settings page. Specify the behavior that is to occur when the deadline is reached for the software update deployment. Specify whether to install the software updates in the deployment. Also specify whether to perform a system restart after software update installation regardless of a configured maintenance window.
>[!NOTE]
>Remember that the installation deadline date and time will be well into the future to allow plenty of time for the user-initiated install during a fixed servicing window.
- **Device restart behavior**: Available only when **Type of deployment** is set to **Required** on the Deployment Settings page. Specify whether to suppress a system restart on servers and workstations after software updates are installed and a system restart is required to complete the installation.
>[!IMPORTANT]
>Suppressing system restarts can be useful in server environments or for cases in which you do not want the computers that are installing the software updates to restart by default. However, doing so can leave computers in an insecure state, whereas allowing a forced restart helps to ensure immediate completion of the software update installation.
- **Write filter handling for Windows Embedded devices**: When you deploy software updates to Windows Embedded devices that are write filter enabled, you can specify to install the software update on the temporary overlay and either commit changes later or commit the changes at the installation deadline or during a maintenance window. When you commit changes at the installation deadline or during a maintenance window, a restart is required and the changes persist on the device.
>[!NOTE]
>When you deploy a software update to a Windows Embedded device, make sure that the device is a member of a collection that has a configured maintenance window.
- **Software updates deployment re-evaluation behavior upon restart**: Starting in Configuration Manager version 1606, select this setting to configure software updates deployments to have clients run a software updates compliance scan immediately after a client installs software updates and restarts. This enables the client to check for additional software updates that become applicable after the client restarts, and to then install them (and become compliant) during the same maintenance window.
8. On the Alerts page, configure how Configuration Manager and System Center Operations Manager will generate alerts for this deployment. You can configure alerts only when **Type of deployment** is set to **Required** on the Deployment Settings page.
>[!NOTE]
>You can review recent software updates alerts from the **Software Updates** node in the **Software Library** workspace.
9. On the Download Settings page, configure the following settings:
- Specify whether the client will download and install the software updates when a client is connected to a slow network or is using a fallback content location.
- Specify whether to have the client download and install the software updates from a fallback distribution point when the content for the software updates is not available on a preferred distribution point.
- **Allow clients to share content with other clients on the same subnet**: Specify whether to enable the use of BranchCache for content downloads. For more information about BranchCache, see [Fundamental concepts for content management](https://docs.microsoft.com/sccm/core/plan-design/hierarchy/fundamental-concepts-for-content-management#branchcache).
- **If software updates are not available on distribution point in current, neighbor or site groups, download content from Microsoft Updates**: Select this setting to have clients that are connected to the intranet download software updates from Microsoft Update if software updates are not available on distribution points. Internet-based clients can always go to Microsoft Update for software updates content.
- Specify whether to allow clients to download after an installation deadline when they use metered Internet connections. Internet providers sometimes charge by the amount of data that you send and receive when you are on a metered Internet connection.
>[!NOTE]
>Clients request the content location from a management point for the software updates in a deployment. The download behavior depends upon how you have configured the distribution point, the deployment package, and the settings on this page. For more information, see [Content source location scenarios](https://docs.microsoft.com/sccm/core/plan-design/hierarchy/content-source-location-scenarios).
10. On the Summary page, review the settings. To save the settings to a deployment template, click **Save As Template**, enter a name and select the settings that you want to include in the template, and then click **Save**. To change a configured setting, click the associated wizard page and change the setting.
11. Click **Next** to deploy the feature update(s).
### Step 4: Monitor the deployment status
After you deploy the feature update(s), you can monitor the deployment status. Use the following procedure to monitor the deployment status:
1. In the Configuration Manager console, navigate to **Monitoring > Overview > Deployments**.
2. Click the software update group or software update for which you want to monitor the deployment status.
3. On the **Home** tab, in the **Deployment** group, click **View Status**.

555
windows/deployment/update/waas-configure-wufb.md
View File

@ -1,277 +1,278 @@
---
title: Configure Windows Update for Business (Windows 10)
ms.reviewer:
manager: laurawi
description: You can use Group Policy or your mobile device management (MDM) service to configure Windows Update for Business settings for your devices.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.topic: article
---
# Configure Windows Update for Business
**Applies to**
- Windows 10
- Windows 10 Mobile
- Windows Server 2016
- Windows Server 2019
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
You can use Group Policy or your mobile device management (MDM) service to configure Windows Update for Business settings for your devices. The sections in this topic provide the Group Policy and MDM policies for Windows 10, version 1511 and above. The MDM policies use the OMA-URI setting from the [Policy CSP](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx).
>[!IMPORTANT]
>For Windows Update for Business policies to be honored, the diagnostic data level of the device must be set to **1 (Basic)** or higher. If it is set to **0 (Security)**, Windows Update for Business policies will have no effect. For instructions, see [Configure the operating system diagnostic data level](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization#diagnostic-data-levels).
Some Windows Update for Business policies are not applicable or behave differently for devices running Windows 10 Mobile Enterprise. Specifically, policies pertaining to Feature Updates will not be applied to Windows 10 Mobile Enterprise. All Windows 10 Mobile updates are recognized as Quality Updates, and can only be deferred or paused using the Quality Update policy settings. Additional information is provided in this topic and in [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md).
## Start by grouping devices
By grouping devices with similar deferral periods, administrators are able to cluster devices into deployment or validation groups which can be as a quality control measure as updates are deployed in Windows 10. With deferral windows and the ability to pause updates, administrators can effectively control and measure update deployments, updating a small pool of devices first to verify quality, prior to a broader roll-out to their organization. For more information, see [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md).
>[!TIP]
>In addition to setting up multiple rings for your update deployments, also incorporate devices enrolled in the Windows Insider Program as part of your deployment strategy. This will provide you the chance to not only evaluate new features before they are broadly available to the public, but it also increases the lead time to provide feedback and influence Microsoft’s design on functional aspects of the product. For more information on Windows Insider program, see [https://insider.windows.com/](https://insider.windows.com/).
<span id="configure-devices-for-current-branch-or-current-branch-for-business"/>
## Configure devices for the appropriate service channel
With Windows Update for Business, you can set a device to be on either Windows Insider Preview or the Semi-Annual Channel servicing branch. For more information on this servicing model, see [Windows 10 servicing options](waas-overview.md#servicing-channels).
**Release branch policies**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 or later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Feature Updates are received** | \Policies\Microsoft\Windows\WindowsUpdate\BranchReadinessLevel |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\DeferUpgrade |
| MDM for Windows 10, version 1607 or later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**BranchReadinessLevel** | \Microsoft\PolicyManager\default\Update\BranchReadinessLevel |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**RequireDeferUpgrade** | \Microsoft\PolicyManager\default\Update\RequireDeferUpgrade |
Starting with Windows 10, version 1703, users can configure the branch readiness level for their device by using **Settings > Update & security > Windows Update > Advanced options**.
![Branch readiness level setting](images/waas-wufb-settings-branch.jpg)
>[!NOTE]
>Users will not be able to change this setting if it was configured by policy.
## Configure when devices receive feature updates
After you configure the servicing branch (Windows Insider Preview or Semi-Annual Channel), you can then define if, and for how long, you would like to defer receiving Feature Updates following their availability from Microsoft on Windows Update. You can defer receiving these Feature Updates for a period of up to 365 days from their release by setting the `DeferFeatureUpdatesPeriodinDays` value.
For example, a device on the Semi-Annual Channel with `DeferFeatureUpdatesPeriodinDays=30` will not install a feature update that is first publicly available on Windows Update in September until 30 days later, in October.
</br></br>
**Policy settings for deferring feature updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Feature Updates are received** | \Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdates</br>\Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdatesPeriodInDays |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\DeferUpgradePeriod |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferFeatureUpdatesPeriodInDays** | \Microsoft\PolicyManager\default\Update\DeferFeatureUpdatesPeriodInDays |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\RequireDeferUpgrade |
>[!NOTE]
>If not configured by policy, individual users can defer feature updates by using **Settings > Update & security > Windows Update > Advanced options**.
## Pause feature updates
You can also pause a device from receiving Feature Updates by a period of up to 35 days from when the value is set. After 35 days has passed, the pause setting will automatically expire and the device will scan Windows Update for applicable Feature Updates. Following this scan, you can then pause Feature Updates for the device again.
Starting with Windows 10, version 1703, when you configure a pause by using policy, you must set a start date for the pause to begin. The pause period is calculated by adding 35 days to this start date.
In cases where the pause policy is first applied after the configured start date has passed, you can extend the pause period up to a total of 35 days by configuring a later start date.
>[!IMPORTANT]
>
>In Windows 10, version 1703 and later versions, you can pause feature updates to 35 days, similar to the number of days for quality updates.
**Policy settings for pausing feature updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Feature Updates are received** | **1607:** \Policies\Microsoft\Windows\WindowsUpdate\PauseFeatureUpdates</br>**1703 and later:** \Policies\Microsoft\Windows\WindowsUpdate\PauseFeatureUpdatesStartDate |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\Pause |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**PauseFeatureUpdates** | **1607:** \Microsoft\PolicyManager\default\Update\PauseFeatureUpdates</br> **1703 and later:** \Microsoft\PolicyManager\default\Update\PauseFeatureUpdatesStartDate |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\Pause |
You can check the date that Feature Updates were paused by checking the registry key **PausedFeatureDate** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings**.
The local group policy editor (GPEdit.msc) will not reflect whether the Feature Update pause period has expired. Although the device will resume Feature Updates after 35 days automatically, the pause checkbox will remain selected in the policy editor. To check whether a device has automatically resumed taking Feature Updates, check the status registry key **PausedFeatureStatus** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings** for the following values:
| Value | Status|
| --- | --- |
| 0 | Feature Updates not paused |
| 1 | Feature Updates paused |
| 2 | Feature Updates have auto-resumed after being paused |
>[!NOTE]
>If not configured by policy, individual users can pause feature updates by using **Settings > Update & security > Windows Update > Advanced options**.
Starting with Windows 10, version 1703, using Settings to control the pause behavior provides a more consistent experience, specifically:
- Any active restart notification are cleared or closed.
- Any pending restarts are canceled.
- Any pending update installations are canceled.
- Any update installation running when pause is activated will attempt to roll back.
## Configure when devices receive Quality Updates
Quality Updates are typically published on the first Tuesday of every month, although they can be released at any time. You can define if, and for how long, you would like to defer receiving Quality Updates following their availability. You can defer receiving these Quality Updates for a period of up to 35 days from their release by setting the **DeferQualityUpdatesPeriodinDays** value.
You can set your system to receive updates for other Microsoft products—known as Microsoft Updates (such as Microsoft Office, Visual Studio)—along with Windows Updates by setting the **AllowMUUpdateService** policy. When you do this, these Microsoft Updates will follow the same deferral and pause rules as all other Quality Updates.
>[!IMPORTANT]
>This policy defers both Feature and Quality Updates on Windows 10 Mobile Enterprise.
**Policy settings for deferring quality updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Quality Updates are received** | \Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdates</br>\Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdatesPeriodInDays |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\DeferUpdatePeriod |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferQualityUpdatesPeriodInDays** | \Microsoft\PolicyManager\default\Update\DeferQualityUpdatesPeriodInDays |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\RequireDeferUpdate |
>[!NOTE]
>If not configured by policy, individual users can defer quality updates by using **Settings > Update & security > Windows Update > Advanced options**.
## Pause quality updates
You can also pause a system from receiving Quality Updates for a period of up to 35 days from when the value is set. After 35 days has passed, the pause setting will automatically expire and the device will scan Windows Update for applicable quality Updates. Following this scan, you can then pause quality Updates for the device again.
Starting with Windows 10, version 1703, when you configure a pause by using policy, you must set a start date for the pause to begin. The pause period is calculated by adding 35 days to this start date.
In cases where the pause policy is first applied after the configured start date has passed, you can extend the pause period up to a total of 35 days by configuring a later start date.
>[!NOTE]
>Starting with Windows 10, version 1809, IT administrators can prevent individual users from pausing updates.
**Policy settings for pausing quality updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Quality Updates are received** |**1607:** \Policies\Microsoft\Windows\WindowsUpdate\PauseQualityUpdates</br>**1703:** \Policies\Microsoft\Windows\WindowsUpdate\PauseQualityUpdatesStartTime |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\Pause |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**PauseQualityUpdates** | **1607:** \Microsoft\PolicyManager\default\Update\PauseQualityUpdates</br>**1703:** \Microsoft\PolicyManager\default\Update\PauseQualityUpdatesStartTime |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\Pause |
You can check the date that quality Updates were paused by checking the registry key **PausedQualityDate** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings**.
The local group policy editor (GPEdit.msc) will not reflect whether the quality Update pause period has expired. Although the device will resume quality Updates after 35 days automatically, the pause checkbox will remain selected in the policy editor. To check whether a device has automatically resumed taking quality Updates, check the status registry key **PausedQualityStatus** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings** for the following values:
| Value | Status|
| --- | --- |
| 0 | Quality Updates not paused |
| 1 | Quality Updates paused |
| 2 | Quality Updates have auto-resumed after being paused |
>[!NOTE]
>If not configured by policy, individual users can pause quality updates by using **Settings > Update & security > Windows Update > Advanced options**.
Starting with Windows 10, version 1703, using Settings to control the pause behavior provides a more consistent experience, specifically:
- Any active restart notification are cleared or closed
- Any pending restarts are canceled
- Any pending update installations are canceled
- Any update installation running when pause is activated will attempt to rollback
## Configure when devices receive Windows Insider Preview builds
Starting with Windows 10, version 1709, you can set policies to manage preview builds and their delivery:
The **Manage preview builds** setting gives administrators control over enabling or disabling preview build installation on a device. You can also decide to stop preview builds once the release is public.
* Group Policy: **Computer Configuration/Administrative Templates/Windows Components/Windows Update/Windows Update for Business** - *Manage preview builds*
* MDM: **Update/ManagePreviewBuilds**
* System Center Configuration Manager: **Enable dual scan, manage through Windows Update for Business policy**
>[!IMPORTANT]
>This policy replaces the "Toggle user control over Insider builds" policy under that is only supported up to Windows 10, version 1703. You can find the older policy here:
>* Group Policy: **Computer Configuration/Administrative Templates/Windows Components/Data Collection and Preview Builds/Toggle user control over Insider builds**
>* MDM: **System/AllowBuildPreview**
The policy settings to **Select when Feature Updates are received** allows you to choose between preview flight rings, and allows you to defer or pause their delivery.
* Group Policy: **Computer Configuration/Administrative Templates/Windows Components/Windows Update/ Windows Update for Business** - *Select when Preview Builds and Feature Updates are received*
* MDM: **Update/BranchReadinessLevel**
## Exclude drivers from Quality Updates
Starting with Windows 10, version 1607, you can selectively opt out of receiving driver update packages as part of your normal quality update cycle. This policy will not apply to updates to drivers provided with the operating system (which will be packaged within a security or critical update) or to Feature Updates, where drivers might be dynamically installed to ensure the Feature Update process can complete.
**Policy settings to exclude drivers**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Do not include drivers with Windows Updates** | \Policies\Microsoft\Windows\WindowsUpdate\ExcludeWUDriversInQualityUpdate |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**ExcludeWUDriversInQualityUpdate** | \Microsoft\PolicyManager\default\Update\ExcludeWUDriversInQualityUpdate |
## Summary: MDM and Group Policy settings for Windows 10, version 1703 and later
The following are quick-reference tables of the supported policy values for Windows Update for Business in Windows 10, version 1607 and later.
**GPO: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate**
| GPO Key | Key type | Value |
| --- | --- | --- |
| BranchReadinessLevel | REG_DWORD | 2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)</br> 4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)</br> 8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)</br> 16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-annual Channel </br>32: systems take Feature Updates from Semi-annual Channel </br>Note: Other value or absent: receive all applicable updates |
| DeferQualityUpdates | REG_DWORD | 1: defer quality updates</br>Other value or absent: don’t defer quality updates |
| DeferQualityUpdatesPeriodinDays | REG_DWORD | 0-35: defer quality updates by given days |
| PauseQualityUpdatesStartDate | REG_DWORD | 1: pause quality updates</br>Other value or absent: don’t pause quality updates |
|DeferFeatureUpdates | REG_DWORD | 1: defer feature updates</br>Other value or absent: don’t defer feature updates |
| DeferFeatureUpdatesPeriodinDays | REG_DWORD | 0-365: defer feature updates by given days |
| PauseFeatureUpdatesStartDate | REG_DWORD |1: pause feature updates</br>Other value or absent: don’t pause feature updates |
| ExcludeWUDriversInQualityUpdate | REG_DWORD | 1: exclude Windows Update drivers</br>Other value or absent: offer Windows Update drivers |
**MDM: HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\default\Update**
| MDM Key | Key type | Value |
| --- | --- | --- |
| BranchReadinessLevel | REG_DWORD |2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)</br> 4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)</br> 8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)</br> 16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-annual Channel </br>32: systems take Feature Updates from Semi-annual Channel </br>Note: Other value or absent: receive all applicable updates |
| DeferQualityUpdatesPeriodinDays | REG_DWORD | 0-35: defer quality updates by given days |
| PauseQualityUpdatesStartDate | REG_DWORD | 1: pause quality updates</br>Other value or absent: don’t pause quality updates |
| DeferFeatureUpdatesPeriodinDays | REG_DWORD | 0-365: defer feature updates by given days |
| PauseFeatureUpdatesStartDate | REG_DWORD | 1: pause feature updates</br>Other value or absent: don’t pause feature updates |
| ExcludeWUDriversinQualityUpdate | REG_DWORD | 1: exclude Windows Update drivers</br>Other value or absent: offer Windows Update drivers |
## Update devices to newer versions
Due to the changes in Windows Update for Business, Windows 10, version 1607 uses different GPO and MDM keys than those available in version 1511. Windows 10, version 1703 also uses a few GPO and MDM keys that are different from those available in version 1607. However, Windows Update for Business devices running older versions will still see their policies honored after they update to a newer version; the old policy keys will continue to exist with their values ported forward during the update. Following the update to a newer version, only the old keys will be populated and not the new version keys, until the newer keys are explicitly defined on the device by the administrator.
### How older version policies are respected on newer versions
When a device running a newer version sees an update available on Windows Update, the device first evaluates and executes the Windows Updates for Business policy keys for its current (newer) version. If these are not present, it then checks whether any of the older version keys are set and defer accordingly. Update keys for newer versions will always supersede the older equivalent.
### Comparing keys in Windows 10, version 1607 to Windows 10, version 1703
| Version 1607 key | Version 1703 key |
| --- | --- |
| PauseFeatureUpdates | PauseFeatureUpdatesStartTime |
| PauseQualityUpdates | PauseQualityUpdatesStartTime |
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Prepare servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md)
- [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md)
- [Assign devices to servicing channels for Windows 10 updates](waas-servicing-channels-windows-10-updates.md)
- [Optimize update delivery for Windows 10 updates](waas-optimize-windows-10-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)
- [Deploy Windows 10 updates using Windows Server Update Services](waas-manage-updates-wsus.md)
- [Deploy Windows 10 updates using System Center Configuration Manager](waas-manage-updates-configuration-manager.md)
- [Manage device restarts after updates](waas-restart.md)
---
title: Configure Windows Update for Business (Windows 10)
ms.reviewer:
manager: laurawi
description: You can use Group Policy or your mobile device management (MDM) service to configure Windows Update for Business settings for your devices.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.topic: article
---
# Configure Windows Update for Business
**Applies to**
- Windows 10
- Windows 10 Mobile
- Windows Server 2016
- Windows Server 2019
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
You can use Group Policy or your mobile device management (MDM) service to configure Windows Update for Business settings for your devices. The sections in this topic provide the Group Policy and MDM policies for Windows 10, version 1511 and above. The MDM policies use the OMA-URI setting from the [Policy CSP](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx).
> [!IMPORTANT]
> Beginning with Windows 10, version 1903, organizations can use Windows Update for Business policies, regardless of the diagnostic data level chosen. If the diagnostic data level is set to **0 (Security)**, Windows Update for Business policies will still be honored. For instructions, see [Configure the operating system diagnostic data level](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization#diagnostic-data-levels).
Some Windows Update for Business policies are not applicable or behave differently for devices running Windows 10 Mobile Enterprise. Specifically, policies pertaining to Feature Updates will not be applied to Windows 10 Mobile Enterprise. All Windows 10 Mobile updates are recognized as Quality Updates, and can only be deferred or paused using the Quality Update policy settings. Additional information is provided in this topic and in [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md).
## Start by grouping devices
By grouping devices with similar deferral periods, administrators are able to cluster devices into deployment or validation groups which can be as a quality control measure as updates are deployed in Windows 10. With deferral windows and the ability to pause updates, administrators can effectively control and measure update deployments, updating a small pool of devices first to verify quality, prior to a broader roll-out to their organization. For more information, see [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md).
>[!TIP]
>In addition to setting up multiple rings for your update deployments, also incorporate devices enrolled in the Windows Insider Program as part of your deployment strategy. This will provide you the chance to not only evaluate new features before they are broadly available to the public, but it also increases the lead time to provide feedback and influence Microsoft’s design on functional aspects of the product. For more information on Windows Insider program, see [https://insider.windows.com/](https://insider.windows.com/).
<span id="configure-devices-for-current-branch-or-current-branch-for-business"/>
## Configure devices for the appropriate service channel
With Windows Update for Business, you can set a device to be on either Windows Insider Preview or the Semi-Annual Channel servicing branch. For more information on this servicing model, see [Windows 10 servicing options](waas-overview.md#servicing-channels).
**Release branch policies**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 or later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Feature Updates are received** | \Policies\Microsoft\Windows\WindowsUpdate\BranchReadinessLevel |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\DeferUpgrade |
| MDM for Windows 10, version 1607 or later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**BranchReadinessLevel** | \Microsoft\PolicyManager\default\Update\BranchReadinessLevel |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**RequireDeferUpgrade** | \Microsoft\PolicyManager\default\Update\RequireDeferUpgrade |
Starting with Windows 10, version 1703, users can configure the branch readiness level for their device by using **Settings > Update & security > Windows Update > Advanced options**.
![Branch readiness level setting](images/waas-wufb-settings-branch.jpg)
>[!NOTE]
>Users will not be able to change this setting if it was configured by policy.
## Configure when devices receive feature updates
After you configure the servicing branch (Windows Insider Preview or Semi-Annual Channel), you can then define if, and for how long, you would like to defer receiving Feature Updates following their availability from Microsoft on Windows Update. You can defer receiving these Feature Updates for a period of up to 365 days from their release by setting the `DeferFeatureUpdatesPeriodinDays` value.
For example, a device on the Semi-Annual Channel with `DeferFeatureUpdatesPeriodinDays=30` will not install a feature update that is first publicly available on Windows Update in September until 30 days later, in October.
</br></br>
**Policy settings for deferring feature updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Feature Updates are received** | \Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdates</br>\Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdatesPeriodInDays |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\DeferUpgradePeriod |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferFeatureUpdatesPeriodInDays** | \Microsoft\PolicyManager\default\Update\DeferFeatureUpdatesPeriodInDays |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\RequireDeferUpgrade |
>[!NOTE]
>If not configured by policy, individual users can defer feature updates by using **Settings > Update & security > Windows Update > Advanced options**.
## Pause feature updates
You can also pause a device from receiving Feature Updates by a period of up to 35 days from when the value is set. After 35 days has passed, the pause setting will automatically expire and the device will scan Windows Update for applicable Feature Updates. Following this scan, you can then pause Feature Updates for the device again.
Starting with Windows 10, version 1703, when you configure a pause by using policy, you must set a start date for the pause to begin. The pause period is calculated by adding 35 days to this start date.
In cases where the pause policy is first applied after the configured start date has passed, you can extend the pause period up to a total of 35 days by configuring a later start date.
>[!IMPORTANT]
>
>In Windows 10, version 1703 and later versions, you can pause feature updates to 35 days, similar to the number of days for quality updates.
**Policy settings for pausing feature updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Feature Updates are received** | **1607:** \Policies\Microsoft\Windows\WindowsUpdate\PauseFeatureUpdates</br>**1703 and later:** \Policies\Microsoft\Windows\WindowsUpdate\PauseFeatureUpdatesStartDate |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\Pause |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**PauseFeatureUpdates** | **1607:** \Microsoft\PolicyManager\default\Update\PauseFeatureUpdates</br> **1703 and later:** \Microsoft\PolicyManager\default\Update\PauseFeatureUpdatesStartDate |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\Pause |
You can check the date that Feature Updates were paused by checking the registry key **PausedFeatureDate** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings**.
The local group policy editor (GPEdit.msc) will not reflect whether the Feature Update pause period has expired. Although the device will resume Feature Updates after 35 days automatically, the pause checkbox will remain selected in the policy editor. To check whether a device has automatically resumed taking Feature Updates, check the status registry key **PausedFeatureStatus** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings** for the following values:
| Value | Status|
| --- | --- |
| 0 | Feature Updates not paused |
| 1 | Feature Updates paused |
| 2 | Feature Updates have auto-resumed after being paused |
>[!NOTE]
>If not configured by policy, individual users can pause feature updates by using **Settings > Update & security > Windows Update > Advanced options**.
Starting with Windows 10, version 1703, using Settings to control the pause behavior provides a more consistent experience, specifically:
- Any active restart notification are cleared or closed.
- Any pending restarts are canceled.
- Any pending update installations are canceled.
- Any update installation running when pause is activated will attempt to roll back.
## Configure when devices receive Quality Updates
Quality Updates are typically published on the first Tuesday of every month, although they can be released at any time. You can define if, and for how long, you would like to defer receiving Quality Updates following their availability. You can defer receiving these Quality Updates for a period of up to 35 days from their release by setting the **DeferQualityUpdatesPeriodinDays** value.
You can set your system to receive updates for other Microsoft products—known as Microsoft Updates (such as Microsoft Office, Visual Studio)—along with Windows Updates by setting the **AllowMUUpdateService** policy. When you do this, these Microsoft Updates will follow the same deferral and pause rules as all other Quality Updates.
>[!IMPORTANT]
>This policy defers both Feature and Quality Updates on Windows 10 Mobile Enterprise.
**Policy settings for deferring quality updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Quality Updates are received** | \Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdates</br>\Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdatesPeriodInDays |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\DeferUpdatePeriod |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferQualityUpdatesPeriodInDays** | \Microsoft\PolicyManager\default\Update\DeferQualityUpdatesPeriodInDays |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\RequireDeferUpdate |
>[!NOTE]
>If not configured by policy, individual users can defer quality updates by using **Settings > Update & security > Windows Update > Advanced options**.
## Pause quality updates
You can also pause a system from receiving Quality Updates for a period of up to 35 days from when the value is set. After 35 days has passed, the pause setting will automatically expire and the device will scan Windows Update for applicable quality Updates. Following this scan, you can then pause quality Updates for the device again.
Starting with Windows 10, version 1703, when you configure a pause by using policy, you must set a start date for the pause to begin. The pause period is calculated by adding 35 days to this start date.
In cases where the pause policy is first applied after the configured start date has passed, you can extend the pause period up to a total of 35 days by configuring a later start date.
>[!NOTE]
>Starting with Windows 10, version 1809, IT administrators can prevent individual users from pausing updates.
**Policy settings for pausing quality updates**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > Defer Windows Updates > **Select when Quality Updates are received** |**1607:** \Policies\Microsoft\Windows\WindowsUpdate\PauseQualityUpdates</br>**1703:** \Policies\Microsoft\Windows\WindowsUpdate\PauseQualityUpdatesStartTime |
| GPO for Windows 10, version 1511: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Defer Upgrades and Updates** | \Policies\Microsoft\Windows\WindowsUpdate\Pause |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**PauseQualityUpdates** | **1607:** \Microsoft\PolicyManager\default\Update\PauseQualityUpdates</br>**1703:** \Microsoft\PolicyManager\default\Update\PauseQualityUpdatesStartTime |
| MDM for Windows 10, version 1511: </br>../Vendor/MSFT/Policy/Config/Update/</br>**DeferUpgrade** | \Microsoft\PolicyManager\default\Update\Pause |
You can check the date that quality Updates were paused by checking the registry key **PausedQualityDate** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings**.
The local group policy editor (GPEdit.msc) will not reflect whether the quality Update pause period has expired. Although the device will resume quality Updates after 35 days automatically, the pause checkbox will remain selected in the policy editor. To check whether a device has automatically resumed taking quality Updates, check the status registry key **PausedQualityStatus** under **HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\Settings** for the following values:
| Value | Status|
| --- | --- |
| 0 | Quality Updates not paused |
| 1 | Quality Updates paused |
| 2 | Quality Updates have auto-resumed after being paused |
>[!NOTE]
>If not configured by policy, individual users can pause quality updates by using **Settings > Update & security > Windows Update > Advanced options**.
Starting with Windows 10, version 1703, using Settings to control the pause behavior provides a more consistent experience, specifically:
- Any active restart notification are cleared or closed
- Any pending restarts are canceled
- Any pending update installations are canceled
- Any update installation running when pause is activated will attempt to rollback
## Configure when devices receive Windows Insider Preview builds
Starting with Windows 10, version 1709, you can set policies to manage preview builds and their delivery:
The **Manage preview builds** setting gives administrators control over enabling or disabling preview build installation on a device. You can also decide to stop preview builds once the release is public.
* Group Policy: **Computer Configuration/Administrative Templates/Windows Components/Windows Update/Windows Update for Business** - *Manage preview builds*
* MDM: **Update/ManagePreviewBuilds**
* System Center Configuration Manager: **Enable dual scan, manage through Windows Update for Business policy**
>[!IMPORTANT]
>This policy replaces the "Toggle user control over Insider builds" policy under that is only supported up to Windows 10, version 1703. You can find the older policy here:
>* Group Policy: **Computer Configuration/Administrative Templates/Windows Components/Data Collection and Preview Builds/Toggle user control over Insider builds**
>* MDM: **System/AllowBuildPreview**
The policy settings to **Select when Feature Updates are received** allows you to choose between preview flight rings, and allows you to defer or pause their delivery.
* Group Policy: **Computer Configuration/Administrative Templates/Windows Components/Windows Update/ Windows Update for Business** - *Select when Preview Builds and Feature Updates are received*
* MDM: **Update/BranchReadinessLevel**
## Exclude drivers from Quality Updates
Starting with Windows 10, version 1607, you can selectively opt out of receiving driver update packages as part of your normal quality update cycle. This policy will not apply to updates to drivers provided with the operating system (which will be packaged within a security or critical update) or to Feature Updates, where drivers might be dynamically installed to ensure the Feature Update process can complete.
**Policy settings to exclude drivers**
| Policy | Sets registry key under **HKLM\Software** |
| --- | --- |
| GPO for Windows 10, version 1607 and later: </br>Computer Configuration > Administrative Templates > Windows Components > Windows Update > **Do not include drivers with Windows Updates** | \Policies\Microsoft\Windows\WindowsUpdate\ExcludeWUDriversInQualityUpdate |
| MDM for Windows 10, version 1607 and later: </br>../Vendor/MSFT/Policy/Config/Update/</br>**ExcludeWUDriversInQualityUpdate** | \Microsoft\PolicyManager\default\Update\ExcludeWUDriversInQualityUpdate |
## Summary: MDM and Group Policy settings for Windows 10, version 1703 and later
The following are quick-reference tables of the supported policy values for Windows Update for Business in Windows 10, version 1607 and later.
**GPO: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate**
| GPO Key | Key type | Value |
| --- | --- | --- |
| BranchReadinessLevel | REG_DWORD | 2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)</br> 4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)</br> 8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)</br> 16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-annual Channel </br>32: systems take Feature Updates from Semi-annual Channel </br>Note: Other value or absent: receive all applicable updates |
| DeferQualityUpdates | REG_DWORD | 1: defer quality updates</br>Other value or absent: don’t defer quality updates |
| DeferQualityUpdatesPeriodinDays | REG_DWORD | 0-35: defer quality updates by given days |
| PauseQualityUpdatesStartDate | REG_DWORD | 1: pause quality updates</br>Other value or absent: don’t pause quality updates |
|DeferFeatureUpdates | REG_DWORD | 1: defer feature updates</br>Other value or absent: don’t defer feature updates |
| DeferFeatureUpdatesPeriodinDays | REG_DWORD | 0-365: defer feature updates by given days |
| PauseFeatureUpdatesStartDate | REG_DWORD |1: pause feature updates</br>Other value or absent: don’t pause feature updates |
| ExcludeWUDriversInQualityUpdate | REG_DWORD | 1: exclude Windows Update drivers</br>Other value or absent: offer Windows Update drivers |
**MDM: HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\default\Update**
| MDM Key | Key type | Value |
| --- | --- | --- |
| BranchReadinessLevel | REG_DWORD |2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)</br> 4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)</br> 8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)</br> 16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-annual Channel </br>32: systems take Feature Updates from Semi-annual Channel </br>Note: Other value or absent: receive all applicable updates |
| DeferQualityUpdatesPeriodinDays | REG_DWORD | 0-35: defer quality updates by given days |
| PauseQualityUpdatesStartDate | REG_DWORD | 1: pause quality updates</br>Other value or absent: don’t pause quality updates |
| DeferFeatureUpdatesPeriodinDays | REG_DWORD | 0-365: defer feature updates by given days |
| PauseFeatureUpdatesStartDate | REG_DWORD | 1: pause feature updates</br>Other value or absent: don’t pause feature updates |
| ExcludeWUDriversinQualityUpdate | REG_DWORD | 1: exclude Windows Update drivers</br>Other value or absent: offer Windows Update drivers |
## Update devices to newer versions
Due to the changes in Windows Update for Business, Windows 10, version 1607 uses different GPO and MDM keys than those available in version 1511. Windows 10, version 1703 also uses a few GPO and MDM keys that are different from those available in version 1607. However, Windows Update for Business devices running older versions will still see their policies honored after they update to a newer version; the old policy keys will continue to exist with their values ported forward during the update. Following the update to a newer version, only the old keys will be populated and not the new version keys, until the newer keys are explicitly defined on the device by the administrator.
### How older version policies are respected on newer versions
When a device running a newer version sees an update available on Windows Update, the device first evaluates and executes the Windows Updates for Business policy keys for its current (newer) version. If these are not present, it then checks whether any of the older version keys are set and defer accordingly. Update keys for newer versions will always supersede the older equivalent.
### Comparing keys in Windows 10, version 1607 to Windows 10, version 1703
| Version 1607 key | Version 1703 key |
| --- | --- |
| PauseFeatureUpdates | PauseFeatureUpdatesStartTime |
| PauseQualityUpdates | PauseQualityUpdatesStartTime |
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Prepare servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md)
- [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md)
- [Assign devices to servicing channels for Windows 10 updates](waas-servicing-channels-windows-10-updates.md)
- [Optimize update delivery for Windows 10 updates](waas-optimize-windows-10-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)
- [Deploy Windows 10 updates using Windows Server Update Services](waas-manage-updates-wsus.md)
- [Deploy Windows 10 updates using System Center Configuration Manager](waas-manage-updates-configuration-manager.md)
- [Manage device restarts after updates](waas-restart.md)

467
windows/deployment/update/waas-delivery-optimization-reference.md
View File

@ -1,233 +1,234 @@
---
title: Delivery Optimization reference
ms.reviewer:
manager: laurawi
description: Reference of all Delivery Optimization settings and descriptions of same
keywords: oms, operations management suite, wdav, updates, downloads, log analytics
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Delivery Optimization reference
**Applies to**
- Windows 10
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
There are a great many details you can set in Delivery Optimization to customize it to do just what you need it to. This topic summarizes them for your reference.
## Delivery Optimization options
You can use Group Policy or an MDM solution like Intune to configure Delivery Optimization.
You will find the Delivery Optimization settings in Group Policy under **Configuration\Policies\Administrative Templates\Windows Components\Delivery Optimization**.
In MDM, the same settings are under **.Vendor/MSFT/Policy/Config/DeliveryOptimization/**.
[//]: # (something about Intune UX--perhaps link to relevant Intune docs?)
### Summary of Delivery Optimization settings :
| Group Policy setting | MDM setting | Supported from version |
| --- | --- | --- |
| [Download mode](#download-mode) | DODownloadMode | 1511 |
| [Group ID](#group-id) | DOGroupID | 1511 |
| [Minimum RAM (inclusive) allowed to use Peer Caching](#minimum-ram-inclusive-allowed-to-use-peer-caching) | DOMinRAMAllowedToPeer | 1703 |
| [Minimum disk size allowed to use Peer Caching](#minimum-disk-size-allowed-to-use-peer-caching) | DOMinDiskSizeAllowedToPeer | 1703 |
| [Max Cache Age](#max-cache-age) | DOMaxCacheAge | 1511 |
| [Max Cache Size](#max-cache-size) | DOMaxCacheSize | 1511 |
| [Absolute Max Cache Size](#absolute-max-cache-size) | DOAbsoluteMaxCacheSize | 1607 |
| [Modify Cache Drive](#modify-cache-drive) | DOModifyCacheDrive | 1607 |
| [Minimum Peer Caching Content File Size](#minimum-peer-caching-content-file-size) | DOMinFileSizeToCache | 1703 |
| [Maximum Download Bandwidth](#maximum-download-bandwidth) | DOMaxDownloadBandwidth | 1607 |
| [Percentage of Maximum Download Bandwidth](#percentage-of-maximum-download-bandwidth) | DOPercentageMaxDownloadBandwidth | 1607 |
| [Max Upload Bandwidth](#max-upload-bandwidth) | DOMaxUploadBandwidth | 1607 |
| [Monthly Upload Data Cap](#monthly-upload-data-cap) | DOMonthlyUploadDataCap | 1607 |
| [Minimum Background QoS](#minimum-background-qos) | DOMinBackgroundQoS | 1607 |
| [Enable Peer Caching while the device connects via VPN](#enable-peer-caching-while-the-device-connects-via-vpn) | DOAllowVPNPeerCaching | 1709 |
| [Allow uploads while the device is on battery while under set Battery level](#allow-uploads-while-the-device-is-on-battery-while-under-set-battery-level) | DOMinBatteryPercentageAllowedToUpload | 1709 |
| [MaxForegroundDownloadBandwidth](#maximum-foreground-download-bandwidth) | DOPercentageMaxForegroundBandwidth | 1803 |
| [MaxBackgroundDownloadBandwidth](#maximum-background-download-bandwidth) | DOPercentageMaxBackgroundBandwidth | 1803 |
| [SetHoursToLimitBackgroundDownloadBandwidth](#set-business-hours-to-limit-background-download-bandwidth) | DOSetHoursToLimitBackgroundDownloadBandwidth | 1803 |
| [SetHoursToLimitForegroundDownloadBandwidth](#set-business-hours-to-limit-foreground-download-bandwidth) |DOSetHoursToLimitForegroundDownloadBandwidth | 1803 |
| [Select a method to restrict Peer Selection](#select-a-method-to-restrict-peer-selection) |DORestrictPeerSelectionBy | 1803 |
| [Select the source of Group IDs](#select-the-source-of-group-ids) | DOGroupIDSource | 1803 |
| [Delay background download from http (in secs)](#delay-background-download-from-http-in-secs) | DODelayBackgroundDownloadFromHttp | 1803 |
| [Delay foreground download from http (in secs)](#delay-foreground-download-from-http-in-secs) | DODelayForegroundDownloadFromHttp | 1803 |
| [Delay foreground download cache server fallback (in secs)](#delay-foreground-download-cache-server-fallback-in-secs) | DelayCacheServerFallbackForeground | 1903 |
| [Delay background download cache server fallback (in secs)](#delay-background-download-cache-server-fallback-in-secs) | DelayCacheServerFallbackBackground | 1903 |
### More detail on Delivery Optimization settings:
[Group ID](#group-id), combined with Group [Download mode](#download-mode), enables administrators to create custom device groups that will share content between devices in the group.
Delivery Optimization uses locally cached updates. In cases where devices have ample local storage and you would like to cache more content, or if you have limited storage and would like to cache less, use the following settings to adjust the Delivery Optimization cache to suit your scenario:
- [Max Cache Size](#max-cache-size) and [Absolute Max Cache Size](#absolute-max-cache-size) control the amount of space the Delivery Optimization cache can use.
- [Max Cache Age](#max-cache-age) controls the retention period for each update in the cache.
- The system drive is the default location for the Delivery Optimization cache. [Modify Cache Drive](#modify-cache-drive) allows administrators to change that location.
>[!NOTE]
>It is possible to configure preferred cache devices. For more information, see [Group ID](#group-id).
All cached files have to be above a set minimum size. This size is automatically set by the Delivery Optimization cloud services, but when local storage is sufficient and the network isn't strained or congested, administrators might choose to change it to obtain increased performance. You can set the minimum size of files to cache by adjusting [Minimum Peer Caching Content File Size](#minimum-peer-caching-content-file-size).
Additional options available that control the impact Delivery Optimization has on your network include the following:
- [Maximum Download Bandwidth](#maximum-download-bandwidth) and [Percentage of Maximum Download Bandwidth](#percentage-of-maximum-download-bandwidth) control the download bandwidth used by Delivery Optimization.
- [Max Upload Bandwidth](#max-upload-bandwidth) controls the Delivery Optimization upload bandwidth usage.
- [Monthly Upload Data Cap](#monthly-upload-data-cap) controls the amount of data a client can upload to peers each month.
- [Minimum Background QoS](#minimum-background-qos) lets administrators guarantee a minimum download speed for Windows updates. This is achieved by adjusting the amount of data downloaded directly from Windows Update or WSUS servers, rather than other peers in the network.
- [Maximum Foreground Download Bandwidth](#maximum-foreground-download-bandwidth) specifies the **maximum foreground download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth.
- [Maximum Background Download Bandwidth](#maximum-background-download-bandwidth) specifies the **maximum background download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth.
- [Set Business Hours to Limit Background Download Bandwidth](#set-business-hours-to-limit-background-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
- [Set Business Hours to Limit Foreground Download Bandwidth](#set-business-hours-to-limit-foreground-download-bandwidth) specifies the maximum foreground download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
- [Select a method to restrict Peer Selection](#select-a-method-to-restrict-peer-selection) restricts peer selection by the options you select.
- [Select the source of Group IDs](#select-the-source-of-group-ids) restricts peer selection to a specific source.
- [Delay background download from http (in secs)](#delay-background-download-from-http-in-secs) allows you to delay the use of an HTTP source in a background download that is allowed to use P2P.
- [Delay foreground download from http (in secs)](#delay-foreground-download-from-http-in-secs) allows you to delay the use of an HTTP source in a foreground (interactive) download that is allowed to use P2P.
Administrators can further customize scenarios where Delivery Optimization will be used with the following settings:
- [Minimum RAM (inclusive) allowed to use Peer Caching](#minimum-ram-inclusive-allowed-to-use-peer-caching) sets the minimum RAM required for peer caching to be enabled.
- [Minimum disk size allowed to use Peer Caching](#minimum-disk-size-allowed-to-use-peer-caching) sets the minimum disk size required for peer caching to be enabled.
- [Enable Peer Caching while the device connects via VPN](#enable-peer-caching-while-the-device-connects-via-vpn) allows clients connected through VPN to use peer caching.
- [Allow uploads while the device is on battery while under set Battery level](#allow-uploads-while-the-device-is-on-battery-while-under-set-battery-level) controls the minimum battery level required for uploads to occur. You must enable this policy to allow upload while on battery.
### Download mode
Download mode dictates which download sources clients are allowed to use when downloading Windows updates in addition to Windows Update servers. The following table shows the available download mode options and what they do. Additional technical details for these policies are available in [Policy CSP - Delivery Optimization](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-deliveryoptimization).
| Download mode option | Functionality when set |
| --- | --- |
| HTTP Only (0) | This setting disables peer-to-peer caching but still allows Delivery Optimization to download content over HTTP from the download's original source. This mode uses additional metadata provided by the Delivery Optimization cloud services for a peerless reliable and efficient download experience. |
| LAN (1 – Default) | This default operating mode for Delivery Optimization enables peer sharing on the same network. The Delivery Optimization cloud service finds other clients that connect to the Internet using the same public IP as the target client. These clients then attempts to connect to other peers on the same network by using their private subnet IP.|
| Group (2) | When group mode is set, the group is automatically selected based on the device’s Active Directory Domain Services (AD DS) site (Windows 10, version 1607) or the domain the device is authenticated to (Windows 10, version 1511). In group mode, peering occurs across internal subnets, between devices that belong to the same group, including devices in remote offices. You can use GroupID option to create your own custom group independently of domains and AD DS sites. Starting with Windows 10, version 1803, you can use the GroupIDSource parameter to take advantage of other method to create groups dynamically. Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization. |
| Internet (3) | Enable Internet peer sources for Delivery Optimization. |
| Simple (99) | Simple mode disables the use of Delivery Optimization cloud services completely (for offline environments). Delivery Optimization switches to this mode automatically when the Delivery Optimization cloud services are unavailable, unreachable or when the content file size is less than 10 MB. In this mode, Delivery Optimization provides a reliable download experience, with no peer-to-peer caching. |
|Bypass (100) | Bypass Delivery Optimization and use BITS, instead. You should only select this mode if you use WSUS and prefer to use BranchCache. You do not need to set this option if you are using SCCM. If you want to disable peer-to-peer functionality, it's best to set **DownloadMode** to **0** or **99**. |
>[!NOTE]
>Group mode is a best-effort optimization and should not be relied on for an authentication of identity of devices participating in the group.
### Group ID
By default, peer sharing on clients using the group download mode is limited to the same domain in Windows 10, version 1511, and the same domain and AD DS site in Windows 10, version 1607. By using the Group ID setting, you can optionally create a custom group that contains devices that should participate in Delivery Optimization but do not fall within those domain or AD DS site boundaries, including devices in another domain. Using Group ID, you can further restrict the default group (for example, you could create a sub-group representing an office building), or extend the group beyond the domain, allowing devices in multiple domains in your organization to be peers. This setting requires the custom group to be specified as a GUID on each device that participates in the custom group.
[//]: # (SCCM Boundary Group option; GroupID Source policy)
>[!NOTE]
>To generate a GUID using Powershell, use [```[guid]::NewGuid()```](https://blogs.technet.microsoft.com/heyscriptingguy/2013/07/25/powertip-create-a-new-guid-by-using-powershell/)
>
>This configuration is optional and not required for most implementations of Delivery Optimization.
### Select the source of Group IDs
Starting in Windows 10, version 1803, set this policy to restrict peer selection to a specific source. The options are:
- 0 = not set
- 1 = AD Site
- 2 = Authenticated domain SID
- 3 = DHCP Option ID (with this option, the client will query DHCP Option ID 234 and use the returned GUID value as the Group ID)
- 4 = DNS Suffix
When set, the Group ID is assigned automatically from the selected source. If you set this policy, the GroupID policy will be ignored. The option set in this policy only applies to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored. If you set the value to anything other than 0-4, the policy is ignored.
### Minimum RAM (inclusive) allowed to use Peer Caching
This setting specifies the minimum RAM size in GB required to use Peer Caching. For example if the minimum set is 1 GB, then devices with 1 GB or higher available RAM will be allowed to use Peer caching. The recommended values are 1 to 4 GB, and the default value is 4 GB.
### Minimum disk size allowed to use Peer Caching
This setting specifies the required minimum disk size (capacity in GB) for the device to use Peer Caching. The recommended values are 64 to 256 GB, and the default value is 32 GB.
>[!NOTE]
>If the [Modify Cache Drive](#modify-cache-drive) policy is set, the disk size check will apply to the new working directory specified by this policy.
### Max Cache Age
In environments configured for Delivery Optimization, you might want to set an expiration on cached updates and Windows application installation files. If so, this setting defines the maximum number of seconds each file can be held in the Delivery Optimization cache on each Windows 10 client device. The default Max Cache Age value is 259,200 seconds (3 days). Alternatively, organizations might choose to set this value to “0” which means “unlimited” to avoid peers re-downloading content. When “Unlimited” value is set, Delivery Optimization will hold the files in the cache longer and will clean up the cache as needed (for example when the cache size exceeded the maximum space allowed).
### Max Cache Size
This setting limits the maximum amount of space the Delivery Optimization cache can use as a percentage of the available drive space, from 1 to 100. For example, if you set this value to 10 on a Windows 10 client device that has 100 GB of available drive space, then Delivery Optimization will use up to 10 GB of that space. Delivery Optimization will constantly assess the available drive space and automatically clear the cache to keep the maximum cache size under the set percentage. The default value for this setting is 20.
### Absolute Max Cache Size
This setting specifies the maximum number of gigabytes the Delivery Optimization cache can use. This is different from the [**Max Cache Size**](#max-cache-size) setting, which is a percentage of available disk space. Also, if you configure this policy, it will override the [**Max Cache Size**](#max-cache-size) setting. The default value for this setting is 10 GB.
### Minimum Peer Caching Content File Size
This setting specifies the minimum content file size in MB enabled to use Peer Caching. The recommended values are from 1 to 100000 MB.
### Maximum Download Bandwidth
This setting specifies the maximum download bandwidth that can be used across all concurrent Delivery Optimization downloads in kilobytes per second (KB/s). A default value of 0 means that Delivery Optimization will dynamically adjust and optimize the maximum bandwidth used.
### Maximum Foreground Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum foreground download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set.
### Maximum Background Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set.
### Percentage of Maximum Download Bandwidth
This setting specifies the maximum download bandwidth that Delivery Optimization can use across all concurrent download activities as a percentage of available download bandwidth. The default value 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for downloads.
### Max Upload Bandwidth
This setting allows you to limit the amount of upload bandwidth individual clients can use for Delivery Optimization. Consider this setting when clients are providing content to requesting peers on the network. This option is set in kilobytes per second (KB/s). The default setting is 0, or “unlimited” which means Delivery Optimization dynamically optimizes for minimal usage of upload bandwidth; however it does not cap the upload bandwidth rate at a set rate.
### Set Business Hours to Limit Background Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
### Set Business Hours to Limit Foreground Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum foreground download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
### Select a method to restrict peer selection
Starting in Windows 10, version 1803, set this policy to restrict peer selection via selected option.
Currently the only available option is **1 = Subnet mask** This option (Subnet mask) applies to both Download Modes LAN (1) and Group (2).
### Delay background download from http (in secs)
Starting in Windows 10, version 1803, this allows you to delay the use of an HTTP source in a background download that is allowed to use peer-to-peer.
### Delay foreground download from http (in secs)
Starting in Windows 10, version 1803, allows you to delay the use of an HTTP source in a foreground (interactive) download that is allowed to use peer-to-peer.
### Delay Foreground Download Cache Server Fallback (in secs)
Starting in Windows 10, version 1903, allows you to delay the fallback from cache server to the HTTP source for foreground content download by X seconds. If you set the policy to delay foreground download from http, it will apply first (to allow downloads from peers first).
### Delay Background Download Cache Server Fallback (in secs)
Starting in Windows 10, version 1903, set this policy to delay the fallback from cache server to the HTTP source for a background content download by X seconds. If you set the policy to delay background download from http, it will apply first (to allow downloads from peers first).
### Minimum Background QoS
This value specifies the minimum download speed guarantee that a client attempts to achieve and will fulfill by downloading more kilobytes from Windows Update servers or WSUS. Simply put, the lower this value is, the more content will be sourced using peers on the network rather than Windows Update. The higher this value, the more content is received from Windows Update servers or WSUS, versus peers on the local network.
### Modify Cache Drive
This setting allows for an alternate Delivery Optimization cache location on the clients. By default, the cache is stored on the operating system drive through the %SYSTEMDRIVE% environment variable. You can set the value to an environment variable (e.g., %SYSTEMDRIVE%), a drive letter (e.g., D:), or a folder path (e.g., D:\DOCache).
### Monthly Upload Data Cap
This setting specifies the total amount of data in gigabytes that a Delivery Optimization client can upload to Internet peers per month. A value of 0 means that an unlimited amount of data can be uploaded. The default value for this setting is 20 GB.
### Enable Peer Caching while the device connects via VPN
This setting determines whether a device will be allowed to participate in Peer Caching while connected to VPN. Specify "true" to allow the device to participate in Peer Caching while connected via VPN to the domain network. This means the device can download from or upload to other domain network devices, either on VPN or on the corporate domain network.
### Allow uploads while the device is on battery while under set Battery level
This setting specifies battery levels at which a device will be allowed to upload data. Specify any value between 1 and 100 (in percentage) to allow the device to upload data to LAN and Group peers while on DC power (Battery). Uploads will automatically pause when the battery level drops below the set minimum battery level. The recommended value to set if you allow uploads on battery is 40 (for 40%).
The device can download from peers while on battery regardless of this policy.
>[!IMPORTANT]
> By default, devices **will not upload while on battery**. To enable uploads while on battery, you need to enable this policy and set the battery value under which uploads pause.
---
title: Delivery Optimization reference
ms.reviewer:
manager: laurawi
description: Reference of all Delivery Optimization settings and descriptions of same
keywords: oms, operations management suite, wdav, updates, downloads, log analytics
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Delivery Optimization reference
**Applies to**
- Windows 10
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
There are a great many details you can set in Delivery Optimization to customize it to do just what you need it to. This topic summarizes them for your reference.
## Delivery Optimization options
You can use Group Policy or an MDM solution like Intune to configure Delivery Optimization.
You will find the Delivery Optimization settings in Group Policy under **Configuration\Policies\Administrative Templates\Windows Components\Delivery Optimization**.
In MDM, the same settings are under **.Vendor/MSFT/Policy/Config/DeliveryOptimization/**.
[//]: # (something about Intune UX--perhaps link to relevant Intune docs?)
### Summary of Delivery Optimization settings :
| Group Policy setting | MDM setting | Supported from version |
| --- | --- | --- |
| [Download mode](#download-mode) | DODownloadMode | 1511 |
| [Group ID](#group-id) | DOGroupID | 1511 |
| [Minimum RAM (inclusive) allowed to use Peer Caching](#minimum-ram-inclusive-allowed-to-use-peer-caching) | DOMinRAMAllowedToPeer | 1703 |
| [Minimum disk size allowed to use Peer Caching](#minimum-disk-size-allowed-to-use-peer-caching) | DOMinDiskSizeAllowedToPeer | 1703 |
| [Max Cache Age](#max-cache-age) | DOMaxCacheAge | 1511 |
| [Max Cache Size](#max-cache-size) | DOMaxCacheSize | 1511 |
| [Absolute Max Cache Size](#absolute-max-cache-size) | DOAbsoluteMaxCacheSize | 1607 |
| [Modify Cache Drive](#modify-cache-drive) | DOModifyCacheDrive | 1607 |
| [Minimum Peer Caching Content File Size](#minimum-peer-caching-content-file-size) | DOMinFileSizeToCache | 1703 |
| [Maximum Download Bandwidth](#maximum-download-bandwidth) | DOMaxDownloadBandwidth | 1607 |
| [Percentage of Maximum Download Bandwidth](#percentage-of-maximum-download-bandwidth) | DOPercentageMaxDownloadBandwidth | 1607 |
| [Max Upload Bandwidth](#max-upload-bandwidth) | DOMaxUploadBandwidth | 1607 |
| [Monthly Upload Data Cap](#monthly-upload-data-cap) | DOMonthlyUploadDataCap | 1607 |
| [Minimum Background QoS](#minimum-background-qos) | DOMinBackgroundQoS | 1607 |
| [Enable Peer Caching while the device connects via VPN](#enable-peer-caching-while-the-device-connects-via-vpn) | DOAllowVPNPeerCaching | 1709 |
| [Allow uploads while the device is on battery while under set Battery level](#allow-uploads-while-the-device-is-on-battery-while-under-set-battery-level) | DOMinBatteryPercentageAllowedToUpload | 1709 |
| [MaxForegroundDownloadBandwidth](#maximum-foreground-download-bandwidth) | DOPercentageMaxForegroundBandwidth | 1803 |
| [MaxBackgroundDownloadBandwidth](#maximum-background-download-bandwidth) | DOPercentageMaxBackgroundBandwidth | 1803 |
| [SetHoursToLimitBackgroundDownloadBandwidth](#set-business-hours-to-limit-background-download-bandwidth) | DOSetHoursToLimitBackgroundDownloadBandwidth | 1803 |
| [SetHoursToLimitForegroundDownloadBandwidth](#set-business-hours-to-limit-foreground-download-bandwidth) |DOSetHoursToLimitForegroundDownloadBandwidth | 1803 |
| [Select a method to restrict Peer Selection](#select-a-method-to-restrict-peer-selection) |DORestrictPeerSelectionBy | 1803 |
| [Select the source of Group IDs](#select-the-source-of-group-ids) | DOGroupIDSource | 1803 |
| [Delay background download from http (in secs)](#delay-background-download-from-http-in-secs) | DODelayBackgroundDownloadFromHttp | 1803 |
| [Delay foreground download from http (in secs)](#delay-foreground-download-from-http-in-secs) | DODelayForegroundDownloadFromHttp | 1803 |
| [Delay foreground download cache server fallback (in secs)](#delay-foreground-download-cache-server-fallback-in-secs) | DelayCacheServerFallbackForeground | 1903 |
| [Delay background download cache server fallback (in secs)](#delay-background-download-cache-server-fallback-in-secs) | DelayCacheServerFallbackBackground | 1903 |
### More detail on Delivery Optimization settings:
[Group ID](#group-id), combined with Group [Download mode](#download-mode), enables administrators to create custom device groups that will share content between devices in the group.
Delivery Optimization uses locally cached updates. In cases where devices have ample local storage and you would like to cache more content, or if you have limited storage and would like to cache less, use the following settings to adjust the Delivery Optimization cache to suit your scenario:
- [Max Cache Size](#max-cache-size) and [Absolute Max Cache Size](#absolute-max-cache-size) control the amount of space the Delivery Optimization cache can use.
- [Max Cache Age](#max-cache-age) controls the retention period for each update in the cache.
- The system drive is the default location for the Delivery Optimization cache. [Modify Cache Drive](#modify-cache-drive) allows administrators to change that location.
>[!NOTE]
>It is possible to configure preferred cache devices. For more information, see [Group ID](#group-id).
All cached files have to be above a set minimum size. This size is automatically set by the Delivery Optimization cloud services, but when local storage is sufficient and the network isn't strained or congested, administrators might choose to change it to obtain increased performance. You can set the minimum size of files to cache by adjusting [Minimum Peer Caching Content File Size](#minimum-peer-caching-content-file-size).
Additional options available that control the impact Delivery Optimization has on your network include the following:
- [Maximum Download Bandwidth](#maximum-download-bandwidth) and [Percentage of Maximum Download Bandwidth](#percentage-of-maximum-download-bandwidth) control the download bandwidth used by Delivery Optimization.
- [Max Upload Bandwidth](#max-upload-bandwidth) controls the Delivery Optimization upload bandwidth usage.
- [Monthly Upload Data Cap](#monthly-upload-data-cap) controls the amount of data a client can upload to peers each month.
- [Minimum Background QoS](#minimum-background-qos) lets administrators guarantee a minimum download speed for Windows updates. This is achieved by adjusting the amount of data downloaded directly from Windows Update or WSUS servers, rather than other peers in the network.
- [Maximum Foreground Download Bandwidth](#maximum-foreground-download-bandwidth) specifies the **maximum foreground download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth.
- [Maximum Background Download Bandwidth](#maximum-background-download-bandwidth) specifies the **maximum background download bandwidth** that Delivery Optimization uses, across all concurrent download activities, as a percentage of available download bandwidth.
- [Set Business Hours to Limit Background Download Bandwidth](#set-business-hours-to-limit-background-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
- [Set Business Hours to Limit Foreground Download Bandwidth](#set-business-hours-to-limit-foreground-download-bandwidth) specifies the maximum foreground download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
- [Select a method to restrict Peer Selection](#select-a-method-to-restrict-peer-selection) restricts peer selection by the options you select.
- [Select the source of Group IDs](#select-the-source-of-group-ids) restricts peer selection to a specific source.
- [Delay background download from http (in secs)](#delay-background-download-from-http-in-secs) allows you to delay the use of an HTTP source in a background download that is allowed to use P2P.
- [Delay foreground download from http (in secs)](#delay-foreground-download-from-http-in-secs) allows you to delay the use of an HTTP source in a foreground (interactive) download that is allowed to use P2P.
Administrators can further customize scenarios where Delivery Optimization will be used with the following settings:
- [Minimum RAM (inclusive) allowed to use Peer Caching](#minimum-ram-inclusive-allowed-to-use-peer-caching) sets the minimum RAM required for peer caching to be enabled.
- [Minimum disk size allowed to use Peer Caching](#minimum-disk-size-allowed-to-use-peer-caching) sets the minimum disk size required for peer caching to be enabled.
- [Enable Peer Caching while the device connects via VPN](#enable-peer-caching-while-the-device-connects-via-vpn) allows clients connected through VPN to use peer caching.
- [Allow uploads while the device is on battery while under set Battery level](#allow-uploads-while-the-device-is-on-battery-while-under-set-battery-level) controls the minimum battery level required for uploads to occur. You must enable this policy to allow upload while on battery.
### Download mode
Download mode dictates which download sources clients are allowed to use when downloading Windows updates in addition to Windows Update servers. The following table shows the available download mode options and what they do. Additional technical details for these policies are available in [Policy CSP - Delivery Optimization](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-deliveryoptimization).
| Download mode option | Functionality when set |
| --- | --- |
| HTTP Only (0) | This setting disables peer-to-peer caching but still allows Delivery Optimization to download content over HTTP from the download's original source. This mode uses additional metadata provided by the Delivery Optimization cloud services for a peerless reliable and efficient download experience. |
| LAN (1 – Default) | This default operating mode for Delivery Optimization enables peer sharing on the same network. The Delivery Optimization cloud service finds other clients that connect to the Internet using the same public IP as the target client. These clients then attempts to connect to other peers on the same network by using their private subnet IP.|
| Group (2) | When group mode is set, the group is automatically selected based on the device’s Active Directory Domain Services (AD DS) site (Windows 10, version 1607) or the domain the device is authenticated to (Windows 10, version 1511). In group mode, peering occurs across internal subnets, between devices that belong to the same group, including devices in remote offices. You can use GroupID option to create your own custom group independently of domains and AD DS sites. Starting with Windows 10, version 1803, you can use the GroupIDSource parameter to take advantage of other method to create groups dynamically. Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization. |
| Internet (3) | Enable Internet peer sources for Delivery Optimization. |
| Simple (99) | Simple mode disables the use of Delivery Optimization cloud services completely (for offline environments). Delivery Optimization switches to this mode automatically when the Delivery Optimization cloud services are unavailable, unreachable or when the content file size is less than 10 MB. In this mode, Delivery Optimization provides a reliable download experience, with no peer-to-peer caching. |
|Bypass (100) | Bypass Delivery Optimization and use BITS, instead. You should only select this mode if you use WSUS and prefer to use BranchCache. You do not need to set this option if you are using SCCM. If you want to disable peer-to-peer functionality, it's best to set **DownloadMode** to **0** or **99**. |
>[!NOTE]
>Group mode is a best-effort optimization and should not be relied on for an authentication of identity of devices participating in the group.
### Group ID
By default, peer sharing on clients using the group download mode is limited to the same domain in Windows 10, version 1511, and the same domain and Active Directory Domain Services site in Windows 10, version 1607. By using the Group ID setting, you can optionally create a custom group that contains devices that should participate in Delivery Optimization but do not fall within those domain or Active Directory Domain Services site boundaries, including devices in another domain. Using Group ID, you can further restrict the default group (for example, you could create a sub-group representing an office building), or extend the group beyond the domain, allowing devices in multiple domains in your organization to be peers. This setting requires the custom group to be specified as a GUID on each device that participates in the custom group.
[//]: # (SCCM Boundary Group option; GroupID Source policy)
>[!NOTE]
>To generate a GUID using Powershell, use [```[guid]::NewGuid()```](https://blogs.technet.microsoft.com/heyscriptingguy/2013/07/25/powertip-create-a-new-guid-by-using-powershell/)
>
>This configuration is optional and not required for most implementations of Delivery Optimization.
### Select the source of Group IDs
Starting in Windows 10, version 1803, set this policy to restrict peer selection to a specific source. The options are:
- 0 = not set
- 1 = AD Site
- 2 = Authenticated domain SID
- 3 = DHCP Option ID (with this option, the client will query DHCP Option ID 234 and use the returned GUID value as the Group ID)
- 4 = DNS Suffix
When set, the Group ID is assigned automatically from the selected source. If you set this policy, the GroupID policy will be ignored. The option set in this policy only applies to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored. If you set the value to anything other than 0-4, the policy is ignored.
### Minimum RAM (inclusive) allowed to use Peer Caching
This setting specifies the minimum RAM size in GB required to use Peer Caching. For example if the minimum set is 1 GB, then devices with 1 GB or higher available RAM will be allowed to use Peer caching. The recommended values are 1 to 4 GB, and the default value is 4 GB.
### Minimum disk size allowed to use Peer Caching
This setting specifies the required minimum disk size (capacity in GB) for the device to use Peer Caching. The recommended values are 64 to 256 GB, and the default value is 32 GB.
>[!NOTE]
>If the [Modify Cache Drive](#modify-cache-drive) policy is set, the disk size check will apply to the new working directory specified by this policy.
### Max Cache Age
In environments configured for Delivery Optimization, you might want to set an expiration on cached updates and Windows application installation files. If so, this setting defines the maximum number of seconds each file can be held in the Delivery Optimization cache on each Windows 10 client device. The default Max Cache Age value is 259,200 seconds (3 days). Alternatively, organizations might choose to set this value to “0” which means “unlimited” to avoid peers re-downloading content. When “Unlimited” value is set, Delivery Optimization will hold the files in the cache longer and will clean up the cache as needed (for example when the cache size exceeded the maximum space allowed).
### Max Cache Size
This setting limits the maximum amount of space the Delivery Optimization cache can use as a percentage of the available drive space, from 1 to 100. For example, if you set this value to 10 on a Windows 10 client device that has 100 GB of available drive space, then Delivery Optimization will use up to 10 GB of that space. Delivery Optimization will constantly assess the available drive space and automatically clear the cache to keep the maximum cache size under the set percentage. The default value for this setting is 20.
### Absolute Max Cache Size
This setting specifies the maximum number of gigabytes the Delivery Optimization cache can use. This is different from the [**Max Cache Size**](#max-cache-size) setting, which is a percentage of available disk space. Also, if you configure this policy, it will override the [**Max Cache Size**](#max-cache-size) setting. The default value for this setting is 10 GB.
### Minimum Peer Caching Content File Size
This setting specifies the minimum content file size in MB enabled to use Peer Caching. The recommended values are from 1 to 100000 MB.
### Maximum Download Bandwidth
This setting specifies the maximum download bandwidth that can be used across all concurrent Delivery Optimization downloads in kilobytes per second (KB/s). A default value of 0 means that Delivery Optimization will dynamically adjust and optimize the maximum bandwidth used.
### Maximum Foreground Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum foreground download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set.
### Maximum Background Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth. The default value of 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for foreground downloads. However, downloads from LAN peers are not throttled even when this policy is set.
### Percentage of Maximum Download Bandwidth
This setting specifies the maximum download bandwidth that Delivery Optimization can use across all concurrent download activities as a percentage of available download bandwidth. The default value 0 means that Delivery Optimization dynamically adjusts to use the available bandwidth for downloads.
### Max Upload Bandwidth
This setting allows you to limit the amount of upload bandwidth individual clients can use for Delivery Optimization. Consider this setting when clients are providing content to requesting peers on the network. This option is set in kilobytes per second (KB/s). The default setting is 0, or “unlimited” which means Delivery Optimization dynamically optimizes for minimal usage of upload bandwidth; however it does not cap the upload bandwidth rate at a set rate.
### Set Business Hours to Limit Background Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
### Set Business Hours to Limit Foreground Download Bandwidth
Starting in Windows 10, version 1803, specifies the maximum foreground download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
### Select a method to restrict peer selection
Starting in Windows 10, version 1803, set this policy to restrict peer selection via selected option.
Currently the only available option is **1 = Subnet mask** This option (Subnet mask) applies to both Download Modes LAN (1) and Group (2).
### Delay background download from http (in secs)
Starting in Windows 10, version 1803, this allows you to delay the use of an HTTP source in a background download that is allowed to use peer-to-peer.
### Delay foreground download from http (in secs)
Starting in Windows 10, version 1803, allows you to delay the use of an HTTP source in a foreground (interactive) download that is allowed to use peer-to-peer.
### Delay Foreground Download Cache Server Fallback (in secs)
Starting in Windows 10, version 1903, allows you to delay the fallback from cache server to the HTTP source for foreground content download by X seconds. If you set the policy to delay foreground download from http, it will apply first (to allow downloads from peers first).
### Delay Background Download Cache Server Fallback (in secs)
Starting in Windows 10, version 1903, set this policy to delay the fallback from cache server to the HTTP source for a background content download by X seconds. If you set the policy to delay background download from http, it will apply first (to allow downloads from peers first).
### Minimum Background QoS
This value specifies the minimum download speed guarantee that a client attempts to achieve and will fulfill by downloading more kilobytes from Windows Update servers or WSUS. Simply put, the lower this value is, the more content will be sourced using peers on the network rather than Windows Update. The higher this value, the more content is received from Windows Update servers or WSUS, versus peers on the local network.
### Modify Cache Drive
This setting allows for an alternate Delivery Optimization cache location on the clients. By default, the cache is stored on the operating system drive through the %SYSTEMDRIVE% environment variable. You can set the value to an environment variable (e.g., %SYSTEMDRIVE%), a drive letter (e.g., D:), or a folder path (e.g., D:\DOCache).
### Monthly Upload Data Cap
This setting specifies the total amount of data in gigabytes that a Delivery Optimization client can upload to Internet peers per month. A value of 0 means that an unlimited amount of data can be uploaded. The default value for this setting is 20 GB.
### Enable Peer Caching while the device connects via VPN
This setting determines whether a device will be allowed to participate in Peer Caching while connected to VPN. Specify "true" to allow the device to participate in Peer Caching while connected via VPN to the domain network. This means the device can download from or upload to other domain network devices, either on VPN or on the corporate domain network.
### Allow uploads while the device is on battery while under set Battery level
This setting specifies battery levels at which a device will be allowed to upload data. Specify any value between 1 and 100 (in percentage) to allow the device to upload data to LAN and Group peers while on DC power (Battery). Uploads will automatically pause when the battery level drops below the set minimum battery level. The recommended value to set if you allow uploads on battery is 40 (for 40%).
The device can download from peers while on battery regardless of this policy.
>[!IMPORTANT]
> By default, devices **will not upload while on battery**. To enable uploads while on battery, you need to enable this policy and set the battery value under which uploads pause.

377
windows/deployment/update/waas-delivery-optimization.md
View File

@ -1,188 +1,189 @@
---
title: Configure Delivery Optimization for Windows 10 updates (Windows 10)
ms.reviewer:
manager: laurawi
description: Delivery Optimization is a peer-to-peer distribution method in Windows 10
keywords: oms, operations management suite, wdav, updates, downloads, log analytics
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Delivery Optimization for Windows 10 updates
**Applies to**
- Windows 10
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
Windows updates, upgrades, and applications can contain packages with very large files. Downloading and distributing updates can consume quite a bit of network resources on the devices receiving them. You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization can accomplish this because it is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based servers. You can use Delivery Optimization in conjunction with Windows Update, Windows Server Update Services (WSUS), Windows Update for Business, or System Center Configuration Manager (when installation of Express Updates is enabled).
Delivery Optimization is a cloud-managed solution. Access to the Delivery Optimization cloud services is a requirement. This means that in order to use the peer-to-peer functionality of Delivery Optimization, devices must have access to the internet.
>[!NOTE]
>WSUS can also use [BranchCache](waas-branchcache.md) for content sharing and caching. If Delivery Optimization is enabled on devices that use BranchCache, Delivery Optimization will be used instead.
## Requirements
The following table lists the minimum Windows 10 version that supports Delivery Optimization:
| Device type | Minimum Windows version |
|------------------|---------------|
| Computers running Windows 10 | 1511 |
| Computers running Server Core installations of Windows Server | 1709 |
| IoT devices | 1803 |
| HoloLens devices | 1803 |
**Types of download packages supported by Delivery Optimization**
| Download package | Minimum Windows version |
|------------------|---------------|
| Windows 10 updates (feature updates and quality updates) | 1511 |
| Windows 10 drivers | 1511 |
| Windows Store files | 1511 |
| Windows Store for Business files | 1511 |
| Windows Defender definition updates | 1511 |
| Office Click-to-Run updates | 1709 |
| Win32 apps for Intune | 1709 |
| SCCM Express Updates | 1709 + Configuration Manager version 1711 |
<!-- ### Network requirements
{can you share with me what the network requirements are?}-->
By default in Windows 10 Enterprise and Education editions, Delivery Optimization allows peer-to-peer sharing on the organization's own network only (specifically, all of the devices must be behind the same NAT), but you can configure it differently in Group Policy and mobile device management (MDM) solutions such as Microsoft Intune.
For more details, see "Download mode" in [Delivery optimization reference](waas-delivery-optimization-reference.md#download-mode).
## Set up Delivery Optimization
See [Set up Delivery Optimization](waas-delivery-optimization-setup.md) for suggested values for a number of common scenarios.
You can use Group Policy or an MDM solution like Intune to configure Delivery Optimization.
You will find the Delivery Optimization settings in Group Policy under **Configuration\Policies\Administrative Templates\Windows Components\Delivery Optimization**.
In MDM, the same settings are under **.Vendor/MSFT/Policy/Config/DeliveryOptimization/**.
Starting with Microsoft Intune version 1902, you can set many Delivery Optimization policies as a profile which you can then apply to groups of devices. For more information, see [Delivery Optimization settings in Microsoft Intune](https://docs.microsoft.com/intune/delivery-optimization-windows))
**Starting with Windows 10, version 1903,** you can use the Azure Active Directory (AAD) Tenant ID as a means to define groups. To do this set the value for DOGroupIdSource to its new maximum value of 5.
## Reference
For complete list of every possible Delivery Optimization setting, see [Delivery Optimization reference](waas-delivery-optimization-reference.md).
## How Microsoft uses Delivery Optimization
At Microsoft, to help ensure that ongoing deployments weren’t affecting our network and taking away bandwidth for other services, Microsoft IT used a couple of different bandwidth management strategies. Delivery Optimization, peer-to-peer caching enabled through Group Policy, was piloted and then deployed to all managed devices using Group Policy. Based on recommendations from the Delivery Optimization team, we used the "group" configuration to limit sharing of content to only the devices that are members of the same Active Directory domain. The content is cached for 24 hours. More than 76 percent of content came from peer devices versus the Internet.
For more details, check out the [Adopting Windows as a Service at Microsoft](https://www.microsoft.com/itshowcase/Article/Content/851/Adopting-Windows-as-a-service-at-Microsoft) technical case study.
## Frequently asked questions
**Does Delivery Optimization work with WSUS?**: Yes. Devices will obtain the update payloads from the WSUS server, but must also have an internet connection as they communicate with the Delivery Optimization cloud service for coordination.
**Which ports does Delivery Optimization use?**: For peer-to-peer traffic, it uses 7680 for TCP/IP or 3544 for NAT traversal (optionally Teredo). For client-service communication, it uses HTTP or HTTPS over port 80/443.
**What are the requirements if I use a proxy?**: You must allow Byte Range requests. See [Proxy requirements for Windows Update](https://support.microsoft.com/help/3175743/proxy-requirements-for-windows-update) for details.
**What hostnames should I allow through my firewall to support Delivery Optimization?**:
For communication between clients and the Delivery Optimization cloud service: **\*.do.dsp.mp.microsoft.com**.
For Delivery Optimization metadata:
- *.dl.delivery.mp.microsoft.com
- *.emdl.ws.microsoft.com
For the payloads (optional):
- *.download.windowsupdate.com
- *.windowsupdate.com
**Does Delivery Optimization use multicast?**: No. It relies on the cloud service for peer discovery, resulting in a list of peers and their IP addresses. Client devices then connect to their peers to obtain download files over TCP/IP.
**How does Delivery Optimization deal with congestion on the router from peer-to-peer activity on the LAN?**: Starting in Windows 10, version 1903, Delivery Optimizatio uses LEDBAT to relieve such congestion. For more details see this post on the [Networking Blog](https://techcommunity.microsoft.com/t5/Networking-Blog/Windows-Transport-converges-on-two-Congestion-Providers-Cubic/ba-p/339819).
## Troubleshooting
This section summarizes common problems and some solutions to try.
### If you don't see any bytes from peers
If you don’t see any bytes coming from peers the cause might be one of the following issues:
- Clients aren’t able to reach the Delivery Optimization cloud services.
- The cloud service doesn’t see other peers on the network.
- Clients aren’t able to connect to peers that are offered back from the cloud service.
### Clients aren't able to reach the Delivery Optimization cloud services.
If you suspect this is the problem, try these steps:
1. Start a download of an app that is larger than 50 MB from the Store (for example "Candy Crush Saga").
2. Run `Get-DeliveryOptimizationStatus` from an elevated Powershell window and observe the DownloadMode setting. For peering to work, DownloadMode should be 1, 2, or 3.
3. If **DownloadMode** is 99 it could indicate your device is unable to reach the Delivery Optimization cloud services. Ensure that the Delivery Optimization hostnames are allowed access: most importantly **\*.do.dsp.mp.microsoft.com**.
### The cloud service doesn't see other peers on the network.
If you suspect this is the problem, try these steps:
1. Download the same app on two different devices on the same network, waiting 10 – 15 minutes between downloads.
2. Run `Get-DeliveryOptimizationStatus` from an elevated Powershell window and ensure that **DownloadMode** is 1 or 2 on both devices.
3. Run `Get-DeliveryOptimizationPerfSnap` from an elevated Powershell window on the second device. The **NumberOfPeers** field should be non-zero.
4. If the number of peers is zero and you have **DownloadMode** = 1, ensure that both devices are using the same public IP address to reach the internet. To do this, open a browser Windows and search for “what is my IP”. You can **DownloadMode 2** (Group) and a custom GroupID (Guid) to fix this if the devices aren’t reporting the same public IP address.
### Clients aren't able to connect to peers offered by the cloud service
If you suspect this is the problem, try a Telnet test between two devices on the network to ensure they can connect using port 7680. To do this, follow these steps:
1. Install Telnet by running **dism /online /Enable-Feature /FeatureName:TelnetClient** from an elevated command prompt.
2. Run the test. For example, if you are on device with IP 192.168.8.12 and you are trying to test the connection to 192.168.9.17 run **telnet 192.168.9.17 7680** (the syntax is *telnet [destination IP] [port]*. You will either see a connection error or a blinking cursor like this /_. The blinking cursor means success.
## Learn more
[Windows 10, Delivery Optimization, and WSUS](https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/)
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Prepare servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md)
- [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md)
- [Assign devices to servicing channels for Windows 10 updates](waas-servicing-channels-windows-10-updates.md)
- [Optimize update delivery for Windows 10 updates](waas-optimize-windows-10-updates.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)
- [Deploy Windows 10 updates using Windows Server Update Services](waas-manage-updates-wsus.md)
- [Deploy Windows 10 updates using System Center Configuration Manager](waas-manage-updates-configuration-manager.md)
- [Manage device restarts after updates](waas-restart.md)
---
title: Configure Delivery Optimization for Windows 10 updates (Windows 10)
ms.reviewer:
manager: laurawi
description: Delivery Optimization is a peer-to-peer distribution method in Windows 10
keywords: oms, operations management suite, wdav, updates, downloads, log analytics
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.author: greglin
ms.collection: M365-modern-desktop
ms.topic: article
---
# Delivery Optimization for Windows 10 updates
**Applies to**
- Windows 10
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
Windows updates, upgrades, and applications can contain packages with very large files. Downloading and distributing updates can consume quite a bit of network resources on the devices receiving them. You can use Delivery Optimization to reduce bandwidth consumption by sharing the work of downloading these packages among multiple devices in your deployment. Delivery Optimization can accomplish this because it is a self-organizing distributed cache that allows clients to download those packages from alternate sources (such as other peers on the network) in addition to the traditional Internet-based servers. You can use Delivery Optimization in conjunction with Windows Update, Windows Server Update Services (WSUS), Windows Update for Business, or System Center Configuration Manager (when installation of Express Updates is enabled).
Delivery Optimization is a cloud-managed solution. Access to the Delivery Optimization cloud services is a requirement. This means that in order to use the peer-to-peer functionality of Delivery Optimization, devices must have access to the internet.
>[!NOTE]
>WSUS can also use [BranchCache](waas-branchcache.md) for content sharing and caching. If Delivery Optimization is enabled on devices that use BranchCache, Delivery Optimization will be used instead.
## Requirements
The following table lists the minimum Windows 10 version that supports Delivery Optimization:
| Device type | Minimum Windows version |
|------------------|---------------|
| Computers running Windows 10 | 1511 |
| Computers running Server Core installations of Windows Server | 1709 |
| IoT devices | 1803 |
| HoloLens devices | 1803 |
**Types of download packages supported by Delivery Optimization**
| Download package | Minimum Windows version |
|------------------|---------------|
| Windows 10 updates (feature updates and quality updates) | 1511 |
| Windows 10 drivers | 1511 |
| Windows Store files | 1511 |
| Windows Store for Business files | 1511 |
| Windows Defender definition updates | 1511 |
| Office Click-to-Run updates | 1709 |
| Win32 apps for Intune | 1709 |
| SCCM Express Updates | 1709 + Configuration Manager version 1711 |
<!-- ### Network requirements
{can you share with me what the network requirements are?}-->
By default in Windows 10 Enterprise and Education editions, Delivery Optimization allows peer-to-peer sharing on the organization's own network only (specifically, all of the devices must be behind the same NAT), but you can configure it differently in Group Policy and mobile device management (MDM) solutions such as Microsoft Intune.
For more details, see "Download mode" in [Delivery optimization reference](waas-delivery-optimization-reference.md#download-mode).
## Set up Delivery Optimization
See [Set up Delivery Optimization](waas-delivery-optimization-setup.md) for suggested values for a number of common scenarios.
You can use Group Policy or an MDM solution like Intune to configure Delivery Optimization.
You will find the Delivery Optimization settings in Group Policy under **Configuration\Policies\Administrative Templates\Windows Components\Delivery Optimization**.
In MDM, the same settings are under **.Vendor/MSFT/Policy/Config/DeliveryOptimization/**.
Starting with Microsoft Intune version 1902, you can set many Delivery Optimization policies as a profile which you can then apply to groups of devices. For more information, see [Delivery Optimization settings in Microsoft Intune](https://docs.microsoft.com/intune/delivery-optimization-windows))
**Starting with Windows 10, version 1903,** you can use the Azure Active Directory (AAD) Tenant ID as a means to define groups. To do this set the value for DOGroupIdSource to its new maximum value of 5.
## Reference
For complete list of every possible Delivery Optimization setting, see [Delivery Optimization reference](waas-delivery-optimization-reference.md).
## How Microsoft uses Delivery Optimization
At Microsoft, to help ensure that ongoing deployments weren’t affecting our network and taking away bandwidth for other services, Microsoft IT used a couple of different bandwidth management strategies. Delivery Optimization, peer-to-peer caching enabled through Group Policy, was piloted and then deployed to all managed devices using Group Policy. Based on recommendations from the Delivery Optimization team, we used the "group" configuration to limit sharing of content to only the devices that are members of the same Active Directory domain. The content is cached for 24 hours. More than 76 percent of content came from peer devices versus the Internet.
For more details, check out the [Adopting Windows as a Service at Microsoft](https://www.microsoft.com/itshowcase/Article/Content/851/Adopting-Windows-as-a-service-at-Microsoft) technical case study.
## Frequently asked questions
**Does Delivery Optimization work with WSUS?**: Yes. Devices will obtain the update payloads from the WSUS server, but must also have an internet connection as they communicate with the Delivery Optimization cloud service for coordination.
**Which ports does Delivery Optimization use?**: For peer-to-peer traffic, it uses 7680 for TCP/IP or 3544 for NAT traversal (optionally Teredo). For client-service communication, it uses HTTP or HTTPS over port 80/443.
**What are the requirements if I use a proxy?**: You must allow Byte Range requests. See [Proxy requirements for Windows Update](https://support.microsoft.com/help/3175743/proxy-requirements-for-windows-update) for details.
**What hostnames should I allow through my firewall to support Delivery Optimization?**:
For communication between clients and the Delivery Optimization cloud service: **\*.do.dsp.mp.microsoft.com**.
For Delivery Optimization metadata:
- *.dl.delivery.mp.microsoft.com
- *.emdl.ws.microsoft.com
For the payloads (optional):
- *.download.windowsupdate.com
- *.windowsupdate.com
**Does Delivery Optimization use multicast?**: No. It relies on the cloud service for peer discovery, resulting in a list of peers and their IP addresses. Client devices then connect to their peers to obtain download files over TCP/IP.
**How does Delivery Optimization deal with congestion on the router from peer-to-peer activity on the LAN?**: Starting in Windows 10, version 1903, Delivery Optimization uses LEDBAT to relieve such congestion. For more details see this post on the [Networking Blog](https://techcommunity.microsoft.com/t5/Networking-Blog/Windows-Transport-converges-on-two-Congestion-Providers-Cubic/ba-p/339819).
## Troubleshooting
This section summarizes common problems and some solutions to try.
### If you don't see any bytes from peers
If you don’t see any bytes coming from peers the cause might be one of the following issues:
- Clients aren’t able to reach the Delivery Optimization cloud services.
- The cloud service doesn’t see other peers on the network.
- Clients aren’t able to connect to peers that are offered back from the cloud service.
### Clients aren't able to reach the Delivery Optimization cloud services.
If you suspect this is the problem, try these steps:
1. Start a download of an app that is larger than 50 MB from the Store (for example "Candy Crush Saga").
2. Run `Get-DeliveryOptimizationStatus` from an elevated Powershell window and observe the DownloadMode setting. For peering to work, DownloadMode should be 1, 2, or 3.
3. If **DownloadMode** is 99 it could indicate your device is unable to reach the Delivery Optimization cloud services. Ensure that the Delivery Optimization hostnames are allowed access: most importantly **\*.do.dsp.mp.microsoft.com**.
### The cloud service doesn't see other peers on the network.
If you suspect this is the problem, try these steps:
1. Download the same app on two different devices on the same network, waiting 10 – 15 minutes between downloads.
2. Run `Get-DeliveryOptimizationStatus` from an elevated Powershell window and ensure that **DownloadMode** is 1 or 2 on both devices.
3. Run `Get-DeliveryOptimizationPerfSnap` from an elevated Powershell window on the second device. The **NumberOfPeers** field should be non-zero.
4. If the number of peers is zero and you have **DownloadMode** = 1, ensure that both devices are using the same public IP address to reach the internet. To do this, open a browser Windows and search for “what is my IP”. You can **DownloadMode 2** (Group) and a custom GroupID (Guid) to fix this if the devices aren’t reporting the same public IP address.
### Clients aren't able to connect to peers offered by the cloud service
If you suspect this is the problem, try a Telnet test between two devices on the network to ensure they can connect using port 7680. To do this, follow these steps:
1. Install Telnet by running **dism /online /Enable-Feature /FeatureName:TelnetClient** from an elevated command prompt.
2. Run the test. For example, if you are on device with IP 192.168.8.12 and you are trying to test the connection to 192.168.9.17 run **telnet 192.168.9.17 7680** (the syntax is *telnet [destination IP] [port]*. You will either see a connection error or a blinking cursor like this /_. The blinking cursor means success.
## Learn more
[Windows 10, Delivery Optimization, and WSUS](https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/)
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Prepare servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md)
- [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md)
- [Assign devices to servicing channels for Windows 10 updates](waas-servicing-channels-windows-10-updates.md)
- [Optimize update delivery for Windows 10 updates](waas-optimize-windows-10-updates.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)
- [Deploy Windows 10 updates using Windows Server Update Services](waas-manage-updates-wsus.md)
- [Deploy Windows 10 updates using System Center Configuration Manager](waas-manage-updates-configuration-manager.md)
- [Manage device restarts after updates](waas-restart.md)

438
windows/deployment/update/waas-overview.md
View File

@ -1,218 +1,220 @@
---
title: Overview of Windows as a service (Windows 10)
description: In Windows 10, Microsoft has streamlined servicing to make operating system updates simpler to test, manage, and deploy.
keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, tools
ms.prod: w10
ms.mktglfcycl: manage
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.audience: itpro author: greg-lindsay
ms.date: 09/24/2018
ms.reviewer:
manager: laurawi
ms.topic: article
---
# Overview of Windows as a service
**Applies to**
- Windows 10
- Windows 10 Mobile
- Windows 10 IoT Mobile
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
The Windows 10 operating system introduces a new way to build, deploy, and service Windows: Windows as a service. Microsoft has reimagined each part of the process, to simplify the lives of IT pros and maintain a consistent Windows 10 experience for its customers. These improvements focus on maximizing customer involvement in Windows development, simplifying the deployment and servicing of Windows client computers, and leveling out the resources needed to deploy and maintain Windows over time.
Click the following Microsoft Mechanics video for an overview of the release model, particularly the Semi-Annual Channel.
[![YouTube video of Michael Niehouse explaining how the Semi-Annual Channel works](images/SAC_vid_crop.jpg)](https://youtu.be/qSAsiM01GOU)
## Building
Prior to Windows 10, Microsoft released new versions of Windows every few years. This traditional deployment schedule imposed a training burden on users because the feature revisions were often significant. That schedule also meant waiting long periods without new features — a scenario that doesn’t work in today’s rapidly changing world, a world in which new security, management, and deployment capabilities are necessary to address challenges. Windows as a service will deliver smaller feature updates two times per year, around March and September, to help address these issues.
In the past, when Microsoft developed new versions of Windows, it typically released technical previews near the end of the process, when Windows was nearly ready to ship. With Windows 10, new features will be delivered to the [Windows Insider community](https://insider.windows.com/) as soon as possible — during the development cycle, through a process called *flighting* — so that organizations can see exactly what Microsoft is developing and start their testing as soon as possible.
Microsoft also depends on receiving feedback from organizations throughout the development process so that it can make adjustments as quickly as possible rather than waiting until after release. For more information about the Windows Insider Program and how to sign up, see the section [Windows Insider](#windows-insider).
Of course Microsoft also performs extensive internal testing, with engineering teams installing new builds daily, and larger groups of employees installing builds frequently, all before those builds are ever released to the Windows Insider Program.
## Deploying
Deploying Windows 10 is simpler than with previous versions of Windows. When migrating from earlier versions of Windows, an easy in-place upgrade process can be used to automatically preserve all apps, settings, and data. And once running Windows 10, deployment of Windows 10 feature updates will be equally simple.
One of the biggest challenges for organizations when it comes to deploying a new version of Windows is compatibility testing. Whereas compatibility was previously a concern for organizations upgrading to a new version of Windows, Windows 10 is compatible with most hardware and software capable of running on Windows 7 or later. Because of this high level of compatibility, the app compatibility testing process can be greatly simplified.
### Application compatibility
Application compatibility testing has historically been a burden when approaching a Windows deployment or upgrade. With Windows 10, application compatibility from the perspective of desktop applications, websites, and apps built on the Universal Windows Platform (UWP) has improved tremendously. Microsoft understands the challenges organizations experienced when they migrated from the Windows XP operating system to Windows 7 and has been working to make Windows 10 upgrades a much better experience.
Most Windows 7–compatible desktop applications will be compatible with Windows 10 straight out of the box. Windows 10 achieved such high compatibility because the changes in the existing Win32 application programming interfaces were minimal. Combined with valuable feedback via the Windows Insider Program and diagnostic data, this level of compatibility can be maintained through each feature update. As for websites, Windows 10 includes Internet Explorer 11 and its backward-compatibility modes for legacy websites. Finally, UWP apps follow a compatibility story similar to desktop applications, so most of them will be compatible with Windows 10.
For the most important business-critical applications, organizations should still perform testing on a regular basis to validate compatibility with new builds. For remaining applications, consider validating them as part of a pilot deployment process to reduce the time spent on compatibility testing. If it’s unclear whether an application is compatible with Windows 10, IT pros can either consult with the ISV or check the supported software directory at [http://www.readyforwindows.com](http://www.readyforwindows.com).
### Device compatibility
Device compatibility in Windows 10 is also very strong; new hardware is not needed for Windows 10 as any device capable of running Windows 7 or later can run Windows 10. In fact, the minimum hardware requirements to run Windows 10 are the same as those required for Windows 7. Most hardware drivers that functioned in Windows 8.1, Windows 8, or Windows 7 will continue to function in Windows 10.
## Servicing
Traditional Windows servicing has included several release types: major revisions (e.g., the Windows 8.1, Windows 8, and Windows 7 operating systems), service packs, and monthly updates. With Windows 10, there are two release types: feature updates that add new functionality twice per year, and quality updates that provide security and reliability fixes at least once a month.
With Windows 10, organizations will need to change the way they approach deploying updates. Servicing channels are the first way to separate users into deployment groups for feature and quality updates. With the introduction of servicing channels comes the concept of a [deployment ring](waas-deployment-rings-windows-10-updates.md), which is simply a way to categorize the combination of a deployment group and a servicing channel to group devices for successive waves of deployment. For more information about developing a deployment strategy that leverages servicing channels and deployment rings, see [Plan servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md).
For information about each servicing tool available for Windows 10, see [Servicing tools](#servicing-tools).
To align with this new update delivery model, Windows 10 has three servicing channels, each of which provides different levels of flexibility over when these updates are delivered to client computers. For information about the servicing channels available in Windows 10, see [Servicing channels](#servicing-channels).
### Naming changes
As part of the alignment with Windows 10 and Office 365 ProPlus, we are adopting common terminology to make it as easy as possible to understand the servicing process. Going forward, these are the new terms we will be using:
* Semi-Annual Channel - We will be referring to Current Branch (CB) as "Semi-Annual Channel (Targeted)", while Current Branch for Business (CBB) will simply be referred to as "Semi-Annual Channel".
* Long-Term Servicing Channel -  The Long-Term Servicing Branch (LTSB) will be referred to as Long-Term Servicing Channel (LTSC).
>[!IMPORTANT]
>With each Semi-Annual Channel release, we recommend beginning deployment right away to devices selected for early adoption (targeted validation) and ramp up to full deployment at your discretion, regardless of the "Targeted" designation. This will enable you to gain access to new features, experiences, and integrated security as soon as possible. For more information, see the blog post [Windows 10 and the "disappearing" SAC-T](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-10-and-the-disappearing-SAC-T/ba-p/199747).
>[!NOTE]
>For additional information, see the section about [Servicing Channels](#servicing-channels).
>
>You can also read the blog post [Waas simplified and aligned](https://blogs.technet.microsoft.com/windowsitpro/2017/07/27/waas-simplified-and-aligned/), with details on this change.
>[!IMPORTANT]
>Devices on the Semi-Annual Channel (formerly called Current Branch for Business) must have their diagnostic data set to **1 (Basic)** or higher, in order to ensure that the service is performing at the expected quality. If diagnostic data is set to **0**, the device will be treated as if it were in the Semi-Annual Channel (Targeted)(formerly called Current Branch or CB) branch. For instructions to set the diagnostic data level, see [Configure the operating system diagnostic data level](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization#diagnostic-data-levels).
### Feature updates
With Windows 10, Microsoft will package new features into feature updates that can be deployed using existing management tools. Because feature updates are delivered more frequently than with previous Windows releases — twice per year, around March and September, rather than every 3–5 years — changes will be in bite-sized chunks rather than all at once and end user readiness time much shorter.
>[!TIP]
> The feature update cadence has been aligned with Office 365 ProPlus updates. Starting with this falls' update, both Windows and Office will deliver their major updates semi-annually, around March and September. See [upcoming changes to Office 365 ProPlus update management](https://support.office.com/article/Overview-of-the-upcoming-changes-to-Office-365-ProPlus-update-management-78b33779-9356-4cdf-9d2c-08350ef05cca) for more information about changes to Office update management.
### Quality updates
Monthly updates in previous Windows versions were often overwhelming because of the sheer number of updates available each month. Many organizations selectively chose which updates they wanted to install and which they didn’t, and this created countless scenarios in which organizations deployed essential security updates but picked only a subset of non-security fixes.
In Windows 10, rather than receiving several updates each month and trying to figure out which the organization needs, which ultimately causes platform fragmentation, administrators will see one cumulative monthly update that supersedes the previous month’s update, containing both security and non-security fixes. This approach makes patching simpler and ensures that customers’ devices are more closely aligned with the testing done at Microsoft, reducing unexpected issues resulting from patching. The left side of Figure 1 provides an example of Windows 7 devices in an enterprise and what their current patch level might look like. On the right is what Microsoft’s test environment PCs contain. This drastic difference is the basis for many compatibility issues and system anomalies related to Windows updates.
**Figure 1**
![Comparison of patch environment in enterprise compared to test](images/waas-overview-patch.png)
## Servicing channels
To align with the new method of delivering feature updates and quality updates in Windows 10, Microsoft introduced the concept of servicing channels to allow customers to designate how frequently their individual devices are updated. For example, an organization may have test devices that the IT department can update with new features as soon as possible, and then specialized devices that require a longer feature update cycle to ensure continuity.
With that in mind, Windows 10 offers 3 servicing channels. The [Windows Insider Program](#windows-insider) provides organizations with the opportunity to test and provide feedback on features that will be shipped in the next feature update. The [Semi-Annual Channel](#semi-annual-channel) provides new functionality with twice-per-year feature update releases. Organizations can choose when to deploy updates from the Semi-Annual Channel. The [Long Term Servicing Channel](#long-term-servicing-channel), which is designed to be used only for specialized devices (which typically don't run Office) such as those that control medical equipment or ATM machines, receives new feature releases every two to three years. For details about the versions in each servicing channel, see [Windows 10 release information](https://technet.microsoft.com/windows/release-info.aspx).
The concept of servicing channels is new, but organizations can use the same management tools they used to manage updates and upgrades in previous versions of Windows. For more information about the servicing tool options for Windows 10 and their capabilities, see [Servicing tools](#servicing-tools).
>[!NOTE]
>Servicing channels are not the only way to separate groups of devices when consuming updates. Each channel can contain subsets of devices, which staggers servicing even further. For information about the servicing strategy and ongoing deployment process for Windows 10, including the role of servicing channels, see [Plan servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md).
### Semi-Annual Channel
In the Semi-Annual servicing channel, feature updates are available as soon as Microsoft releases them. Windows 10, version 1511, had few servicing tool options to delay feature updates, limiting the use of the Semi-Annual servicing channel. Windows 10, version 1607 and onward, includes more servicing tools that can delay feature updates for up to 365 days. This servicing model is ideal for pilot deployments and testing of Windows 10 feature updates and for users such as developers who need to work with the latest features immediately. Once the latest release has gone through pilot deployment and testing, you will be able to choose the timing at which it goes into broad deployment.
When Microsoft officially releases a feature update for Windows 10, it is made available to any PC not configured to defer feature updates so that those devices can immediately install it. Organizations that use Windows Server Update Services (WSUS), Microsoft System Center Configuration Manager, or Windows Update for Business, however, can defer feature updates to selective devices by withholding their approval and deployment. In this scenario, the content available for the Semi-Annual Channel will be available but not necessarily immediately mandatory, depending on the policy of the management system. For more details about Windows 10 servicing tools, see [Servicing tools](#servicing-tools).
Organizations are expected to initiate targeted deployment on Semi-Annual Channel releases. All customers, independent software vendors (ISVs), and partners should use this time for testing and piloting within their environments. After 2-4 months, we will transition to broad deployment and encourage customers and partners to expand and accelerate the deployment of the release. For customers using Windows Update for Business, the Semi-Annual Channel provides three months of additional total deployment time before being required to update to the next release.
> [!NOTE]
> All releases of Windows 10 have 18 months of servicing for all editions--these updates provide security and feature updates for the release. Customers running Enterprise and Education editions have an additional 12 months of servicing for specific Windows 10 releases, for a total of 30 months from initial release. These versions include Enterprise and Education editions for Windows 10, versions 1607, 1703, 1709 and 1803. Starting in October 2018, all Semi-Annual Channel releases in the September/October timeframe will also have the additional 12 months of servicing for a total of 30 months from the initial release. The Semi-Annual Channel versions released in March/April timeframe will continue to have an 18 month lifecycle.
>
>
> [!NOTE]
> Organizations can electively delay feature updates into as many phases as they wish by using one of the servicing tools mentioned in the section Servicing tools.
### Long-term Servicing Channel
Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.
>[!NOTE]
>Windows 10 Enterprise LTSB is a separate Long Term Servicing Channel version.
>
>Long-term Servicing channel is not intended for deployment on most or all the PCs in an organization; it should be used only for special-purpose devices. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, typically used by an information worker, and therefore it is better suited for the Semi-Annual servicing channel.
Microsoft never publishes feature updates through Windows Update on devices that run Windows 10 Enterprise LTSB. Instead, it typically offers new LTSC releases every 2–3 years, and organizations can choose to install them as in-place upgrades or even skip releases over a 10-year life cycle.
>[!NOTE]
>Windows 10 LTSB will support the currently released processors and chipsets at the time of release of the LTSB. As future CPU generations are released, support will be created through future Windows 10 LTSB releases that customers can deploy for those systems. For more information, see **Supporting the latest processor and chipsets on Windows** in [Lifecycle support policy FAQ - Windows Products](https://support.microsoft.com/help/18581/lifecycle-support-policy-faq-windows-products).
The Long-term Servicing Channel is available only in the Windows 10 Enterprise LTSB edition. This edition of Windows doesn’t include a number of applications, such as Microsoft Edge, Microsoft Store, Cortana (though limited search capabilities remain available), Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock. These apps are not supported in Windows 10 Enterprise LTSB edition, even if you install by using sideloading.
>[!NOTE]
>If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.
### Windows Insider
For many IT pros, gaining visibility into feature updates early—before they’re available to the Semi-Annual Channel — can be both intriguing and valuable for future end user communications as well as provide the means to test for any issues on the next Semi-Annual Channel release. With Windows 10, feature flighting enables Windows Insiders to consume and deploy preproduction code to their test machines, gaining early visibility into the next build. Testing the early builds of Windows 10 helps both Microsoft and its customers because they have the opportunity to discover possible issues before the update is ever publicly available and can report it to Microsoft.
Microsoft recommends that all organizations have at least a few PCs enrolled in the Windows Insider Program and provide feedback on any issues they encounter. For information about the Windows Insider Program for Business, go to [Windows Insider Program for Business](waas-windows-insider-for-business.md).
>[!NOTE]
>Microsoft recommends that all organizations have at least a few PCs enrolled in the Windows Insider Program, to include the Windows Insider Program in their deployment plans and to provide feedback on any issues they encounter to Microsoft via our Feedback Hub app.
>
>The Windows Insider Program isn’t intended to replace Semi-Annual Channel deployments in an organization. Rather, it provides IT pros and other interested parties with pre-release Windows builds that they can test and ultimately provide feedback on to Microsoft.
## Servicing tools
There are many tools with which IT pros can service Windows as a service. Each option has its pros and cons, ranging from capabilities and control to simplicity and low administrative requirements. The following are examples of the servicing tools available to manage Windows as a service updates:
- **Windows Update (stand-alone)** provides limited control over feature updates, with IT pros manually configuring the device to be in the Semi-Annual Channel. Organizations can target which devices defer updates by selecting the Defer upgrades check box in Start\Settings\Update & Security\Advanced Options on a Windows 10 client.
- **Windows Update for Business** is the second option for servicing Windows as a service. This servicing tool includes control over update deferment and provides centralized management using Group Policy. Windows Update for Business can be used to defer updates by up to 365 days, depending on the version. These deployment options are available to clients in the Semi-Annual Channel. In addition to being able to use Group Policy to manage Windows Update for Business, either option can be configured without requiring any on-premises infrastructure by using Intune.
- **Windows Server Update Services (WSUS)** provides extensive control over Windows 10 updates and is natively available in the Windows Server operating system. In addition to the ability to defer updates, organizations can add an approval layer for updates and choose to deploy them to specific computers or groups of computers whenever ready.
- **System Center Configuration Manager** provides the greatest control over servicing Windows as a service. IT pros can defer updates, approve them, and have multiple options for targeting deployments and managing bandwidth usage and deployment times.
With all these options, which an organization chooses depends on the resources, staff, and expertise its IT organization already has. For example, if IT already uses System Center Configuration Manager to manage Windows updates, it can continue to use it. Similarly, if IT is using WSUS, it can continue to use that. For a consolidated look at the benefits of each tool, see Table 1.
**Table 1**
| Servicing tool | Can updates be deferred? | Ability to approve updates | Peer-to-peer option | Additional features |
| --- | --- | --- | --- | --- |
| Windows Update | Yes (manual) | No | Delivery Optimization | None|
| Windows Update for Business | Yes | No | Delivery Optimization | Other Group Policy objects |
| WSUS | Yes | Yes | BranchCache or Delivery Optimization | Upstream/downstream server scalability |
| Configuration Manager | Yes | Yes | BranchCache, Client Peer Cache | Distribution points, multiple deployment options |
>[!NOTE]
>Due to [naming changes](#naming-changes), older terms like CB,CBB and LTSB may still be displayed in some of our products.
</br>
## Steps to manage updates for Windows 10
| | |
| --- | --- |
| ![done](images/checklistdone.png) | Learn about updates and servicing channels (this topic) |
| ![to do](images/checklistbox.gif) | [Prepare servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Assign devices to servicing channels for Windows 10 updates](waas-servicing-channels-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Optimize update delivery for Windows 10 updates](waas-optimize-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md)</br>or [Deploy Windows 10 updates using Windows Server Update Services](waas-manage-updates-wsus.md)</br>or [Deploy Windows 10 updates using System Center Configuration Manager](waas-manage-updates-configuration-manager.md) |
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Quick guide to Windows as a service](waas-quick-start.md)
- [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)
- [Manage device restarts after updates](waas-restart.md)
---
title: Overview of Windows as a service (Windows 10)
description: In Windows 10, Microsoft has streamlined servicing to make operating system updates simpler to test, manage, and deploy.
keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, tools
ms.prod: w10
ms.mktglfcycl: manage
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.audience: itpro
author: greg-lindsay
ms.date: 09/24/2018
ms.reviewer:
manager: laurawi
ms.topic: article
---
# Overview of Windows as a service
**Applies to**
- Windows 10
- Windows 10 Mobile
- Windows 10 IoT Mobile
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
The Windows 10 operating system introduces a new way to build, deploy, and service Windows: Windows as a service. Microsoft has reimagined each part of the process, to simplify the lives of IT pros and maintain a consistent Windows 10 experience for its customers. These improvements focus on maximizing customer involvement in Windows development, simplifying the deployment and servicing of Windows client computers, and leveling out the resources needed to deploy and maintain Windows over time.
Click the following Microsoft Mechanics video for an overview of the release model, particularly the Semi-Annual Channel.
[![YouTube video of Michael Niehouse explaining how the Semi-Annual Channel works](images/SAC_vid_crop.jpg)](https://youtu.be/qSAsiM01GOU)
## Building
Prior to Windows 10, Microsoft released new versions of Windows every few years. This traditional deployment schedule imposed a training burden on users because the feature revisions were often significant. That schedule also meant waiting long periods without new features — a scenario that doesn’t work in today’s rapidly changing world, a world in which new security, management, and deployment capabilities are necessary to address challenges. Windows as a service will deliver smaller feature updates two times per year, around March and September, to help address these issues.
In the past, when Microsoft developed new versions of Windows, it typically released technical previews near the end of the process, when Windows was nearly ready to ship. With Windows 10, new features will be delivered to the [Windows Insider community](https://insider.windows.com/) as soon as possible — during the development cycle, through a process called *flighting* — so that organizations can see exactly what Microsoft is developing and start their testing as soon as possible.
Microsoft also depends on receiving feedback from organizations throughout the development process so that it can make adjustments as quickly as possible rather than waiting until after release. For more information about the Windows Insider Program and how to sign up, see the section [Windows Insider](#windows-insider).
Of course Microsoft also performs extensive internal testing, with engineering teams installing new builds daily, and larger groups of employees installing builds frequently, all before those builds are ever released to the Windows Insider Program.
## Deploying
Deploying Windows 10 is simpler than with previous versions of Windows. When migrating from earlier versions of Windows, an easy in-place upgrade process can be used to automatically preserve all apps, settings, and data. And once running Windows 10, deployment of Windows 10 feature updates will be equally simple.
One of the biggest challenges for organizations when it comes to deploying a new version of Windows is compatibility testing. Whereas compatibility was previously a concern for organizations upgrading to a new version of Windows, Windows 10 is compatible with most hardware and software capable of running on Windows 7 or later. Because of this high level of compatibility, the app compatibility testing process can be greatly simplified.
### Application compatibility
Application compatibility testing has historically been a burden when approaching a Windows deployment or upgrade. With Windows 10, application compatibility from the perspective of desktop applications, websites, and apps built on the Universal Windows Platform (UWP) has improved tremendously. Microsoft understands the challenges organizations experienced when they migrated from the Windows XP operating system to Windows 7 and has been working to make Windows 10 upgrades a much better experience.
Most Windows 7–compatible desktop applications will be compatible with Windows 10 straight out of the box. Windows 10 achieved such high compatibility because the changes in the existing Win32 application programming interfaces were minimal. Combined with valuable feedback via the Windows Insider Program and diagnostic data, this level of compatibility can be maintained through each feature update. As for websites, Windows 10 includes Internet Explorer 11 and its backward-compatibility modes for legacy websites. Finally, UWP apps follow a compatibility story similar to desktop applications, so most of them will be compatible with Windows 10.
For the most important business-critical applications, organizations should still perform testing on a regular basis to validate compatibility with new builds. For remaining applications, consider validating them as part of a pilot deployment process to reduce the time spent on compatibility testing. If it’s unclear whether an application is compatible with Windows 10, IT pros can either consult with the ISV or check the supported software directory at [http://www.readyforwindows.com](http://www.readyforwindows.com).
### Device compatibility
Device compatibility in Windows 10 is also very strong; new hardware is not needed for Windows 10 as any device capable of running Windows 7 or later can run Windows 10. In fact, the minimum hardware requirements to run Windows 10 are the same as those required for Windows 7. Most hardware drivers that functioned in Windows 8.1, Windows 8, or Windows 7 will continue to function in Windows 10.
## Servicing
Traditional Windows servicing has included several release types: major revisions (e.g., the Windows 8.1, Windows 8, and Windows 7 operating systems), service packs, and monthly updates. With Windows 10, there are two release types: feature updates that add new functionality twice per year, and quality updates that provide security and reliability fixes at least once a month.
With Windows 10, organizations will need to change the way they approach deploying updates. Servicing channels are the first way to separate users into deployment groups for feature and quality updates. With the introduction of servicing channels comes the concept of a [deployment ring](waas-deployment-rings-windows-10-updates.md), which is simply a way to categorize the combination of a deployment group and a servicing channel to group devices for successive waves of deployment. For more information about developing a deployment strategy that leverages servicing channels and deployment rings, see [Plan servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md).
For information about each servicing tool available for Windows 10, see [Servicing tools](#servicing-tools).
To align with this new update delivery model, Windows 10 has three servicing channels, each of which provides different levels of flexibility over when these updates are delivered to client computers. For information about the servicing channels available in Windows 10, see [Servicing channels](#servicing-channels).
### Naming changes
As part of the alignment with Windows 10 and Office 365 ProPlus, we are adopting common terminology to make it as easy as possible to understand the servicing process. Going forward, these are the new terms we will be using:
* Semi-Annual Channel - We will be referring to Current Branch (CB) as "Semi-Annual Channel (Targeted)", while Current Branch for Business (CBB) will simply be referred to as "Semi-Annual Channel".
* Long-Term Servicing Channel -  The Long-Term Servicing Branch (LTSB) will be referred to as Long-Term Servicing Channel (LTSC).
>[!IMPORTANT]
>With each Semi-Annual Channel release, we recommend beginning deployment right away to devices selected for early adoption (targeted validation) and ramp up to full deployment at your discretion, regardless of the "Targeted" designation. This will enable you to gain access to new features, experiences, and integrated security as soon as possible. For more information, see the blog post [Windows 10 and the "disappearing" SAC-T](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-10-and-the-disappearing-SAC-T/ba-p/199747).
> [!NOTE]
>For additional information, see the section about [Servicing Channels](#servicing-channels).
>
>You can also read the blog post [Waas simplified and aligned](https://blogs.technet.microsoft.com/windowsitpro/2017/07/27/waas-simplified-and-aligned/), with details on this change.
> [!IMPORTANT]
> Devices on the Semi-Annual Channel (formerly called Current Branch for Business) must have their diagnostic data set to **1 (Basic)** or higher, in order to ensure that the service is performing at the expected quality. If diagnostic data is set to **0**, the device will be treated as if it were in the Semi-Annual Channel (Targeted)(formerly called Current Branch or CB) branch. For instructions to set the diagnostic data level, see [Configure the operating system diagnostic data level](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization#diagnostic-data-levels).
### Feature updates
With Windows 10, Microsoft will package new features into feature updates that can be deployed using existing management tools. Because feature updates are delivered more frequently than with previous Windows releases — twice per year, around March and September, rather than every 3–5 years — changes will be in bite-sized chunks rather than all at once and end user readiness time much shorter.
>[!TIP]
> The feature update cadence has been aligned with Office 365 ProPlus updates. Starting with this falls' update, both Windows and Office will deliver their major updates semi-annually, around March and September. See [upcoming changes to Office 365 ProPlus update management](https://support.office.com/article/Overview-of-the-upcoming-changes-to-Office-365-ProPlus-update-management-78b33779-9356-4cdf-9d2c-08350ef05cca) for more information about changes to Office update management.
### Quality updates
Monthly updates in previous Windows versions were often overwhelming because of the sheer number of updates available each month. Many organizations selectively chose which updates they wanted to install and which they didn’t, and this created countless scenarios in which organizations deployed essential security updates but picked only a subset of non-security fixes.
In Windows 10, rather than receiving several updates each month and trying to figure out which the organization needs, which ultimately causes platform fragmentation, administrators will see one cumulative monthly update that supersedes the previous month’s update, containing both security and non-security fixes. This approach makes patching simpler and ensures that customers’ devices are more closely aligned with the testing done at Microsoft, reducing unexpected issues resulting from patching. The left side of Figure 1 provides an example of Windows 7 devices in an enterprise and what their current patch level might look like. On the right is what Microsoft’s test environment PCs contain. This drastic difference is the basis for many compatibility issues and system anomalies related to Windows updates.
**Figure 1**
![Comparison of patch environment in enterprise compared to test](images/waas-overview-patch.png)
## Servicing channels
To align with the new method of delivering feature updates and quality updates in Windows 10, Microsoft introduced the concept of servicing channels to allow customers to designate how frequently their individual devices are updated. For example, an organization may have test devices that the IT department can update with new features as soon as possible, and then specialized devices that require a longer feature update cycle to ensure continuity.
With that in mind, Windows 10 offers 3 servicing channels. The [Windows Insider Program](#windows-insider) provides organizations with the opportunity to test and provide feedback on features that will be shipped in the next feature update. The [Semi-Annual Channel](#semi-annual-channel) provides new functionality with twice-per-year feature update releases. Organizations can choose when to deploy updates from the Semi-Annual Channel. The [Long Term Servicing Channel](#long-term-servicing-channel), which is designed to be used only for specialized devices (which typically don't run Office) such as those that control medical equipment or ATM machines, receives new feature releases every two to three years. For details about the versions in each servicing channel, see [Windows 10 release information](https://technet.microsoft.com/windows/release-info.aspx).
The concept of servicing channels is new, but organizations can use the same management tools they used to manage updates and upgrades in previous versions of Windows. For more information about the servicing tool options for Windows 10 and their capabilities, see [Servicing tools](#servicing-tools).
> [!NOTE]
> Servicing channels are not the only way to separate groups of devices when consuming updates. Each channel can contain subsets of devices, which staggers servicing even further. For information about the servicing strategy and ongoing deployment process for Windows 10, including the role of servicing channels, see [Plan servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md).
### Semi-Annual Channel
In the Semi-Annual servicing channel, feature updates are available as soon as Microsoft releases them. Windows 10, version 1511, had few servicing tool options to delay feature updates, limiting the use of the Semi-Annual servicing channel. Windows 10, version 1607 and onward, includes more servicing tools that can delay feature updates for up to 365 days. This servicing model is ideal for pilot deployments and testing of Windows 10 feature updates and for users such as developers who need to work with the latest features immediately. Once the latest release has gone through pilot deployment and testing, you will be able to choose the timing at which it goes into broad deployment.
When Microsoft officially releases a feature update for Windows 10, it is made available to any PC not configured to defer feature updates so that those devices can immediately install it. Organizations that use Windows Server Update Services (WSUS), Microsoft System Center Configuration Manager, or Windows Update for Business, however, can defer feature updates to selective devices by withholding their approval and deployment. In this scenario, the content available for the Semi-Annual Channel will be available but not necessarily immediately mandatory, depending on the policy of the management system. For more details about Windows 10 servicing tools, see [Servicing tools](#servicing-tools).
Organizations are expected to initiate targeted deployment on Semi-Annual Channel releases. All customers, independent software vendors (ISVs), and partners should use this time for testing and piloting within their environments. After 2-4 months, we will transition to broad deployment and encourage customers and partners to expand and accelerate the deployment of the release. For customers using Windows Update for Business, the Semi-Annual Channel provides three months of additional total deployment time before being required to update to the next release.
> [!NOTE]
> All releases of Windows 10 have 18 months of servicing for all editions--these updates provide security and feature updates for the release. Customers running Enterprise and Education editions have an additional 12 months of servicing for specific Windows 10 releases, for a total of 30 months from initial release. These versions include Enterprise and Education editions for Windows 10, versions 1607, 1703, 1709 and 1803. Starting in October 2018, all Semi-Annual Channel releases in the September/October timeframe will also have the additional 12 months of servicing for a total of 30 months from the initial release. The Semi-Annual Channel versions released in March/April timeframe will continue to have an 18 month lifecycle.
>
>
> [!NOTE]
> Organizations can electively delay feature updates into as many phases as they wish by using one of the servicing tools mentioned in the section Servicing tools.
### Long-term Servicing Channel
Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.
> [!NOTE]
> Windows 10 Enterprise LTSB is a separate Long Term Servicing Channel version.
>
> Long-term Servicing channel is not intended for deployment on most or all the PCs in an organization; it should be used only for special-purpose devices. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, typically used by an information worker, and therefore it is better suited for the Semi-Annual servicing channel.
Microsoft never publishes feature updates through Windows Update on devices that run Windows 10 Enterprise LTSB. Instead, it typically offers new LTSC releases every 2–3 years, and organizations can choose to install them as in-place upgrades or even skip releases over a 10-year life cycle.
> [!NOTE]
> Windows 10 LTSB will support the currently released processors and chipsets at the time of release of the LTSB. As future CPU generations are released, support will be created through future Windows 10 LTSB releases that customers can deploy for those systems. For more information, see **Supporting the latest processor and chipsets on Windows** in [Lifecycle support policy FAQ - Windows Products](https://support.microsoft.com/help/18581/lifecycle-support-policy-faq-windows-products).
The Long-term Servicing Channel is available only in the Windows 10 Enterprise LTSB edition. This edition of Windows doesn’t include a number of applications, such as Microsoft Edge, Microsoft Store, Cortana (though limited search capabilities remain available), Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock. These apps are not supported in Windows 10 Enterprise LTSB edition, even if you install by using sideloading.
> [!NOTE]
> If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.
### Windows Insider
For many IT pros, gaining visibility into feature updates early—before they’re available to the Semi-Annual Channel — can be both intriguing and valuable for future end user communications as well as provide the means to test for any issues on the next Semi-Annual Channel release. With Windows 10, feature flighting enables Windows Insiders to consume and deploy preproduction code to their test machines, gaining early visibility into the next build. Testing the early builds of Windows 10 helps both Microsoft and its customers because they have the opportunity to discover possible issues before the update is ever publicly available and can report it to Microsoft.
Microsoft recommends that all organizations have at least a few PCs enrolled in the Windows Insider Program and provide feedback on any issues they encounter. For information about the Windows Insider Program for Business, go to [Windows Insider Program for Business](waas-windows-insider-for-business.md).
> [!NOTE]
> Microsoft recommends that all organizations have at least a few PCs enrolled in the Windows Insider Program, to include the Windows Insider Program in their deployment plans and to provide feedback on any issues they encounter to Microsoft via our Feedback Hub app.
>
> The Windows Insider Program isn’t intended to replace Semi-Annual Channel deployments in an organization. Rather, it provides IT pros and other interested parties with pre-release Windows builds that they can test and ultimately provide feedback on to Microsoft.
## Servicing tools
There are many tools with which IT pros can service Windows as a service. Each option has its pros and cons, ranging from capabilities and control to simplicity and low administrative requirements. The following are examples of the servicing tools available to manage Windows as a service updates:
- **Windows Update (stand-alone)** provides limited control over feature updates, with IT pros manually configuring the device to be in the Semi-Annual Channel. Organizations can target which devices defer updates by selecting the Defer upgrades check box in Start\Settings\Update & Security\Advanced Options on a Windows 10 client.
- **Windows Update for Business** is the second option for servicing Windows as a service. This servicing tool includes control over update deferment and provides centralized management using Group Policy. Windows Update for Business can be used to defer updates by up to 365 days, depending on the version. These deployment options are available to clients in the Semi-Annual Channel. In addition to being able to use Group Policy to manage Windows Update for Business, either option can be configured without requiring any on-premises infrastructure by using Intune.
- **Windows Server Update Services (WSUS)** provides extensive control over Windows 10 updates and is natively available in the Windows Server operating system. In addition to the ability to defer updates, organizations can add an approval layer for updates and choose to deploy them to specific computers or groups of computers whenever ready.
- **System Center Configuration Manager** provides the greatest control over servicing Windows as a service. IT pros can defer updates, approve them, and have multiple options for targeting deployments and managing bandwidth usage and deployment times.
With all these options, which an organization chooses depends on the resources, staff, and expertise its IT organization already has. For example, if IT already uses System Center Configuration Manager to manage Windows updates, it can continue to use it. Similarly, if IT is using WSUS, it can continue to use that. For a consolidated look at the benefits of each tool, see Table 1.
**Table 1**
| Servicing tool | Can updates be deferred? | Ability to approve updates | Peer-to-peer option | Additional features |
| --- | --- | --- | --- | --- |
| Windows Update | Yes (manual) | No | Delivery Optimization | None|
| Windows Update for Business | Yes | No | Delivery Optimization | Other Group Policy objects |
| WSUS | Yes | Yes | BranchCache or Delivery Optimization | Upstream/downstream server scalability |
| Configuration Manager | Yes | Yes | BranchCache, Client Peer Cache | Distribution points, multiple deployment options |
> [!NOTE]
> Due to [naming changes](#naming-changes), older terms like CB,CBB and LTSB may still be displayed in some of our products.
</br>
## Steps to manage updates for Windows 10
| | |
| --- | --- |
| ![done](images/checklistdone.png) | Learn about updates and servicing channels (this topic) |
| ![to do](images/checklistbox.gif) | [Prepare servicing strategy for Windows 10 updates](waas-servicing-strategy-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Build deployment rings for Windows 10 updates](waas-deployment-rings-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Assign devices to servicing channels for Windows 10 updates](waas-servicing-channels-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Optimize update delivery for Windows 10 updates](waas-optimize-windows-10-updates.md) |
| ![to do](images/checklistbox.gif) | [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md)</br>or [Deploy Windows 10 updates using Windows Server Update Services](waas-manage-updates-wsus.md)</br>or [Deploy Windows 10 updates using System Center Configuration Manager](waas-manage-updates-configuration-manager.md) |
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Quick guide to Windows as a service](waas-quick-start.md)
- [Deploy updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)
- [Manage device restarts after updates](waas-restart.md)

240
windows/deployment/update/waas-servicing-differences.md
View File

@ -1,119 +1,121 @@
---
title: Servicing differences between Windows 10 and older operating systems
ms.reviewer:
manager: laurawi
description: Learn the differences between servicing Windows 10 and servicing older operating systems.
keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, tools
ms.prod: w10
ms.mktglfcycl: manage
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.audience: itpro author: greg-lindsay
ms.topic: article
ms.collection: M365-modern-desktop
---
# Understanding the differences between servicing Windows 10-era and legacy Windows operating systems
> Applies to: Windows 10
>
> **February 15, 2019: This document has been corrected and edited to reflect that security-only updates for legacy OS versions are not cumulative. They were previously identified as cumulative similar to monthly rollups, which is inaccurate.**
Today, many enterprise customers have a mix of modern and legacy client and server operating systems. Managing the servicing and updating differences between those legacy operating systems and Windows 10 versions adds a level of complexity that is not well understood. This can be confusing. With the end of support for legacy [Windows 7 SP1](https://support.microsoft.com/help/4057281/windows-7-support-will-end-on-january-14-2020) and Windows Server 2008 R2 variants on January 14, 2020, System Administrators have a critical need critical to understand how best to leverage a modern workplace to support system updates.
The following provides an initial overview of how updating client and server differs between the Windows 10-era Operating Systems (such as, Windows 10 version 1709, Windows Server 2016) and legacy operating systems (such as Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2).
>[!NOTE]
>A note on naming convention in this article: For brevity, "Windows 10" refers to all operating systems across client, server and IoT released since July 2015, while "legacy" refers to all operating systems prior to that period for client and server, including Windows 7, Window 8.1, Windows Server 2008 R2, Windows Server 2012 R2, etc.
## Infinite fragmentation
Prior to Windows 10, all updates to operating system (OS) components were published individually. On "Update Tuesday," customers would pick and choose individual updates they wanted to apply. Most chose to update security fixes, while far fewer selected non-security fixes, updated drivers, or installed .NET Framework updates.
As a result, each environment within the global Windows ecosystem that had only a subset of security and non-security fixes installed had a different set of binaries and behaviors than those that consistently installed every available update as tested by Microsoft.
This resulted in a fragmented ecosystem that created diverse challenges in predictively testing interoperability, resulting in high update failure rates - which were subsequently mitigated by customers removing individual updates that were causing issues. Each customer that selectively removed individual updates amplified this fragmentation by creating more diverse environment permutations across the ecosystem. As an IT Administrator once quipped, "If you’ve seen one Windows 7 PC, you have seen one Windows 7 PC," suggesting no consistency or predictability across more than 250M commercial devices at the time.
## Windows 10 – Next generation
Windows 10 provided an opportunity to end the era of infinite fragmentation. With Windows 10 and the Windows as a service model, updates came rolled together in the "latest cumulative update" (LCU) packages for both client and server. Every new update published includes all changes from previous updates, as well as new fixes. Since Windows client and server share the same code base, these LCUs allow the same update to be installed on the same client and server OS family, further reducing fragmentation.
This helps simplify servicing. Devices with the original Release to Market (RTM) version of a feature release installed could get up to date by installing the most recent LCU.
Windows publishes the new LCU packages for each Windows 10 version (1607, 1709, etc.) on the second Tuesday of each month. This package is classified as a required security update and contains contents from the previous LCU as well as new security, non-security and Internet Explorer 11 (IE11) fixes. The security classification, by definition, requires a reboot of the device to complete installation of the update.
![High level cumulative update model](images/servicing-cadence.png)
*Figure 1.0 - High level cumulative update model*
Another benefit of the LCU model is fewer steps. Devices that have the original Release to Market (RTM) version of a release can install the most recent LCU to get up to date in one step, rather than having to install multiple updates with reboots after each.
This cumulative update model for Windows 10 has helped provide the Windows ecosystem with consistent update experiences that can be predicted by baseline testing before release. Even with highly complex updates with hundreds of fixes, the number of incidents with monthly security updates for Windows 10 have fallen month over month since the initial release of Windows 10.
### Points to consider
- Windows 10 does not have the concept of a Security-Only or Monthly Rollup for updates. All updates are an LCU package, which includes the last release plus anything new.
- Windows 10 no longer has the concept of a "hotfix" since all individual updates must be rolled into the cumulative packages. (Note: Any private fix is offered for customer validation only, and then rolled into an LCU.)
- [Updates for the .NET Framework](https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/) are NOT included in the Windows 10 LCU. They are separate packages with different behaviors depending on the version of .NET Framework being updated, and on which OS. As of October 2018, .NET Framework updates for Windows 10 will be separate and have their own cumulative update model.
- For Windows 10, available update types vary by publishing channel:
- For customers using Windows Server Update Services (WSUS) and for the Update Catalog, several different updates types for Windows 10 are rolled together for the core OS in a single LCU package, with exception of Servicing Stack Updates.
- Servicing Stack Updates (SSU) are available for download from the Update Catalog and can be imported through WSUS. Servicing Stack Updates (SSU) will be synced automatically (See this example for Windows 10, version 1709). Learn more about [Servicing Stack Updates](https://docs.microsoft.com/windows/deployment/update/servicing-stack-updates).
- For customers connecting to Windows Update, the new cloud update architecture uses a database of updates which break out all the different update types, including Servicing Stack Updates (SSU) and Dynamic Updates (DU). The update scanning in the Windows 10 servicing stack on the client automatically takes only the updates that are needed by the device to be completely up to date.
- Windows 7 and other legacy operating systems have cumulative updates that operate differently than in Windows 10 (see next section).
## Windows 7 and legacy OS versions
While Windows 10 updates could have been controlled as cumulative from "Day 1," the legacy OS ecosystem for both client and server was highly fragmented. Recognizing the challenges of update quality in a fragmented environment, we moved Windows 7 to a cumulative update model in October 2016.
Customers saw the LCU model used for Windows 10 as having packages that were too large and represented too much of a change for legacy operating systems, so a different model was implemented. Windows instead offered one cumulative package (Monthly Rollup) and one individual package (Security Only) for all legacy operating systems.
The Monthly Rollup includes new non-security (if appropriate), security updates, Internet Explorer (IE) updates, and all updates from the previous month similar to the Windows 10 model. The Security-only package includes only new security updates for the month. This means that any security updates from any previous month are not included in current month’s Security-Only Package. If a Security-Only update is missed, it is missed. Those updates will not appear in a future Security-Only update. Additionally, a cumulative package is offered for IE, which can be tested and installed separately, reducing the total update package size. The IE cumulative update includes both security and non-security fixes following the same model as Windows 10.
![Legacy OS security-only update model](images/security-only-update.png)
*Figure 2.0 - Legacy OS security-only update model*
Moving to the cumulative model for legacy OS versions continues to improve predictability of update quality. The Windows legacy environments which have fully updated machines with Monthly Rollups are running the same baseline against which all legacy OS version updates are tested. These include all of the updates (security and non-security) prior to and after October 2016. Many customer environments do not have all updates prior to this change installed, which leaves some continued fragmentation in the ecosystem. Further, customers who are installing Security-Only Updates and potentially doing so inconsistently are also more fragmented than Microsoft’s test environments for legacy OS version. This remaining fragmentation results in issues like those seen when the September 2016 Servicing Stack Update (SSU) was needed for smooth installation of the August 2018 security update. These environments did not have the SSU applied previously.
### Points to consider
- Windows 7 and Windows 8 legacy operating system updates [moved from individual to cumulative in October 2016](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/More-on-Windows-7-and-Windows-8-1-servicing-changes/ba-p/166783). Devices with updates missing prior to that point are still missing those updates, as they were not included in the subsequent cumulative packages.
- "Hotfixes" are no longer published for legacy OS versions. All updates are rolled into the appropriate package depending on their classification as either non-security, security, or Internet Explorer updates. (Note: any private fix is offered for customer validation only. Once validated they are then rolled into a Monthly Rollup or IE cumulative update, as appropriate.)
- Both Monthly Rollups and Security-only updates released on Update Tuesday for legacy OS versions are identified as "security required" updates, because both have the full set of security updates in them. The Monthly Rollup may have additional non-security updates that are not included in the Security Only update. The "security" classification requires the device be rebooted so the update can be fully installed.
- Given the differences between the cumulative Monthly Rollups and the single-month Security-only update packages, switching between these update types is not advised. Differences in the baselines of these packages may result in installation errors and conflicts. Choosing one and staying on that update type with high consistency – Monthly Rollup or Security-only – is recommended.
- With all Legacy OS versions now in the Extended Support stage of their 10-year lifecycle, they typically receive only security updates for both Monthly Rollup and Security Only updates. Using Express for the Monthly Rollup results in almost the same package size as Security Only, with the added confidence of ensuring all relevant updates are installed.
- In [February 2017](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Simplified-servicing-for-Windows-7-and-Windows-8-1-the-latest/ba-p/166798), Windows pulled IE updates out of the legacy OS versions Security-only updates, while leaving them in the Monthly Rollup updates. This was done specifically to reduce package size based on customer feedback.
- The IE cumulative update includes both security and non-security updates and is also needed for to help secure the entire environment. This update can be installed separately or as part of the Monthly Rollup.
- [Updates for .NET Framework](https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/) are NOT included in legacy Monthly Rollup or Security Only packages. They are separate packages with different behaviors depending on the version of the .NET Framework, and which legacy OS, being updated.
- For [Windows Server 2008 SP2](https://cloudblogs.microsoft.com/windowsserver/2018/06/12/windows-server-2008-sp2-servicing-changes/), cumulative updates began in October 2018, and follow the same model as Windows 7. Updates for IE9 are included in those packages, as the last supported version of Internet Explorer for that Legacy OS version.
## Public preview releases
Lastly, the cumulative update model directly impacts the public Preview releases offered in the 3rd and/or 4th weeks of the month. Update Tuesday, also referred to as the "B" week release occurs on the second Tuesday of the month. It is always a required security update across all operating systems. In addition to this monthly release, Windows also releases non-security update "previews" targeting the 3rd (C) and the 4th (D) weeks of the month. These preview releases include that month’s B-release plus a set of non-security updates for testing and validation as a cumulative package. We recommend IT Administrators uses the C/D previews to test the update in their environments. Any issues identified with the updates in the C/D releases are identified and then fixed or removed, prior to being rolled up in to the next month’s B release package together with new security updates. Security-only Packages are not part of the C/D preview program.
### Examples
Windows 10 version 1709:
- (9B) September 11, 2018 Update Tuesday / B release - includes security, non-security and IE update. This update is categorized as "Required, Security" it requires a system reboot.
- (9C) September 26, 2018 Preview C release - includes everything from 9B PLUS some non-security updates for testing/validation. This update is qualified as not required, non-security. No system reboot is required.
- (10B) October 9, 2018 Update Tuesday / B release includes all fixes included in 9B, all fixes in 9C and introduces new security fixes and IE updates. This update is qualified as "Required, Security" and requires a system reboot.
All of these updates are cumulative and build on each other for Windows 10. This is in contrast to legacy OS versions, where the 9C release becomes part of the "Monthly Rollup," but not the "Security Only" update. In other words, a Window 7 SP1 9C update is part of the cumulative "Monthly Rollup" but not included in the "Security Only" update because the fixes are qualified as "non-security". This is an important variation to note on the two models.
![Preview releases in the Windows 10 LCU model](images/servicing-previews.png)
*Figure 3.0 - Preview releases within the Windows 10 LCU model*
## Previews vs. on-demand releases
In 2018, we experienced incidents which required urgent remediation that didn’t map to the monthly update release cadence. These incidents were situations that required an immediate fix to an Update Tuesday release. While Windows engineering worked aggressively to respond within a week of the B-release, these "on-demand" releases created confusion with the C Preview releases.
As a general policy, if a Security-Only package has a regression, which is defined as an unintentional error in the code of an update, then the fix for that regression will be added to the next month’s Security-Only Update. The fix for that regression may also be offered as part an On-Demand release and will be rolled into the next Monthly Update. (Note: Exceptions do exist to this policy, based on timing.)
### Point to consider
- When Windows identifies an issue with a Update Tuesday release, engineering teams work to remediate or fix the issue as quickly as possible. The outcome is often a new update which may be released at any time, including during the 3rd or 4th week of the month. Such updates are independent of the regularly scheduled "C" and "D" update previews. These updates are created on-demand to remediate a customer impacting issue. In most cases they are qualified as a "non-security" update, and do not require a system reboot.
- Rarely do incidents with Update Tuesday releases impact more than .1% of the total population. With the new Windows Update (WU) architecture, updates can be targeted to affected devices. This targeting is not available through the Update Catalog or WSUS channels, however.
- On-demand releases address a specific issue with an Update Tuesday release and are often qualified as "non-security" for one of two reasons. First, the fix may not be an additional security fix, but a non-security change to the update. Second, the "non-security" designation allows individuals or companies to choose when and how to reboot the devices, rather than forcing a system reboot on all Windows devices receiving the update globally. This trade-off is rarely a difficult choice as it has the potential to impact customer experience across client and server, across consumer and commercial customers for more than one billion devices.
- Because the cumulative model is used across Window 10 and legacy Windows OS versions, despite variations between these OS versions, an out of band release will include all of the changes from the Update Tuesday release plus the fix that addresses the issue. And since Windows no longer releases hotfixes, everything is cumulative in some way.
In closing, I hope this overview of the update model across current and legacy Windows OS versions highlights the benefits of the Windows 10 cumulative update model to help defragment the Windows ecosystem environments, simplify servicing and help make systems more secure.
## Resources
- [Simplifying updates for Windows 7 and 8.1](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Simplifying-updates-for-Windows-7-and-8-1/ba-p/166530)
- [Further simplifying servicing models for Windows 7 and Windows 8.1](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Further-simplifying-servicing-models-for-Windows-7-and-Windows-8/ba-p/166772)
- [More on Windows 7 and Windows 8.1 servicing changes](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/More-on-Windows-7-and-Windows-8-1-servicing-changes/ba-p/166783)
- [.NET Framework Monthly Rollups Explained](https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/)
- [Simplified servicing for Windows 7 and Windows 8.1: the latest improvements](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Simplified-servicing-for-Windows-7-and-Windows-8-1-the-latest/ba-p/166798)
- [Windows Server 2008 SP2 servicing changes](https://cloudblogs.microsoft.com/windowsserver/2018/06/12/windows-server-2008-sp2-servicing-changes/)
- [Windows 10 update servicing cadence](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-10-update-servicing-cadence/ba-p/222376)
- [Windows 7 servicing stack updates: managing change and appreciating cumulative updates](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-7-servicing-stack-updates-managing-change-and/ba-p/260434)
---
title: Servicing differences between Windows 10 and older operating systems
ms.reviewer:
manager: laurawi
description: Learn the differences between servicing Windows 10 and servicing older operating systems.
keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, tools
ms.prod: w10
ms.mktglfcycl: manage
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.audience: itpro
author: greg-lindsay
ms.topic: article
ms.collection: M365-modern-desktop
---
# Understanding the differences between servicing Windows 10-era and legacy Windows operating systems
> Applies to: Windows 10
>
> **February 15, 2019: This document has been corrected and edited to reflect that security-only updates for legacy OS versions are not cumulative. They were previously identified as cumulative similar to monthly rollups, which is inaccurate.**
Today, many enterprise customers have a mix of modern and legacy client and server operating systems. Managing the servicing and updating differences between those legacy operating systems and Windows 10 versions adds a level of complexity that is not well understood. This can be confusing. With the end of support for legacy [Windows 7 SP1](https://support.microsoft.com/help/4057281/windows-7-support-will-end-on-january-14-2020) and Windows Server 2008 R2 variants on January 14, 2020, System Administrators have a critical need to understand how best to leverage a modern workplace to support system updates.
The following provides an initial overview of how updating client and server differs between the Windows 10-era Operating Systems (such as, Windows 10 version 1709, Windows Server 2016) and legacy operating systems (such as Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2).
>[!NOTE]
>A note on naming convention in this article: For brevity, "Windows 10" refers to all operating systems across client, server and IoT released since July 2015, while "legacy" refers to all operating systems prior to that period for client and server, including Windows 7, Window 8.1, Windows Server 2008 R2, Windows Server 2012 R2, etc.
## Infinite fragmentation
Prior to Windows 10, all updates to operating system (OS) components were published individually. On "Update Tuesday," customers would pick and choose individual updates they wanted to apply. Most chose to update security fixes, while far fewer selected non-security fixes, updated drivers, or installed .NET Framework updates.
As a result, each environment within the global Windows ecosystem that had only a subset of security and non-security fixes installed had a different set of binaries and behaviors than those that consistently installed every available update as tested by Microsoft.
This resulted in a fragmented ecosystem that created diverse challenges in predictively testing interoperability, resulting in high update failure rates - which were subsequently mitigated by customers removing individual updates that were causing issues. Each customer that selectively removed individual updates amplified this fragmentation by creating more diverse environment permutations across the ecosystem. As an IT Administrator once quipped, "If you’ve seen one Windows 7 PC, you have seen one Windows 7 PC," suggesting no consistency or predictability across more than 250M commercial devices at the time.
## Windows 10 – Next generation
Windows 10 provided an opportunity to end the era of infinite fragmentation. With Windows 10 and the Windows as a service model, updates came rolled together in the "latest cumulative update" (LCU) packages for both client and server. Every new update published includes all changes from previous updates, as well as new fixes. Since Windows client and server share the same code base, these LCUs allow the same update to be installed on the same client and server OS family, further reducing fragmentation.
This helps simplify servicing. Devices with the original Release to Market (RTM) version of a feature release installed could get up to date by installing the most recent LCU.
Windows publishes the new LCU packages for each Windows 10 version (1607, 1709, etc.) on the second Tuesday of each month. This package is classified as a required security update and contains contents from the previous LCU as well as new security, non-security and Internet Explorer 11 (IE11) fixes. The security classification, by definition, requires a reboot of the device to complete installation of the update.
![High level cumulative update model](images/servicing-cadence.png)
*Figure 1.0 - High level cumulative update model*
Another benefit of the LCU model is fewer steps. Devices that have the original Release to Market (RTM) version of a release can install the most recent LCU to get up to date in one step, rather than having to install multiple updates with reboots after each.
This cumulative update model for Windows 10 has helped provide the Windows ecosystem with consistent update experiences that can be predicted by baseline testing before release. Even with highly complex updates with hundreds of fixes, the number of incidents with monthly security updates for Windows 10 have fallen month over month since the initial release of Windows 10.
### Points to consider
- Windows 10 does not have the concept of a Security-Only or Monthly Rollup for updates. All updates are an LCU package, which includes the last release plus anything new.
- Windows 10 no longer has the concept of a "hotfix" since all individual updates must be rolled into the cumulative packages. (Note: Any private fix is offered for customer validation only, and then rolled into an LCU.)
- [Updates for the .NET Framework](https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/) are NOT included in the Windows 10 LCU. They are separate packages with different behaviors depending on the version of .NET Framework being updated, and on which OS. As of October 2018, .NET Framework updates for Windows 10 will be separate and have their own cumulative update model.
- For Windows 10, available update types vary by publishing channel:
- For customers using Windows Server Update Services (WSUS) and for the Update Catalog, several different updates types for Windows 10 are rolled together for the core OS in a single LCU package, with exception of Servicing Stack Updates.
- Servicing Stack Updates (SSU) are available for download from the Update Catalog and can be imported through WSUS. Servicing Stack Updates (SSU) will be synced automatically (See this example for Windows 10, version 1709). Learn more about [Servicing Stack Updates](https://docs.microsoft.com/windows/deployment/update/servicing-stack-updates).
- For customers connecting to Windows Update, the new cloud update architecture uses a database of updates which break out all the different update types, including Servicing Stack Updates (SSU) and Dynamic Updates (DU). The update scanning in the Windows 10 servicing stack on the client automatically takes only the updates that are needed by the device to be completely up to date.
- Windows 7 and other legacy operating systems have cumulative updates that operate differently than in Windows 10 (see next section).
## Windows 7 and legacy OS versions
While Windows 10 updates could have been controlled as cumulative from "Day 1," the legacy OS ecosystem for both client and server was highly fragmented. Recognizing the challenges of update quality in a fragmented environment, we moved Windows 7 to a cumulative update model in October 2016.
Customers saw the LCU model used for Windows 10 as having packages that were too large and represented too much of a change for legacy operating systems, so a different model was implemented. Windows instead offered one cumulative package (Monthly Rollup) and one individual package (Security Only) for all legacy operating systems.
The Monthly Rollup includes new non-security (if appropriate), security updates, Internet Explorer (IE) updates, and all updates from the previous month similar to the Windows 10 model. The Security-only package includes only new security updates for the month. This means that any security updates from any previous month are not included in current month’s Security-Only Package. If a Security-Only update is missed, it is missed. Those updates will not appear in a future Security-Only update. Additionally, a cumulative package is offered for IE, which can be tested and installed separately, reducing the total update package size. The IE cumulative update includes both security and non-security fixes following the same model as Windows 10.
![Legacy OS security-only update model](images/security-only-update.png)
*Figure 2.0 - Legacy OS security-only update model*
Moving to the cumulative model for legacy OS versions continues to improve predictability of update quality. The Windows legacy environments which have fully updated machines with Monthly Rollups are running the same baseline against which all legacy OS version updates are tested. These include all of the updates (security and non-security) prior to and after October 2016. Many customer environments do not have all updates prior to this change installed, which leaves some continued fragmentation in the ecosystem. Further, customers who are installing Security-Only Updates and potentially doing so inconsistently are also more fragmented than Microsoft’s test environments for legacy OS version. This remaining fragmentation results in issues like those seen when the September 2016 Servicing Stack Update (SSU) was needed for smooth installation of the August 2018 security update. These environments did not have the SSU applied previously.
### Points to consider
- Windows 7 and Windows 8 legacy operating system updates [moved from individual to cumulative in October 2016](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/More-on-Windows-7-and-Windows-8-1-servicing-changes/ba-p/166783). Devices with updates missing prior to that point are still missing those updates, as they were not included in the subsequent cumulative packages.
- "Hotfixes" are no longer published for legacy OS versions. All updates are rolled into the appropriate package depending on their classification as either non-security, security, or Internet Explorer updates. (Note: any private fix is offered for customer validation only. Once validated they are then rolled into a Monthly Rollup or IE cumulative update, as appropriate.)
- Both Monthly Rollups and Security-only updates released on Update Tuesday for legacy OS versions are identified as "security required" updates, because both have the full set of security updates in them. The Monthly Rollup may have additional non-security updates that are not included in the Security Only update. The "security" classification requires the device be rebooted so the update can be fully installed.
- Given the differences between the cumulative Monthly Rollups and the single-month Security-only update packages, switching between these update types is not advised. Differences in the baselines of these packages may result in installation errors and conflicts. Choosing one and staying on that update type with high consistency – Monthly Rollup or Security-only – is recommended.
- With all Legacy OS versions now in the Extended Support stage of their 10-year lifecycle, they typically receive only security updates for both Monthly Rollup and Security Only updates. Using Express for the Monthly Rollup results in almost the same package size as Security Only, with the added confidence of ensuring all relevant updates are installed.
- In [February 2017](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Simplified-servicing-for-Windows-7-and-Windows-8-1-the-latest/ba-p/166798), Windows pulled IE updates out of the legacy OS versions Security-only updates, while leaving them in the Monthly Rollup updates. This was done specifically to reduce package size based on customer feedback.
- The IE cumulative update includes both security and non-security updates and is also needed for to help secure the entire environment. This update can be installed separately or as part of the Monthly Rollup.
- [Updates for .NET Framework](https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/) are NOT included in legacy Monthly Rollup or Security Only packages. They are separate packages with different behaviors depending on the version of the .NET Framework, and which legacy OS, being updated.
- For [Windows Server 2008 SP2](https://cloudblogs.microsoft.com/windowsserver/2018/06/12/windows-server-2008-sp2-servicing-changes/), cumulative updates began in October 2018, and follow the same model as Windows 7. Updates for IE9 are included in those packages, as the last supported version of Internet Explorer for that Legacy OS version.
## Public preview releases
Lastly, the cumulative update model directly impacts the public Preview releases offered in the 3rd and/or 4th weeks of the month. Update Tuesday, also referred to as the "B" week release occurs on the second Tuesday of the month. It is always a required security update across all operating systems. In addition to this monthly release, Windows also releases non-security update "previews" targeting the 3rd (C) and the 4th (D) weeks of the month. These preview releases include that month’s B-release plus a set of non-security updates for testing and validation as a cumulative package. We recommend IT Administrators uses the C/D previews to test the update in their environments. Any issues identified with the updates in the C/D releases are identified and then fixed or removed, prior to being rolled up in to the next month’s B release package together with new security updates. Security-only Packages are not part of the C/D preview program.
### Examples
Windows 10 version 1709:
- (9B) September 11, 2018 Update Tuesday / B release - includes security, non-security and IE update. This update is categorized as "Required, Security" it requires a system reboot.
- (9C) September 26, 2018 Preview C release - includes everything from 9B PLUS some non-security updates for testing/validation. This update is qualified as not required, non-security. No system reboot is required.
- (10B) October 9, 2018 Update Tuesday / B release includes all fixes included in 9B, all fixes in 9C and introduces new security fixes and IE updates. This update is qualified as "Required, Security" and requires a system reboot.
All of these updates are cumulative and build on each other for Windows 10. This is in contrast to legacy OS versions, where the 9C release becomes part of the "Monthly Rollup," but not the "Security Only" update. In other words, a Window 7 SP1 9C update is part of the cumulative "Monthly Rollup" but not included in the "Security Only" update because the fixes are qualified as "non-security". This is an important variation to note on the two models.
![Preview releases in the Windows 10 LCU model](images/servicing-previews.png)
*Figure 3.0 - Preview releases within the Windows 10 LCU model*
## Previews vs. on-demand releases
In 2018, we experienced incidents which required urgent remediation that didn’t map to the monthly update release cadence. These incidents were situations that required an immediate fix to an Update Tuesday release. While Windows engineering worked aggressively to respond within a week of the B-release, these "on-demand" releases created confusion with the C Preview releases.
As a general policy, if a Security-Only package has a regression, which is defined as an unintentional error in the code of an update, then the fix for that regression will be added to the next month’s Security-Only Update. The fix for that regression may also be offered as part an On-Demand release and will be rolled into the next Monthly Update. (Note: Exceptions do exist to this policy, based on timing.)
### Point to consider
- When Windows identifies an issue with a Update Tuesday release, engineering teams work to remediate or fix the issue as quickly as possible. The outcome is often a new update which may be released at any time, including during the 3rd or 4th week of the month. Such updates are independent of the regularly scheduled "C" and "D" update previews. These updates are created on-demand to remediate a customer impacting issue. In most cases they are qualified as a "non-security" update, and do not require a system reboot.
- Rarely do incidents with Update Tuesday releases impact more than .1% of the total population. With the new Windows Update (WU) architecture, updates can be targeted to affected devices. This targeting is not available through the Update Catalog or WSUS channels, however.
- On-demand releases address a specific issue with an Update Tuesday release and are often qualified as "non-security" for one of two reasons. First, the fix may not be an additional security fix, but a non-security change to the update. Second, the "non-security" designation allows individuals or companies to choose when and how to reboot the devices, rather than forcing a system reboot on all Windows devices receiving the update globally. This trade-off is rarely a difficult choice as it has the potential to impact customer experience across client and server, across consumer and commercial customers for more than one billion devices.
- Because the cumulative model is used across Window 10 and legacy Windows OS versions, despite variations between these OS versions, an out of band release will include all of the changes from the Update Tuesday release plus the fix that addresses the issue. And since Windows no longer releases hotfixes, everything is cumulative in some way.
In closing, I hope this overview of the update model across current and legacy Windows OS versions highlights the benefits of the Windows 10 cumulative update model to help defragment the Windows ecosystem environments, simplify servicing and help make systems more secure.
## Resources
- [Simplifying updates for Windows 7 and 8.1](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Simplifying-updates-for-Windows-7-and-8-1/ba-p/166530)
- [Further simplifying servicing models for Windows 7 and Windows 8.1](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Further-simplifying-servicing-models-for-Windows-7-and-Windows-8/ba-p/166772)
- [More on Windows 7 and Windows 8.1 servicing changes](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/More-on-Windows-7-and-Windows-8-1-servicing-changes/ba-p/166783)
- [.NET Framework Monthly Rollups Explained](https://blogs.msdn.microsoft.com/dotnet/2016/10/11/net-framework-monthly-rollups-explained/)
- [Simplified servicing for Windows 7 and Windows 8.1: the latest improvements](https://techcommunity.microsoft.com/t5/Windows-Blog-Archive/Simplified-servicing-for-Windows-7-and-Windows-8-1-the-latest/ba-p/166798)
- [Windows Server 2008 SP2 servicing changes](https://cloudblogs.microsoft.com/windowsserver/2018/06/12/windows-server-2008-sp2-servicing-changes/)
- [Windows 10 update servicing cadence](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-10-update-servicing-cadence/ba-p/222376)
- [Windows 7 servicing stack updates: managing change and appreciating cumulative updates](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-7-servicing-stack-updates-managing-change-and/ba-p/260434)

526
windows/deployment/update/waas-wu-settings.md
View File

@ -1,262 +1,264 @@
---
title: Manage additional Windows Update settings (Windows 10)
description: Additional settings to control the behavior of Windows Update (WU) in Windows 10
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.localizationpriority: medium
ms.audience: itpro author: greg-lindsay
ms.date: 07/27/2017
ms.reviewer:
manager: laurawi
ms.topic: article
---
# Manage additional Windows Update settings
**Applies to**
- Windows 10
- Windows 10 Mobile
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
You can use Group Policy settings or mobile device management (MDM) to configure the behavior of Windows Update (WU) on your Windows 10 devices. You can configure the update detection frequency, select when updates are received, specify the update service location and more.
>[!IMPORTANT]
>In Windows 10, any Group Policy user configuration settings for Windows Update were deprecated and are no longer supported on this platform.
## Summary of Windows Update settings
| Group Policy setting | MDM setting | Supported from version |
| --- | --- | --- |
| [Specify Intranet Microsoft update service location](#specify-intranet-microsoft-update-service-location) | [UpdateServiceUrl](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurl) and [UpdateServiceUrlAlternate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurlalternate) | All |
| [Automatic Updates Detection Frequency](#automatic-updates-detection-frequency) | [DetectionFrequency](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-detectionfrequency) | 1703 |
| [Remove access to use all Windows Update features](#remove-access-to-use-all-windows-update-features) | | All |
| [Do not connect to any Windows Update Internet locations](#do-not-connect-to-any-windows-update-internet-locations) | | All |
| [Enable client-side targeting](#enable-client-side-targeting) | | All |
| [Allow signed updates from an intranet Microsoft update service location](#allow-signed-updates-from-an-intranet-microsoft-update-service-location) | [AllowNonMicrosoftSignedUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-allownonmicrosoftsignedupdate) | All |
| [Do not include drivers with Windows Updates](#do-not-include-drivers-with-windows-updates) | [ExcludeWUDriversInQualityUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-excludewudriversinqualityupdate) | 1607 |
| [Configure Automatic Updates](#configure-automatic-updates) | [AllowAutoUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-allowautoupdate) | All |
>[!IMPORTANT]
>Additional information about settings to manage device restarts and restart notifications for updates is available on **[Manage device restarts after updates](waas-restart.md)**.
>
>Additional settings that configure when Feature and Quality updates are received are detailed on **[Configure Windows Update for Business](waas-configure-wufb.md)**.
## Scanning for updates
With Windows 10, admins have a lot of flexibility in configuring how their devices scan and receive updates.
[Specify Intranet Microsoft update service location](#specify-intranet-microsoft-update-service-location) allows admins to point devices to an internal Microsoft update service location, while [Do not connect to any Windows Update Internet locations](#do-not-connect-to-any-windows-update-internet-locations) gives them to option to restrict devices to just that internal update service. [Automatic Updates Detection Frequency](#automatic-updates-detection-frequency) controls how frequently devices scan for updates.
You can make custom device groups that'll work with your internal Microsoft update service by using [Enable client-side targeting](#enable-client-side-targeting). You can also make sure your devices receive updates that were not signed by Microsoft from your internal Microsoft update service, through [Allow signed updates from an intranet Microsoft update service location](#allow-signed-updates-from-an-intranet-microsoft-update-service-location).
Finally, to make sure the updating experience is fully controlled by the admins, you can [Remove access to use all Windows Update features](#remove-access-to-use-all-windows-update-features) for users.
For additional settings that configure when Feature and Quality updates are received, see [Configure Windows Update for Business](waas-configure-wufb.md).
### Specify Intranet Microsoft update service location
Specifies an intranet server to host updates from Microsoft Update. You can then use this update service to automatically update computers on your network.
This setting lets you specify a server on your network to function as an internal update service. The Automatic Updates client will search this service for updates that apply to the computers on your network.
To use this setting in Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update\Specify Intranet Microsoft update service location**. You must set two server name values: the server from which the Automatic Updates client detects and downloads updates, and the server to which updated workstations upload statistics. You can set both values to be the same server. An optional server name value can be specified to configure Windows Update Agent to download updates from an alternate download server instead of the intranet update service.
If the setting is set to **Enabled**, the Automatic Updates client connects to the specified intranet Microsoft update service (or alternate download server), instead of Windows Update, to search for and download updates. Enabling this setting means that end users in your organization don’t have to go through a firewall to get updates, and it gives you the opportunity to test updates after deploying them.
If the setting is set to **Disabled** or **Not Configured**, and if Automatic Updates is not disabled by policy or user preference, the Automatic Updates client connects directly to the Windows Update site on the Internet.
The alternate download server configures the Windows Update Agent to download files from an alternative download server instead of the intranet update service.
The option to download files with missing Urls allows content to be downloaded from the Alternate Download Server when there are no download Urls for files in the update metadata. This option should only be used when the intranet update service does not provide download Urls in the update metadata for files which are present on the alternate download server.
>[!NOTE]
>If the "Configure Automatic Updates" policy is disabled, then this policy has no effect.
>
>If the "Alternate Download Server" is not set, it will use the intranet update service by default to download updates.
>
>The option to "Download files with no Url..." is only used if the "Alternate Download Server" is set.
To configure this policy with MDM, use [UpdateServiceUrl](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurl) and [UpdateServiceUrlAlternate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurlalternate).
### Automatic Updates detection frequency
Specifies the hours that Windows will use to determine how long to wait before checking for available updates. The exact wait time is determined by using the hours specified here minus zero to twenty percent of the hours specified. For example, if this policy is used to specify a 20-hour detection frequency, then all clients to which this policy is applied will check for updates anywhere between 16 to 20 hours.
To set this setting with Group Policy, navigate to **Computer Configuration\Administrative Templates\Windows Components\Windows Update\Automatic Updates detection frequency**.
If the setting is set to **Enabled**, Windows will check for available updates at the specified interval.
If the setting is set to **Disabled** or **Not Configured**, Windows will check for available updates at the default interval of 22 hours.
>[!NOTE]
>The “Specify intranet Microsoft update service location” setting must be enabled for this policy to have effect.
>
>If the “Configure Automatic Updates” policy is disabled, this policy has no effect.
To configure this policy with MDM, use [DetectionFrequency](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-detectionfrequency).
### Remove access to use all Windows Update features
By enabling the Group Policy setting under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Remove access to use all Windows update features**, administrators can disable the "Check for updates" option for users. Any background update scans, downloads and installations will continue to work as configured.
### Do not connect to any Windows Update Internet locations
Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update or the Microsoft Store.
Use **Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not connect to any Windows Update Internet locations** to enable this policy. When enabled, this policy will disable the functionality described above, and may cause connection to public services such as the Microsoft Store, Windows Update for Business and Delivery Optimization to stop working.
>[!NOTE]
>This policy applies only when the device is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy.
### Enable client-side targeting
Specifies the target group name or names that should be used to receive updates from an intranet Microsoft update service. This allows admins to configure device groups that will receive different updates from sources like WSUS or SCCM.
This Group Policy setting can be found under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Enable client-side targeting**.
If the setting is set to **Enabled**, the specified target group information is sent to the intranet Microsoft update service which uses it to determine which updates should be deployed to this computer.
If the setting is set to **Disabled** or **Not Configured**, no target group information will be sent to the intranet Microsoft update service.
If the intranet Microsoft update service supports multiple target groups, this policy can specify multiple group names separated by semicolons. Otherwise, a single group must be specified.
>[!NOTE]
>This policy applies only when the intranet Microsoft update service the device is directed to is configured to support client-side targeting. If the “Specify intranet Microsoft update service location” policy is disabled or not configured, this policy has no effect.
### Allow signed updates from an intranet Microsoft update service location
This policy setting allows you to manage whether Automatic Updates accepts updates signed by entities other than Microsoft when the update is found on an intranet Microsoft update service location.
To configure this setting in Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows update\Allow signed updates from an intranet Microsoft update service location**.
If you enable this policy setting, Automatic Updates accepts updates received through an intranet Microsoft update service location, as specified by [Specify Intranet Microsoft update service location](#specify-intranet-microsoft-update-service-location), if they are signed by a certificate found in the “Trusted Publishers” certificate store of the local computer.
If you disable or do not configure this policy setting, updates from an intranet Microsoft update service location must be signed by Microsoft.
>[!NOTE]
>Updates from a service other than an intranet Microsoft update service must always be signed by Microsoft and are not affected by this policy setting.
To configure this policy with MDM, use [AllowNonMicrosoftSignedUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-allownonmicrosoftsignedupdate).
## Installing updates
To add more flexibility to the update process, settings are available to control update installation.
[Configure Automatic Updates](#configure-automatic-updates) offers 4 different options for automatic update installation, while [Do not include drivers with Windows Updates](#do-not-include-drivers-with-windows-updates) makes sure drivers are not installed with the rest of the received updates.
### Do not include drivers with Windows Updates
Allows admins to exclude Windows Update (WU) drivers during updates.
To configure this setting in Group Policy, use **Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not include drivers with Windows Updates**.
Enable this policy to not include drivers with Windows quality updates.
If you disable or do not configure this policy, Windows Update will include updates that have a Driver classification.
### Configure Automatic Updates
Enables the IT admin to manage automatic update behavior to scan, download, and install updates.
#### Configuring Automatic Updates by using Group Policy
Under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Configure Automatic Updates**, you must select one of the four options:
**2 - Notify for download and auto install** - When Windows finds updates that apply to this device, users will be notified that updates are ready to be downloaded. After going to **Settings > Update & security > Windows Update**, users can download and install any available updates.
**3 - Auto download and notify for Install** - Windows finds updates that apply to the device and downloads them in the background (the user is not notified or interrupted during this process). When the downloads are complete, users will be notified that they are ready to install. After going to **Settings > Update & security > Windows Update**, users can install them.
**4 - Auto download and schedule the install** - Specify the schedule using the options in the Group Policy Setting. For more information about this setting, see [Schedule update installation](waas-restart.md#schedule-update-installation).
**5 - Allow local admin to choose setting** - With this option, local administrators will be allowed to use the settings app to select a configuration option of their choice. Local administrators will not be allowed to disable the configuration for Automatic Updates.
If this setting is set to *Disabled*, any updates that are available on Windows Update must be downloaded and installed manually. To do this, users must go to **Settings > Update & security > Windows Update**.
If this setting is set to *Not Configured*, an administrator can still configure Automatic Updates through the settings app, under **Settings > Update & security > Windows Update > Advanced options**.
#### Configuring Automatic Updates by editing the registry
> [!NOTE]
> Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require you to reinstall the operating system. Microsoft cannot guarantee that these problems can be resolved. Modify the registry at your own risk.
In an environment that does not have Active Directory deployed, you can edit registry settings to configure group policies for Automatic Update.
To do this, follow these steps:
1. Select **Start**, search for "regedit", and then open Registry Editor.
2. Open the following registry key:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
```
3. Add one of the following registry values to configure Automatic Update.
* NoAutoUpdate (REG_DWORD):
* **0**: Automatic Updates is enabled (default).
* **1**: Automatic Updates is disabled.
* AUOptions (REG_DWORD):
* **1**: Keep my computer up to date is disabled in Automatic Updates.
* **2**: Notify of download and installation.
* **3**: Automatically download and notify of installation.
* **4**: Automatically download and scheduled installation.
* ScheduledInstallDay (REG_DWORD):
* **0**: Every day.
* **1** through **7**: The days of the week from Sunday (1) to Saturday (7).
* ScheduledInstallTime (REG_DWORD):
**n**, where **n** equals the time of day in a 24-hour format (0-23).
* UseWUServer (REG_DWORD)
Set this value to **1** to configure Automatic Updates to use a server that is running Software Update Services instead of Windows Update.
* RescheduleWaitTime (REG_DWORD)
**m**, where **m** equals the time period to wait between the time Automatic Updates starts and the time that it begins installations where the scheduled times have passed. The time is set in minutes from 1 to 60, representing 1 minute to 60 minutes)
> [!NOTE]
> This setting only affects client behavior after the clients have updated to the SUS SP1 client version or later versions.
* NoAutoRebootWithLoggedOnUsers (REG_DWORD):
**0** (false) or **1** (true). If set to **1**, Automatic Updates does not automatically restart a computer while users are logged on.
> [!NOTE]
> This setting affects client behavior after the clients have updated to the SUS SP1 client version or later versions.
To use Automatic Updates with a server that is running Software Update Services, see the Deploying Microsoft Windows Server Update Services 2.0 guidance.
When you configure Automatic Updates directly by using the policy registry keys, the policy overrides the preferences that are set by the local administrative user to configure the client. If an administrator removes the registry keys at a later date, the preferences that were set by the local administrative user are used again.
To determine the WSUS server that the client computers and servers connect to for updates, add the following registry values to the registry:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\
```
* WUServer (REG_SZ)
This value sets the WSUS server by HTTP name (for example, http://IntranetSUS).
* WUStatusServer (REG_SZ)
This value sets the SUS statistics server by HTTP name (for example, http://IntranetSUS).
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Manage updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Manage device restarts after updates](waas-restart.md)
---
title: Manage additional Windows Update settings (Windows 10)
description: Additional settings to control the behavior of Windows Update (WU) in Windows 10
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.audience: itpro
author: greg-lindsay
ms.date: 07/27/2017
ms.reviewer:
manager: laurawi
ms.topic: article
---
# Manage additional Windows Update settings
**Applies to**
- Windows 10
- Windows 10 Mobile
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
You can use Group Policy settings or mobile device management (MDM) to configure the behavior of Windows Update (WU) on your Windows 10 devices. You can configure the update detection frequency, select when updates are received, specify the update service location and more.
>[!IMPORTANT]
>In Windows 10, any Group Policy user configuration settings for Windows Update were deprecated and are no longer supported on this platform.
## Summary of Windows Update settings
| Group Policy setting | MDM setting | Supported from version |
| --- | --- | --- |
| [Specify Intranet Microsoft update service location](#specify-intranet-microsoft-update-service-location) | [UpdateServiceUrl](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurl) and [UpdateServiceUrlAlternate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurlalternate) | All |
| [Automatic Updates Detection Frequency](#automatic-updates-detection-frequency) | [DetectionFrequency](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-detectionfrequency) | 1703 |
| [Remove access to use all Windows Update features](#remove-access-to-use-all-windows-update-features) | | All |
| [Do not connect to any Windows Update Internet locations](#do-not-connect-to-any-windows-update-internet-locations) | | All |
| [Enable client-side targeting](#enable-client-side-targeting) | | All |
| [Allow signed updates from an intranet Microsoft update service location](#allow-signed-updates-from-an-intranet-microsoft-update-service-location) | [AllowNonMicrosoftSignedUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-allownonmicrosoftsignedupdate) | All |
| [Do not include drivers with Windows Updates](#do-not-include-drivers-with-windows-updates) | [ExcludeWUDriversInQualityUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-excludewudriversinqualityupdate) | 1607 |
| [Configure Automatic Updates](#configure-automatic-updates) | [AllowAutoUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-allowautoupdate) | All |
>[!IMPORTANT]
>Additional information about settings to manage device restarts and restart notifications for updates is available on **[Manage device restarts after updates](waas-restart.md)**.
>
>Additional settings that configure when Feature and Quality updates are received are detailed on **[Configure Windows Update for Business](waas-configure-wufb.md)**.
## Scanning for updates
With Windows 10, admins have a lot of flexibility in configuring how their devices scan and receive updates.
[Specify Intranet Microsoft update service location](#specify-intranet-microsoft-update-service-location) allows admins to point devices to an internal Microsoft update service location, while [Do not connect to any Windows Update Internet locations](#do-not-connect-to-any-windows-update-internet-locations) gives them to option to restrict devices to just that internal update service. [Automatic Updates Detection Frequency](#automatic-updates-detection-frequency) controls how frequently devices scan for updates.
You can make custom device groups that'll work with your internal Microsoft update service by using [Enable client-side targeting](#enable-client-side-targeting). You can also make sure your devices receive updates that were not signed by Microsoft from your internal Microsoft update service, through [Allow signed updates from an intranet Microsoft update service location](#allow-signed-updates-from-an-intranet-microsoft-update-service-location).
Finally, to make sure the updating experience is fully controlled by the admins, you can [Remove access to use all Windows Update features](#remove-access-to-use-all-windows-update-features) for users.
For additional settings that configure when Feature and Quality updates are received, see [Configure Windows Update for Business](waas-configure-wufb.md).
### Specify Intranet Microsoft update service location
Specifies an intranet server to host updates from Microsoft Update. You can then use this update service to automatically update computers on your network.
This setting lets you specify a server on your network to function as an internal update service. The Automatic Updates client will search this service for updates that apply to the computers on your network.
To use this setting in Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update\Specify Intranet Microsoft update service location**. You must set two server name values: the server from which the Automatic Updates client detects and downloads updates, and the server to which updated workstations upload statistics. You can set both values to be the same server. An optional server name value can be specified to configure Windows Update Agent to download updates from an alternate download server instead of the intranet update service.
If the setting is set to **Enabled**, the Automatic Updates client connects to the specified intranet Microsoft update service (or alternate download server), instead of Windows Update, to search for and download updates. Enabling this setting means that end users in your organization don’t have to go through a firewall to get updates, and it gives you the opportunity to test updates after deploying them.
If the setting is set to **Disabled** or **Not Configured**, and if Automatic Updates is not disabled by policy or user preference, the Automatic Updates client connects directly to the Windows Update site on the Internet.
The alternate download server configures the Windows Update Agent to download files from an alternative download server instead of the intranet update service.
The option to download files with missing Urls allows content to be downloaded from the Alternate Download Server when there are no download Urls for files in the update metadata. This option should only be used when the intranet update service does not provide download Urls in the update metadata for files which are present on the alternate download server.
>[!NOTE]
>If the "Configure Automatic Updates" policy is disabled, then this policy has no effect.
>
>If the "Alternate Download Server" is not set, it will use the intranet update service by default to download updates.
>
>The option to "Download files with no Url..." is only used if the "Alternate Download Server" is set.
To configure this policy with MDM, use [UpdateServiceUrl](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurl) and [UpdateServiceUrlAlternate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-updateserviceurlalternate).
### Automatic Updates detection frequency
Specifies the hours that Windows will use to determine how long to wait before checking for available updates. The exact wait time is determined by using the hours specified here minus zero to twenty percent of the hours specified. For example, if this policy is used to specify a 20-hour detection frequency, then all clients to which this policy is applied will check for updates anywhere between 16 to 20 hours.
To set this setting with Group Policy, navigate to **Computer Configuration\Administrative Templates\Windows Components\Windows Update\Automatic Updates detection frequency**.
If the setting is set to **Enabled**, Windows will check for available updates at the specified interval.
If the setting is set to **Disabled** or **Not Configured**, Windows will check for available updates at the default interval of 22 hours.
>[!NOTE]
>The “Specify intranet Microsoft update service location” setting must be enabled for this policy to have effect.
>
>If the “Configure Automatic Updates” policy is disabled, this policy has no effect.
To configure this policy with MDM, use [DetectionFrequency](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-detectionfrequency).
### Remove access to use all Windows Update features
By enabling the Group Policy setting under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Remove access to use all Windows update features**, administrators can disable the "Check for updates" option for users. Any background update scans, downloads and installations will continue to work as configured.
### Do not connect to any Windows Update Internet locations
Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update or the Microsoft Store.
Use **Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not connect to any Windows Update Internet locations** to enable this policy. When enabled, this policy will disable the functionality described above, and may cause connection to public services such as the Microsoft Store, Windows Update for Business and Delivery Optimization to stop working.
>[!NOTE]
>This policy applies only when the device is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy.
### Enable client-side targeting
Specifies the target group name or names that should be used to receive updates from an intranet Microsoft update service. This allows admins to configure device groups that will receive different updates from sources like WSUS or SCCM.
This Group Policy setting can be found under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Enable client-side targeting**.
If the setting is set to **Enabled**, the specified target group information is sent to the intranet Microsoft update service which uses it to determine which updates should be deployed to this computer.
If the setting is set to **Disabled** or **Not Configured**, no target group information will be sent to the intranet Microsoft update service.
If the intranet Microsoft update service supports multiple target groups, this policy can specify multiple group names separated by semicolons. Otherwise, a single group must be specified.
>[!NOTE]
>This policy applies only when the intranet Microsoft update service the device is directed to is configured to support client-side targeting. If the “Specify intranet Microsoft update service location” policy is disabled or not configured, this policy has no effect.
### Allow signed updates from an intranet Microsoft update service location
This policy setting allows you to manage whether Automatic Updates accepts updates signed by entities other than Microsoft when the update is found on an intranet Microsoft update service location.
To configure this setting in Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows update\Allow signed updates from an intranet Microsoft update service location**.
If you enable this policy setting, Automatic Updates accepts updates received through an intranet Microsoft update service location, as specified by [Specify Intranet Microsoft update service location](#specify-intranet-microsoft-update-service-location), if they are signed by a certificate found in the “Trusted Publishers” certificate store of the local computer.
If you disable or do not configure this policy setting, updates from an intranet Microsoft update service location must be signed by Microsoft.
>[!NOTE]
>Updates from a service other than an intranet Microsoft update service must always be signed by Microsoft and are not affected by this policy setting.
To configure this policy with MDM, use [AllowNonMicrosoftSignedUpdate](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#update-allownonmicrosoftsignedupdate).
## Installing updates
To add more flexibility to the update process, settings are available to control update installation.
[Configure Automatic Updates](#configure-automatic-updates) offers 4 different options for automatic update installation, while [Do not include drivers with Windows Updates](#do-not-include-drivers-with-windows-updates) makes sure drivers are not installed with the rest of the received updates.
### Do not include drivers with Windows Updates
Allows admins to exclude Windows Update (WU) drivers during updates.
To configure this setting in Group Policy, use **Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not include drivers with Windows Updates**.
Enable this policy to not include drivers with Windows quality updates.
If you disable or do not configure this policy, Windows Update will include updates that have a Driver classification.
### Configure Automatic Updates
Enables the IT admin to manage automatic update behavior to scan, download, and install updates.
#### Configuring Automatic Updates by using Group Policy
Under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Configure Automatic Updates**, you must select one of the four options:
**2 - Notify for download and auto install** - When Windows finds updates that apply to this device, users will be notified that updates are ready to be downloaded. After going to **Settings > Update & security > Windows Update**, users can download and install any available updates.
**3 - Auto download and notify for Install** - Windows finds updates that apply to the device and downloads them in the background (the user is not notified or interrupted during this process). When the downloads are complete, users will be notified that they are ready to install. After going to **Settings > Update & security > Windows Update**, users can install them.
**4 - Auto download and schedule the install** - Specify the schedule using the options in the Group Policy Setting. For more information about this setting, see [Schedule update installation](waas-restart.md#schedule-update-installation).
**5 - Allow local admin to choose setting** - With this option, local administrators will be allowed to use the settings app to select a configuration option of their choice. Local administrators will not be allowed to disable the configuration for Automatic Updates.
If this setting is set to *Disabled*, any updates that are available on Windows Update must be downloaded and installed manually. To do this, users must go to **Settings > Update & security > Windows Update**.
If this setting is set to *Not Configured*, an administrator can still configure Automatic Updates through the settings app, under **Settings > Update & security > Windows Update > Advanced options**.
#### Configuring Automatic Updates by editing the registry
> [!NOTE]
> Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require you to reinstall the operating system. Microsoft cannot guarantee that these problems can be resolved. Modify the registry at your own risk.
In an environment that does not have Active Directory deployed, you can edit registry settings to configure group policies for Automatic Update.
To do this, follow these steps:
1. Select **Start**, search for "regedit", and then open Registry Editor.
2. Open the following registry key:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
```
3. Add one of the following registry values to configure Automatic Update.
* NoAutoUpdate (REG_DWORD):
* **0**: Automatic Updates is enabled (default).
* **1**: Automatic Updates is disabled.
* AUOptions (REG_DWORD):
* **1**: Keep my computer up to date is disabled in Automatic Updates.
* **2**: Notify of download and installation.
* **3**: Automatically download and notify of installation.
* **4**: Automatically download and scheduled installation.
* ScheduledInstallDay (REG_DWORD):
* **0**: Every day.
* **1** through **7**: The days of the week from Sunday (1) to Saturday (7).
* ScheduledInstallTime (REG_DWORD):
**n**, where **n** equals the time of day in a 24-hour format (0-23).
* UseWUServer (REG_DWORD)
Set this value to **1** to configure Automatic Updates to use a server that is running Software Update Services instead of Windows Update.
* RescheduleWaitTime (REG_DWORD)
**m**, where **m** equals the time period to wait between the time Automatic Updates starts and the time that it begins installations where the scheduled times have passed. The time is set in minutes from 1 to 60, representing 1 minute to 60 minutes)
> [!NOTE]
> This setting only affects client behavior after the clients have updated to the SUS SP1 client version or later versions.
* NoAutoRebootWithLoggedOnUsers (REG_DWORD):
**0** (false) or **1** (true). If set to **1**, Automatic Updates does not automatically restart a computer while users are logged on.
> [!NOTE]
> This setting affects client behavior after the clients have updated to the SUS SP1 client version or later versions.
To use Automatic Updates with a server that is running Software Update Services, see the Deploying Microsoft Windows Server Update Services 2.0 guidance.
When you configure Automatic Updates directly by using the policy registry keys, the policy overrides the preferences that are set by the local administrative user to configure the client. If an administrator removes the registry keys at a later date, the preferences that were set by the local administrative user are used again.
To determine the WSUS server that the client computers and servers connect to for updates, add the following registry values to the registry:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\
```
* WUServer (REG_SZ)
This value sets the WSUS server by HTTP name (for example, http://IntranetSUS).
* WUStatusServer (REG_SZ)
This value sets the SUS statistics server by HTTP name (for example, http://IntranetSUS).
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Manage updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Manage device restarts after updates](waas-restart.md)

2
windows/deployment/update/windows-analytics-get-started.md
View File

@ -78,7 +78,7 @@ To enable data sharing, configure your proxy server to whitelist the following e
>[!NOTE]
>Microsoft has a strong commitment to providing the tools and resources that put you in control of your privacy. As a result, Microsoft doesn't collect the following data from devices located in European countries (EEA and Switzerland):
>- Windows diagnostic data from Windows 8.1 devices
>- App usage data for Windows 7 devices
>- App usage data and [Internet Explorer site discovery](../upgrade/upgrade-readiness-additional-insights#site-discovery) features for Windows 7 devices

1049
windows/deployment/upgrade/setupdiag.md
View File

File diff suppressed because it is too large Load Diff

381
windows/deployment/upgrade/upgrade-readiness-deployment-script.md
View File

@ -1,190 +1,191 @@
---
title: Upgrade Readiness deployment script (Windows 10)
ms.reviewer:
manager: laurawi
ms.author: greglin
description: Deployment script for Upgrade Readiness.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro author: greg-lindsay
ms.topic: article
ms.collection: M365-analytics
---
# Upgrade Readiness deployment script
To automate the steps provided in [Get started with Upgrade Readiness](upgrade-readiness-get-started.md), and to troubleshoot data sharing issues, you can run the [Upgrade Readiness deployment script](https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409), developed by Microsoft.
>[!IMPORTANT]
>Upgrade Readiness was previously called Upgrade Analytics. References to Upgrade Analytics in any scripts or online content pertain to the Upgrade Readiness solution.
>[!IMPORTANT]
>The latest version of the Upgrade Readiness Script is **2.4.4 - 10.10.2018**
For detailed information about using the Upgrade Readiness (also known as upgrade analytics) deployment script, see the [Upgrade Analytics blog](https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/New-version-of-the-Upgrade-Analytics-Deployment-Script-available/ba-p/187164?advanced=false&collapse_discussion=true&q=new%20version%20of%20the%20upgrade%20analytics%20deployment%20script%20available&search_type=thread).
> The following guidance applies to version **2.4.4 - 10.10.2018** of the Upgrade Readiness deployment script. If you are using an older version, download the latest from the [Download Center](https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409).
The Upgrade Readiness deployment script does the following:
1. Sets commercial ID key + CommercialDataOptIn + RequestAllAppraiserVersions keys.
2. Verifies that user computers can send data to Microsoft.
3. Checks whether the computer has a pending restart.  
4. Verifies that the latest version of KB package 10.0.x is installed (version 10.0.14348 or later is required, but version 10.0.14913 or later is recommended).
5. If enabled, turns on verbose mode for troubleshooting.
6. Initiates the collection of the diagnostic data that Microsoft needs to assess your organization’s upgrade readiness.
7. If enabled, displays the script’s progress in a cmd window, providing you immediate visibility into issues (success or fail for each step) and/or writes to log file.
## Running the script
>There should be no performance impact caused by the script. The script is a light wrapper of Windows in-box components that undergo performance testing and optimization to avoid any performance impact. However, typically the script is scheduled to be run outside of working hours.
>
>Do not run the script at each sign-on. It is recommended to run the script once every 30 days.
>
>The length of time the script takes to run on each system depends on the number of apps and drivers, and the type of hardware. Anti-virus software scanning simultaneously can increase the script run time, but the script should require no longer than 10 minutes to run, and typically the time is much shorter. If the script is observed running for an extended period of time, please run the Pilot script, and collect logs to share with Microsoft. Log files are created in the drive that is specified in the RunConfig.bat file. By default this is set to: **%SystemDrive%\UADiagnostics**.
To run the Upgrade Readiness deployment script:
1. Download the [Upgrade Readiness deployment script](https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409) and extract the .zip file. Inside, there are two folders: **Pilot** and **Deployment**. The **Pilot** folder contains advanced logging that can help troubleshoot issues and is intended to be run from an elevated command prompt. The **Deployment** folder offers a lightweight script intended for broad deployment through ConfigMgr or other software deployment system. We recommend manually running the Pilot version of the script on 5-10 machines to verify that everything is configured correctly. Once you have confirmed that data is flowing successfully, proceed to run the Deployment version throughout your organization.
2. Edit the following parameters in RunConfig.bat:
1. Provide a storage location for log information. You can store log information on a remote file share or a local directory. If the script is blocked from creating the log file for the given path, it creates the log files in the drive with the Windows directory. Example: %SystemDrive%\\UADiagnostics
2. Input your commercial ID key. To find your commercial ID, first navigate to the **Solutions** tab for your workspace, and then select the solution. From there, select the **Settings** page, where you can find and copy your commercial ID:
3. By default, the script sends log information to both the console and the log file. To change the default behavior, use one of the following options:
> *logMode = 0 log to console only*
>
> *logMode = 1 log to file and console*
>
> *logMode = 2 log to file only*
3. To enable Internet Explorer data collection, set AllowIEData to IEDataOptIn. By default, AllowIEData is set to Disable. Then use one of the following options to determine what Internet Explorer data can be collected:
> *IEOptInLevel = 0 Internet Explorer data collection is disabled*
>
> *IEOptInLevel = 1 Data collection is enabled for sites in the Local intranet + Trusted sites + Machine local zones*
>
> *IEOptInLevel = 2 Data collection is enabled for sites in the Internet + Restricted sites zones*
>
> *IEOptInLevel = 3 Data collection is enabled for all sites*
4. The deployment script is configured to collect and send diagnostic and debugging data to Microsoft. If you wish to disable sending diagnostic and debugging data to Microsoft, set **AppInsightsOptIn = false**. By default, **AppInsightsOptIn** is set to **true**.
The data that is sent is the same data that is collected in the text log file that captures the events and error codes while running the script. This file is named in the following format: **UA_yyyy_mm_dd_hh_mm_ss_machineID.txt**. Log files are created in the drive that is specified in the RunConfig.bat file. By default this is set to: **%SystemDrive%\UADiagnostics**.
This data gives us the ability to determine the status of your machines and to help troubleshoot issues. If you choose to opt-in to and send this data to Microsoft, you must also allow https traffic to be sent to the following wildcard endpoints:
\*vortex\*.data.microsoft.com<BR>
\*settings\*.data.microsoft.com
5. The deployment script configures insider builds to continue to send the device name to the diagnostic data management service and the analytics portal. If you do not want to have insider builds send the device name sent to analytics and be available in the analytics portal, set **DeviceNAmeOptIn = false**. By default it is true, which preserves the behavior on previous versions of Windows. This setting only applies to insider builds. Note that the device name is also sent to AppInsights, so to ensure the device name is not sent to either place you would need to also set **AppInsightsOptIn = false**.
6. After you finish editing the parameters in RunConfig.bat, you are ready to run the script. If you are using the Pilot version, run RunConfig.bat from an elevated command prompt. If you are using the Deployment version, use ConfigMgr or other software deployment service to run RunConfig.bat as system.
## Exit codes
The deployment script displays the following exit codes to let you know if it was successful, or if an error was encountered.
| Exit code | Suggested fix |
|-----------|--------------|
| 0 - Success | N/A |
| 1 - Unexpected error occurred while executing the script. | The files in the deployment script are likely corrupted. Download the [latest script](https://go.microsoft.com/fwlink/?LinkID=822966) from the download center and try again. |
| 2 - Error when logging to console. $logMode = 0. (console only) | Try changing the $logMode value to **1** and try again. $logMode value 1 logs to both console and file. |
| 3 - Error when logging to console and file. $logMode = 1. | Verify that you have set the logPath parameter in RunConfig.bat, and that the configuration script has access to connect and write to this location. |
| 4 - Error when logging to file. $logMode = 2. | Verify that you have set the logPath parameter in RunConfig.bat, and that the configuration script has access to connect and write to this location. |
| 5 - Error when logging to console and file. $logMode = unknown. | Verify that you have set the logPath parameter in RunConfig.bat, and that the configuration script has access to connect and write to this location. |
| 6 - The commercialID parameter is set to unknown. | Modify the runConfig.bat file to set the CommercialID value. The value for parameter in the runconfig.bat file should match the Commercial ID key for your workspace. See [Generate your Commercial ID key](https://technet.microsoft.com/itpro/windows/deploy/upgrade-readiness-get-started#generate-your-commercial-id-key) for instructions on generating a Commercial ID key for your workspace. |
| 8 - Failure to create registry key path: **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection**. The Commercial Id property is set at the following registry key path: **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the context under which the script in running has access to the registry key. |
| 9 - The script failed to write Commercial Id to registry.
Error creating or updating registry key: **CommercialId** at **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the context under which the script in running has access to the registry key. |
| 10 - Error when writing **CommercialDataOptIn** to the registry at **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the deployment script is running in a context that has access to the registry key. |
| 11 - Function **SetupCommercialId** failed with an unexpected exception. The **SetupCommercialId** function updates the Commercial Id at the registry key path: **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the configuration script has access to this location. |
| 12 - Can’t connect to Microsoft - Vortex. Check your network/proxy settings. | **Http Get** on the end points did not return a success exit code. For Windows 10, connectivity is verified by connecting to https://v10.vortex-win.data.microsoft.com/health/keepalive. For previous operating systems, connectivity is verified by connecting to https://vortex-win.data.microsoft.com/health/keepalive. If there is an error verifying connectivity, this will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](../update/windows-analytics-get-started.md) |
| 13 - Can’t connect to Microsoft - setting. | An error occurred connecting to https://settings.data.microsoft.com/qos. This error will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](https://technet.microsoft.com/itpro/windows/deploy/upgrade-readiness-get-started#enable-data-sharing). Verify that the required endpoints are whitelisted correctly. See Whitelist select endpoints for more details. |
| 14 - Can’t connect to Microsoft - compatexchange. An error occurred connecting to [CompatibilityExchangeService.svc](https://compatexchange1.trafficmanager.net/CompatibilityExchangeService.svc). | This error will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](../update/windows-analytics-get-started.md). |
| 15 - Function CheckVortexConnectivity failed with an unexpected exception. | This error will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](../update/windows-analytics-get-started.md). Check the logs for the exception message and the HResult. |
| 16 - The computer requires a reboot before running the script. | Restart the device to complete the installation of the compatibility update and related updates. Reboot the computer before running the Upgrade Readiness deployment script. |
| 17 - Function **CheckRebootRequired** failed with an unexpected exception. | Restart the device to complete installation of the compatibility update and related updates. Check the logs for the exception message and the HResult. |
|18 - Appraiser KBs not installed or **appraiser.dll** not found. | Either the Appraiser-related updates are not installed, or the **appraiser.dll** file was not found. For more information, see appraiser diagnostic data events and fields information in the [Data collection](https://technet.microsoft.com/itpro/windows/deploy/upgrade-readiness-get-started#data-collection-and-privacy) and privacy topic. |
| 19 - Function **CheckAppraiserKB**, which checks the compatibility update KBs, failed with unexpected exception. | Check the logs for the Exception message and HResult. The script will not run further if this error is not fixed. |
| 20 - An error occurred when creating or updating the registry key **RequestAllAppraiserVersions** at **HKLM:\SOFTWARE\Microsoft\WindowsNT \CurrentVersion\AppCompatFlags\Appraiser** | The registry key is required for data collection to work correctly. Verify that the script is running in a context that has access to the registry key. |
| 21 - Function **SetRequestAllAppraiserVersions** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 22 - **RunAppraiser** failed with unexpected exception. | Check the logs for the exception message and HResult. Check the **%windir%\System32** directory for the file **CompatTelRunner.exe**. If the file does not exist, reinstall the required compatibility updates which include this file, and check your organization's Group Policy to verify it does not remove this file. |
| 23 - Error finding system variable **%WINDIR%**. | Verify that this environment variable is configured on the computer. |
| 24 - The script failed when writing **IEDataOptIn** to the registry. An error occurred when creating registry key **IEOptInLevel** at **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | This is a required registry key for IE data collection to work correctly. Verify that the deployment script in running in a context that has access to the registry key. Check the logs for the exception message and HResult. |
| 25 - The function **SetIEDataOptIn** failed with unexpected exception. | Check the logs for the exception message and HResult. |
| 27 - The script is not running under **System** account. | The Upgrade Readiness configuration script must be run as **System**. |
| 28 - Could not create log file at the specified **logPath**. | Make sure the deployment script has access to the location specified in the **logPath** parameter. |
| 29 - Connectivity check failed for proxy authentication. | Install cumulative updates on the device and enable the **DisableEnterpriseAuthProxy** authentication proxy setting. The **DisableEnterpriseAuthProxy** setting is enabled by default for Windows 7\. For Windows 8.1 computers, set the **DisableEnterpriseAuthProxy** setting to **0** (not disabled). For more information on authentication proxy support, see [Authentication proxy support added in new version (12.28.16) of the Upgrade Readiness deployment script](https://go.microsoft.com/fwlink/?linkid=838688). |
| 30 - Connectivity check failed. Registry key property **DisableEnterpriseAuthProxy** is not enabled. | The **DisableEnterpriseAuthProxy** setting is enabled by default for Windows 7\. For Windows 8.1 computers, set the **DisableEnterpriseAuthProxy** setting to **0** (not disabled). For more information on authentication proxy support, see [this blog post](https://go.microsoft.com/fwlink/?linkid=838688). |
| 31 - There is more than one instance of the Upgrade Readiness data collector running at the same time on this computer. Use Task Manager to check if **CompatTelRunner.exe** is running, and wait until it has completed to rerun the script. The Upgrade Readiness task is scheduled by default to run daily at 0300. |
| 32 - Appraiser version on the machine is outdated. | The configuration script detected a version of the compatibility update module that is older than the minimum required to correctly collect the data required by Upgrade Readiness solution. Use the latest version of the [compatibility update](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#deploy-the-compatibility-update-and-related-updates) for Windows 7 SP1/Windows 8.1. |
| 33 - **CompatTelRunner.exe** exited with an exit code | **CompatTelRunner.exe** runs the appraise task on the device. If it fails, it will provide a specific exit code. The script will return exit code 33 when **CompatTelRunner.exe** itself exits with an exit code. Check the logs for more details. Also see the **Note** following this table for additional steps to follow. |
| 34 - Function **CheckProxySettings** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 35 - Function **CheckAuthProxy** failed with an unexpected exception. Check the logs for the exception message and HResult. |
| 36 - Function **CheckAppraiserEndPointsConnectivity** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 37 - **Diagnose_internal.cmd** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 38 - Function **Get-SqmID** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 39 - For Windows 10: AllowTelemetry property is not set to 1 or higher at registry key path **HKLM:\SOFTWARE\Policies\Microsoft \Windows\DataCollection** or **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | For Windows 10 devices, the **AllowTelemetry** property should be set to 1 or greater to enable data collection. The script will return an error if this is not true. For more information, see [Configure Windows diagnostic data in your organization](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization). |
| 40 - Function **CheckTelemetryOptIn** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 41 - The script failed to impersonate the currently logged on user. | The script mimics the UTC client to collect upgrade readiness data. When auth proxy is set, the UTC client impersonates the user that is logged on. The script also tries to mimic this, but the process failed. |
| 42 - Function **StartImpersonatingLoggedOnUser** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 43 - Function **EndImpersonatingLoggedOnUser** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 44 - Diagtrack.dll version is old, so Auth Proxy will not work. | Update the device using Windows Update or Windows Server Update Services. |
| 45 - Diagtrack.dll was not found. | Update the device using Windows Update or Windows Server Update Services. |
| 48 - **CommercialID** mentioned in RunConfig.bat should be a GUID. | Copy the commercial ID from your workspace. To find your commercial ID, first navigate to the Solutions tab for your workspace in Azure Portal, and then select the solution. From there, select the **Settings** page, where you can find and copy your commercial ID.|
| 50 - Diagtrack Service is not running. | The Diagtrack service is required to send data to Microsoft. Enable and run the "Connected User Experiences and Telemetry" service. |
| 51 - RunCensus failed with an unexpected exception. | RunCensus explitly runs the process used to collect device information. The method failed with an unexpected exception. The most common cause is incorrect setup of diagnostic data. Check the ExceptionHResult and ExceptionMessage for more details. |
| 52 - DeviceCensus.exe not found on a Windows 10 machine. | On computers running Windows 10, the process devicecensus.exe should be present in the \system32 directory. Error code 52 is returned if the process was not found. Ensure that it exists at the specified location. |
| 53 - There is a different CommercialID present at the GPO path: **HKLM:\SOFTWARE\Policies\Microsoft \Windows\DataCollection**. This will take precedence over the CommercialID provided in the script. | Provide the correct CommercialID at the GPO location. |
| 54 - Microsoft Account Sign In Assistant Service is Disabled. | This service is required for devices running Windows 10. The diagnostic data client relies on the Microsoft Account Sign In Assistant (MSA) to get the Global Device ID for the device. Without the MSA service running, the global device ID will not be generated and sent by the client and Windows Update will no longer offer feature updates to devices running Windows 10 1709 or higher. See [Feature updates are not being offered while other updates are](https://docs.microsoft.com/windows/deployment/update/windows-update-troubleshooting#feature-updates-are-not-being-offered-while-other-updates-are). |
| 55 - SetDeviceNameOptIn function failed to create registry key path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** | The function SetDeviceNameOptIn sets the registry key value which determines whether to send the device name in diagnostic data. The function tries to create the registry key path if it does not already exist. Verify that the account has the correct permissions to change or add registry keys. |
| 56 - SetDeviceNameOptIn function failed to create property AllowDeviceNameInTelemetry at registry key path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** | Verify that the account has the correct permissions to change or add registry keys.|
| 57 - SetDeviceNameOptIn function failed to update AllowDeviceNameInTelemetry property to value 1 at registry key path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** | Verify that the account has the correct permissions to change or add registry keys. |
| 58 - SetDeviceNameOptIn function failed with unexpected exception | The function SetDeviceNameOptIn failed with an unexpected exception. |
| 59 - CleanupOneSettings failed to delete LastPersistedEventTimeOrFirstBoot property at registry key path: **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\Diagtrack** |The CleanupOneSettings function clears some of the cached values needed by the Appraiser which is the data collector on the monitored device. This helps in the download of the most recent for accurate running of the data collector. Verify that the account has the correct permissions to change or add registry keys. |
| 60 - CleanupOneSettings failed to delete registry key: **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\ Diagnostics\Diagtrack\SettingsRequests** | Verify that the account has the correct permissions to change or add registry keys. |
| 61 - CleanupOneSettings failed with an exception | CleanupOneSettings failed with an unexpected exception. |
| 62 - AllowTelemetry property value at registry key path **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** is not of type REG_DWORD. It should be of type REG_DWORD. | Ensure that the **AllowTelemetry** property at path **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** is a REG_DWORD. |
| 63 - Diagnostic data is disabled for the device | If AllowTelemetry equals **0**, devices cannot send diagnostic data. To resolve this, set the **AllowTelemetry** value at **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection**. |
| 64 - AllowTelemetry property value at registry key path **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection** is not of type REG_DWORD. It should be of type REG_DWORD. | Ensure that the **AllowTelemetry** property at **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection** is a REG_DWORD. |
| 65 - Diagnostic data is disabled for the device | If AllowTelemetry equals **0**, devices cannot send diagnostic data. To resolve this, set the **AllowTelemetry** value at **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection**. |
| 66 - All recent data uploads for the Universal Telemetry Client failed. | Review the UtcConnectionReport in WMI in the namespace **root\cimv2\mdm\dmmap** under the **MDM_Win32CompatibilityAppraiser_UniversalTelemetryClient01** class. Only SYSTEM has access to this class. Use [PSExec](https://docs.microsoft.com/sysinternals/downloads/psexec) to execute your WMI utility as SYSTEM. |
| 67 - CheckUtcCsp failed with an exception | There was an error reading the WIM/CIM class **MDM_Win32CompatibilityAppraiser_UniversalTelemetryClient01** in the namespace **root\cimv2\mdm\dmmap**. Review system for WMI errors. |
> [!NOTE]
> **Additional steps to follow if you receive exit code 33**
>
> Check the exit code for any of these messages:
>
> - CompatTelRunner.exe exited with last error code: 0x800703F1
> - CompatTelRunner.exe exited with last error code: 0x80070005
> - CompatTelRunner.exe exited with last error code: 0x80080005
> 
>
> If the exit code includes any of those messages, then run these commands from an elevated command prompt:
>
> 1. Net stop diagtrack
> 2. Net stop pcasvc
> 3. Net stop dps
> 4. Del %windir%\appcompat\programs\amcache.hve
> 5. reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v AmiHivePermissionsCorrect /f
> 6. reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v LogFlags /t REG_DWORD /d 4 /f
> 7. Net start diagtrack
> 8. Net start pcasvc
> 9. Net start dps
>
> Then run the Enterprise Config script (RunConfig.bat) again.
>
> If the script still fails, then send mail to <strong>uasupport@microsoft.com</strong> including log files from the RunConfig.bat script. These log files are stored on the drive that is specified in the RunConfig.bat file. By default this is set to **%SystemDrive%\UADiagnostics**. The log file is named with the format **UA_yyyy_mm_dd_hh_mm_ss_machineID.txt**. There will be some additional logs generated under your **\<system drive>\Windows\Temp** directory with the names similar to **AslLog_....txt**. You should send those logs as well.
---
title: Upgrade Readiness deployment script (Windows 10)
ms.reviewer:
manager: laurawi
ms.author: greglin
description: Deployment script for Upgrade Readiness.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.topic: article
ms.collection: M365-analytics
---
# Upgrade Readiness deployment script
To automate the steps provided in [Get started with Upgrade Readiness](upgrade-readiness-get-started.md), and to troubleshoot data sharing issues, you can run the [Upgrade Readiness deployment script](https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409), developed by Microsoft.
>[!IMPORTANT]
>Upgrade Readiness was previously called Upgrade Analytics. References to Upgrade Analytics in any scripts or online content pertain to the Upgrade Readiness solution.
>[!IMPORTANT]
>The latest version of the Upgrade Readiness Script is **2.4.4 - 10.10.2018**
For detailed information about using the Upgrade Readiness (also known as upgrade analytics) deployment script, see the [Upgrade Analytics blog](https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/New-version-of-the-Upgrade-Analytics-Deployment-Script-available/ba-p/187164?advanced=false&collapse_discussion=true&q=new%20version%20of%20the%20upgrade%20analytics%20deployment%20script%20available&search_type=thread).
> The following guidance applies to version **2.4.4 - 10.10.2018** of the Upgrade Readiness deployment script. If you are using an older version, download the latest from the [Download Center](https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409).
The Upgrade Readiness deployment script does the following:
1. Sets commercial ID key + CommercialDataOptIn + RequestAllAppraiserVersions keys.
2. Verifies that user computers can send data to Microsoft.
3. Checks whether the computer has a pending restart.  
4. Verifies that the latest version of KB package 10.0.x is installed (version 10.0.14348 or later is required, but version 10.0.14913 or later is recommended).
5. If enabled, turns on verbose mode for troubleshooting.
6. Initiates the collection of the diagnostic data that Microsoft needs to assess your organization’s upgrade readiness.
7. If enabled, displays the script’s progress in a cmd window, providing you immediate visibility into issues (success or fail for each step) and/or writes to log file.
## Running the script
>There should be no performance impact caused by the script. The script is a light wrapper of Windows in-box components that undergo performance testing and optimization to avoid any performance impact. However, typically the script is scheduled to be run outside of working hours.
>
>Do not run the script at each sign-on. It is recommended to run the script once every 30 days.
>
>The length of time the script takes to run on each system depends on the number of apps and drivers, and the type of hardware. Anti-virus software scanning simultaneously can increase the script run time, but the script should require no longer than 10 minutes to run, and typically the time is much shorter. If the script is observed running for an extended period of time, please run the Pilot script, and collect logs to share with Microsoft. Log files are created in the drive that is specified in the RunConfig.bat file. By default this is set to: **%SystemDrive%\UADiagnostics**.
To run the Upgrade Readiness deployment script:
1. Download the [Upgrade Readiness deployment script](https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409) and extract the .zip file. Inside, there are two folders: **Pilot** and **Deployment**. The **Pilot** folder contains advanced logging that can help troubleshoot issues and is intended to be run from an elevated command prompt. The **Deployment** folder offers a lightweight script intended for broad deployment through ConfigMgr or other software deployment system. We recommend manually running the Pilot version of the script on 5-10 machines to verify that everything is configured correctly. Once you have confirmed that data is flowing successfully, proceed to run the Deployment version throughout your organization.
2. Edit the following parameters in RunConfig.bat:
1. Provide a storage location for log information. You can store log information on a remote file share or a local directory. If the script is blocked from creating the log file for the given path, it creates the log files in the drive with the Windows directory. Example: %SystemDrive%\\UADiagnostics
2. Input your commercial ID key. To find your commercial ID, first navigate to the **Solutions** tab for your workspace, and then select the solution. From there, select the **Settings** page, where you can find and copy your commercial ID:
3. By default, the script sends log information to both the console and the log file. To change the default behavior, use one of the following options:
> *logMode = 0 log to console only*
>
> *logMode = 1 log to file and console*
>
> *logMode = 2 log to file only*
3. To enable Internet Explorer data collection, set AllowIEData to IEDataOptIn. By default, AllowIEData is set to Disable. Then use one of the following options to determine what Internet Explorer data can be collected:
> *IEOptInLevel = 0 Internet Explorer data collection is disabled*
>
> *IEOptInLevel = 1 Data collection is enabled for sites in the Local intranet + Trusted sites + Machine local zones*
>
> *IEOptInLevel = 2 Data collection is enabled for sites in the Internet + Restricted sites zones*
>
> *IEOptInLevel = 3 Data collection is enabled for all sites*
4. The deployment script is configured to collect and send diagnostic and debugging data to Microsoft. If you wish to disable sending diagnostic and debugging data to Microsoft, set **AppInsightsOptIn = false**. By default, **AppInsightsOptIn** is set to **true**.
The data that is sent is the same data that is collected in the text log file that captures the events and error codes while running the script. This file is named in the following format: **UA_yyyy_mm_dd_hh_mm_ss_machineID.txt**. Log files are created in the drive that is specified in the RunConfig.bat file. By default this is set to: **%SystemDrive%\UADiagnostics**.
This data gives us the ability to determine the status of your machines and to help troubleshoot issues. If you choose to opt-in to and send this data to Microsoft, you must also allow https traffic to be sent to the following wildcard endpoints:
\*vortex\*.data.microsoft.com<BR>
\*settings\*.data.microsoft.com
5. The deployment script configures insider builds to continue to send the device name to the diagnostic data management service and the analytics portal. If you do not want to have insider builds send the device name sent to analytics and be available in the analytics portal, set **DeviceNAmeOptIn = false**. By default it is true, which preserves the behavior on previous versions of Windows. This setting only applies to insider builds. Note that the device name is also sent to AppInsights, so to ensure the device name is not sent to either place you would need to also set **AppInsightsOptIn = false**.
6. After you finish editing the parameters in RunConfig.bat, you are ready to run the script. If you are using the Pilot version, run RunConfig.bat from an elevated command prompt. If you are using the Deployment version, use ConfigMgr or other software deployment service to run RunConfig.bat as system.
## Exit codes
The deployment script displays the following exit codes to let you know if it was successful, or if an error was encountered.
| Exit code | Suggested fix |
|-----------|--------------|
| 0 - Success | N/A |
| 1 - Unexpected error occurred while executing the script. | The files in the deployment script are likely corrupted. Download the [latest script](https://go.microsoft.com/fwlink/?LinkID=822966) from the download center and try again. |
| 2 - Error when logging to console. $logMode = 0. (console only) | Try changing the $logMode value to **1** and try again. $logMode value 1 logs to both console and file. |
| 3 - Error when logging to console and file. $logMode = 1. | Verify that you have set the logPath parameter in RunConfig.bat, and that the configuration script has access to connect and write to this location. |
| 4 - Error when logging to file. $logMode = 2. | Verify that you have set the logPath parameter in RunConfig.bat, and that the configuration script has access to connect and write to this location. |
| 5 - Error when logging to console and file. $logMode = unknown. | Verify that you have set the logPath parameter in RunConfig.bat, and that the configuration script has access to connect and write to this location. |
| 6 - The commercialID parameter is set to unknown. | Modify the runConfig.bat file to set the CommercialID value. The value for parameter in the runconfig.bat file should match the Commercial ID key for your workspace. See [Generate your Commercial ID key](https://technet.microsoft.com/itpro/windows/deploy/upgrade-readiness-get-started#generate-your-commercial-id-key) for instructions on generating a Commercial ID key for your workspace. |
| 8 - Failure to create registry key path: **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection**. The Commercial Id property is set at the following registry key path: **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the context under which the script in running has access to the registry key. |
| 9 - The script failed to write Commercial Id to registry.
Error creating or updating registry key: **CommercialId** at **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the context under which the script in running has access to the registry key. |
| 10 - Error when writing **CommercialDataOptIn** to the registry at **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the deployment script is running in a context that has access to the registry key. |
| 11 - Function **SetupCommercialId** failed with an unexpected exception. The **SetupCommercialId** function updates the Commercial Id at the registry key path: **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | Verify that the configuration script has access to this location. |
| 12 - Can’t connect to Microsoft - Vortex. Check your network/proxy settings. | **Http Get** on the end points did not return a success exit code. For Windows 10, connectivity is verified by connecting to https://v10.vortex-win.data.microsoft.com/health/keepalive. For previous operating systems, connectivity is verified by connecting to https://vortex-win.data.microsoft.com/health/keepalive. If there is an error verifying connectivity, this will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](../update/windows-analytics-get-started.md) |
| 13 - Can’t connect to Microsoft - setting. | An error occurred connecting to https://settings.data.microsoft.com/qos. This error will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](https://technet.microsoft.com/itpro/windows/deploy/upgrade-readiness-get-started#enable-data-sharing). Verify that the required endpoints are whitelisted correctly. See Whitelist select endpoints for more details. |
| 14 - Can’t connect to Microsoft - compatexchange. An error occurred connecting to [CompatibilityExchangeService.svc](https://compatexchange1.trafficmanager.net/CompatibilityExchangeService.svc). | This error will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](../update/windows-analytics-get-started.md). |
| 15 - Function CheckVortexConnectivity failed with an unexpected exception. | This error will prevent the collected data from being sent to Upgrade Readiness. To resolve this issue, verify that the required endpoints are correctly whitelisted. For more information, see [Enrolling devices in Windows Analytics](../update/windows-analytics-get-started.md). Check the logs for the exception message and the HResult. |
| 16 - The computer requires a reboot before running the script. | Restart the device to complete the installation of the compatibility update and related updates. Reboot the computer before running the Upgrade Readiness deployment script. |
| 17 - Function **CheckRebootRequired** failed with an unexpected exception. | Restart the device to complete installation of the compatibility update and related updates. Check the logs for the exception message and the HResult. |
|18 - Appraiser KBs not installed or **appraiser.dll** not found. | Either the Appraiser-related updates are not installed, or the **appraiser.dll** file was not found. For more information, see appraiser diagnostic data events and fields information in the [Data collection](https://technet.microsoft.com/itpro/windows/deploy/upgrade-readiness-get-started#data-collection-and-privacy) and privacy topic. |
| 19 - Function **CheckAppraiserKB**, which checks the compatibility update KBs, failed with unexpected exception. | Check the logs for the Exception message and HResult. The script will not run further if this error is not fixed. |
| 20 - An error occurred when creating or updating the registry key **RequestAllAppraiserVersions** at **HKLM:\SOFTWARE\Microsoft\WindowsNT \CurrentVersion\AppCompatFlags\Appraiser** | The registry key is required for data collection to work correctly. Verify that the script is running in a context that has access to the registry key. |
| 21 - Function **SetRequestAllAppraiserVersions** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 22 - **RunAppraiser** failed with unexpected exception. | Check the logs for the exception message and HResult. Check the **%windir%\System32** directory for the file **CompatTelRunner.exe**. If the file does not exist, reinstall the required compatibility updates which include this file, and check your organization's Group Policy to verify it does not remove this file. |
| 23 - Error finding system variable **%WINDIR%**. | Verify that this environment variable is configured on the computer. |
| 24 - The script failed when writing **IEDataOptIn** to the registry. An error occurred when creating registry key **IEOptInLevel** at **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | This is a required registry key for IE data collection to work correctly. Verify that the deployment script in running in a context that has access to the registry key. Check the logs for the exception message and HResult. |
| 25 - The function **SetIEDataOptIn** failed with unexpected exception. | Check the logs for the exception message and HResult. |
| 27 - The script is not running under **System** account. | The Upgrade Readiness configuration script must be run as **System**. |
| 28 - Could not create log file at the specified **logPath**. | Make sure the deployment script has access to the location specified in the **logPath** parameter. |
| 29 - Connectivity check failed for proxy authentication. | Install cumulative updates on the device and enable the **DisableEnterpriseAuthProxy** authentication proxy setting. The **DisableEnterpriseAuthProxy** setting is enabled by default for Windows 7\. For Windows 8.1 computers, set the **DisableEnterpriseAuthProxy** setting to **0** (not disabled). For more information on authentication proxy support, see [Authentication proxy support added in new version (12.28.16) of the Upgrade Readiness deployment script](https://go.microsoft.com/fwlink/?linkid=838688). |
| 30 - Connectivity check failed. Registry key property **DisableEnterpriseAuthProxy** is not enabled. | The **DisableEnterpriseAuthProxy** setting is enabled by default for Windows 7\. For Windows 8.1 computers, set the **DisableEnterpriseAuthProxy** setting to **0** (not disabled). For more information on authentication proxy support, see [this blog post](https://go.microsoft.com/fwlink/?linkid=838688). |
| 31 - There is more than one instance of the Upgrade Readiness data collector running at the same time on this computer. Use Task Manager to check if **CompatTelRunner.exe** is running, and wait until it has completed to rerun the script. The Upgrade Readiness task is scheduled by default to run daily at 0300. |
| 32 - Appraiser version on the machine is outdated. | The configuration script detected a version of the compatibility update module that is older than the minimum required to correctly collect the data required by Upgrade Readiness solution. Use the latest version of the [compatibility update](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#deploy-the-compatibility-update-and-related-updates) for Windows 7 SP1/Windows 8.1. |
| 33 - **CompatTelRunner.exe** exited with an exit code | **CompatTelRunner.exe** runs the appraise task on the device. If it fails, it will provide a specific exit code. The script will return exit code 33 when **CompatTelRunner.exe** itself exits with an exit code. Check the logs for more details. Also see the **Note** following this table for additional steps to follow. |
| 34 - Function **CheckProxySettings** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 35 - Function **CheckAuthProxy** failed with an unexpected exception. Check the logs for the exception message and HResult. |
| 36 - Function **CheckAppraiserEndPointsConnectivity** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 37 - **Diagnose_internal.cmd** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 38 - Function **Get-SqmID** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 39 - For Windows 10: AllowTelemetry property is not set to 1 or higher at registry key path **HKLM:\SOFTWARE\Policies\Microsoft \Windows\DataCollection** or **HKLM:\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\DataCollection** | For Windows 10 devices, the **AllowTelemetry** property should be set to 1 or greater to enable data collection. The script will return an error if this is not true. For more information, see [Configure Windows diagnostic data in your organization](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization). |
| 40 - Function **CheckTelemetryOptIn** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 41 - The script failed to impersonate the currently logged on user. | The script mimics the UTC client to collect upgrade readiness data. When auth proxy is set, the UTC client impersonates the user that is logged on. The script also tries to mimic this, but the process failed. |
| 42 - Function **StartImpersonatingLoggedOnUser** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 43 - Function **EndImpersonatingLoggedOnUser** failed with an unexpected exception. | Check the logs for the exception message and HResult. |
| 44 - Diagtrack.dll version is old, so Auth Proxy will not work. | Update the device using Windows Update or Windows Server Update Services. |
| 45 - Diagtrack.dll was not found. | Update the device using Windows Update or Windows Server Update Services. |
| 48 - **CommercialID** mentioned in RunConfig.bat should be a GUID. | Copy the commercial ID from your workspace. To find your commercial ID, first navigate to the Solutions tab for your workspace in Azure Portal, and then select the solution. From there, select the **Settings** page, where you can find and copy your commercial ID.|
| 50 - Diagtrack Service is not running. | The Diagtrack service is required to send data to Microsoft. Enable and run the "Connected User Experiences and Telemetry" service. |
| 51 - RunCensus failed with an unexpected exception. | RunCensus explitly runs the process used to collect device information. The method failed with an unexpected exception. The most common cause is incorrect setup of diagnostic data. Check the ExceptionHResult and ExceptionMessage for more details. |
| 52 - DeviceCensus.exe not found on a Windows 10 machine. | On computers running Windows 10, the process devicecensus.exe should be present in the \system32 directory. Error code 52 is returned if the process was not found. Ensure that it exists at the specified location. |
| 53 - There is a different CommercialID present at the GPO path: **HKLM:\SOFTWARE\Policies\Microsoft \Windows\DataCollection**. This will take precedence over the CommercialID provided in the script. | Provide the correct CommercialID at the GPO location. |
| 54 - Microsoft Account Sign In Assistant Service is Disabled. | This service is required for devices running Windows 10. The diagnostic data client relies on the Microsoft Account Sign In Assistant (MSA) to get the Global Device ID for the device. Without the MSA service running, the global device ID will not be generated and sent by the client and Windows Update will no longer offer feature updates to devices running Windows 10 1709 or higher. See [Feature updates are not being offered while other updates are](https://docs.microsoft.com/windows/deployment/update/windows-update-troubleshooting#feature-updates-are-not-being-offered-while-other-updates-are). |
| 55 - SetDeviceNameOptIn function failed to create registry key path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** | The function SetDeviceNameOptIn sets the registry key value which determines whether to send the device name in diagnostic data. The function tries to create the registry key path if it does not already exist. Verify that the account has the correct permissions to change or add registry keys. |
| 56 - SetDeviceNameOptIn function failed to create property AllowDeviceNameInTelemetry at registry key path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** | Verify that the account has the correct permissions to change or add registry keys.|
| 57 - SetDeviceNameOptIn function failed to update AllowDeviceNameInTelemetry property to value 1 at registry key path: **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** | Verify that the account has the correct permissions to change or add registry keys. |
| 58 - SetDeviceNameOptIn function failed with unexpected exception | The function SetDeviceNameOptIn failed with an unexpected exception. |
| 59 - CleanupOneSettings failed to delete LastPersistedEventTimeOrFirstBoot property at registry key path: **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\Diagtrack** |The CleanupOneSettings function clears some of the cached values needed by the Appraiser which is the data collector on the monitored device. This helps in the download of the most recent for accurate running of the data collector. Verify that the account has the correct permissions to change or add registry keys. |
| 60 - CleanupOneSettings failed to delete registry key: **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\ Diagnostics\Diagtrack\SettingsRequests** | Verify that the account has the correct permissions to change or add registry keys. |
| 61 - CleanupOneSettings failed with an exception | CleanupOneSettings failed with an unexpected exception. |
| 62 - AllowTelemetry property value at registry key path **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** is not of type REG_DWORD. It should be of type REG_DWORD. | Ensure that the **AllowTelemetry** property at path **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection** is a REG_DWORD. |
| 63 - Diagnostic data is disabled for the device | If AllowTelemetry equals **0**, devices cannot send diagnostic data. To resolve this, set the **AllowTelemetry** value at **HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection**. |
| 64 - AllowTelemetry property value at registry key path **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection** is not of type REG_DWORD. It should be of type REG_DWORD. | Ensure that the **AllowTelemetry** property at **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection** is a REG_DWORD. |
| 65 - Diagnostic data is disabled for the device | If AllowTelemetry equals **0**, devices cannot send diagnostic data. To resolve this, set the **AllowTelemetry** value at **HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection**. |
| 66 - All recent data uploads for the Universal Telemetry Client failed. | Review the UtcConnectionReport in WMI in the namespace **root\cimv2\mdm\dmmap** under the **MDM_Win32CompatibilityAppraiser_UniversalTelemetryClient01** class. Only SYSTEM has access to this class. Use [PSExec](https://docs.microsoft.com/sysinternals/downloads/psexec) to execute your WMI utility as SYSTEM. |
| 67 - CheckUtcCsp failed with an exception | There was an error reading the WIM/CIM class **MDM_Win32CompatibilityAppraiser_UniversalTelemetryClient01** in the namespace **root\cimv2\mdm\dmmap**. Review system for WMI errors. |
> [!NOTE]
> **Additional steps to follow if you receive exit code 33**
>
> Check the exit code for any of these messages:
>
> - CompatTelRunner.exe exited with last error code: 0x800703F1
> - CompatTelRunner.exe exited with last error code: 0x80070005
> - CompatTelRunner.exe exited with last error code: 0x80080005
> 
>
> If the exit code includes any of those messages, then run these commands from an elevated command prompt:
>
> 1. Net stop diagtrack
> 2. Net stop pcasvc
> 3. Net stop dps
> 4. Del %windir%\appcompat\programs\amcache.hve
> 5. reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v AmiHivePermissionsCorrect /f
> 6. reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v LogFlags /t REG_DWORD /d 4 /f
> 7. Net start diagtrack
> 8. Net start pcasvc
> 9. Net start dps
>
> Then run the Enterprise Config script (RunConfig.bat) again.
>
> If the script still fails, then contact support@microsoft.com and share the log files from the RunConfig.bat script. These log files are stored on the drive that is specified in the RunConfig.bat file. By default this is set to **%SystemDrive%\UADiagnostics**. The log file is named with the format **UA_yyyy_mm_dd_hh_mm_ss_machineID.txt**. There will be some additional logs generated under your **\<system drive>\Windows\Temp** directory with the names similar to **AslLog_....txt**. You should send those logs as well.

567
windows/deployment/upgrade/windows-10-upgrade-paths.md
View File

@ -1,283 +1,284 @@
---
title: Windows 10 upgrade paths (Windows 10)
ms.reviewer:
manager: laurawi
ms.author: greglin
description: You can upgrade to Windows 10 from a previous version of Windows if the upgrade path is supported.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.localizationpriority: medium
ms.pagetype: mobile
audience: itpro author: greg-lindsay
ms.topic: article
---
# Windows 10 upgrade paths
**Applies to**
- Windows 10
- Windows 10 Mobile
## Upgrade paths
This topic provides a summary of available upgrade paths to Windows 10. You can upgrade to Windows 10 from Windows 7 or a later operating system. This includes upgrading from one release of Windows 10 to later release of Windows 10. Migrating from one edition of Windows 10 to a different edition of the same release is also supported. For more information about migrating to a different edition of Windows 10, see [Windows 10 edition upgrade](windows-10-edition-upgrades.md).
> **Windows 10 version upgrade**: You can directly upgrade a supported version of Windows 10 to a newer version of Windows 10, even if it involves skipping versions. Work with your account representative if your current version of Windows is out of support. See the [Windows lifecycle fact sheet](https://support.microsoft.com/help/13853/windows-lifecycle-fact-sheet) for availability and service information.
>
> **Windows 10 LTSC/LTSB**: Due to [naming changes](https://docs.microsoft.com/windows/deployment/update/waas-overview#naming-changes), product versions that display Windows 10 LTSB will be replaced with Windows 10 LTSC in subsequent feature updates. The term LTSC is used here to refer to all long term servicing versions.
>
> In-place upgrade from Windows 7, Windows 8.1, or [Windows 10 semi-annual channel](https://docs.microsoft.com/windows/release-information/) to Windows 10 LTSC is not supported. **Note**: Windows 10 LTSC 2015 did not block this upgrade path. This was corrected in the Windows 10 LTSC 2016 release, which will now only allow data-only and clean install options. You can upgrade from Windows 10 LTSC to Windows 10 semi-annual channel, provided that you upgrade to the same or a newer build version. For example, Windows 10 Enterprise 2016 LTSB can be upgraded to Windows 10 Enterprise version 1607 or later. Upgrade is supported using the in-place upgrade process (using Windows setup).
>
> **Windows N/KN**: Windows "N" and "KN" SKUs (editions without media-related functionality) follow the same upgrade paths shown below. If the pre-upgrade and post-upgrade editions are not the same type (e.g. Windows 8.1 Pro N to Windows 10 Pro), personal data will be kept but applications and settings will be removed during the upgrade process.
>
> **Windows 8.0**: You cannot upgrade directly from Windows 8.0 to Windows 10. To upgrade from Windows 8.0, you must first install the [Windows 8.1 update](https://support.microsoft.com/help/15356/windows-8-install-update-kb-2919355).
✔ = Full upgrade is supported including personal data, settings, and applications.<BR>
D = Edition downgrade; personal data is maintained, applications and settings are removed.
<br>
<table border="0" cellpadding="1">
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td>
<td></td>
<td>Windows 10 Home</td>
<td>Windows 10 Pro</td>
<td>Windows 10 Pro Education</td>
<td>Windows 10 Education</td>
<td>Windows 10 Enterprise</td>
<td>Windows 10 Mobile</td>
<td>Windows 10 Mobile Enterprise</td>
</tr>
<tr>
<td rowspan="7" nowrap="nowrap">Windows 7</td>
</tr>
<tr>
<td>Starter</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Home Basic</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Home Premium</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Professional</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Ultimate</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise</td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td rowspan="10" nowrap="nowrap">Windows 8.1</td>
</tr>
<tr>
<td>(Core)</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Connected</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro Student</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro WMC</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise</td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Embedded Industry</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Windows RT</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Windows Phone 8.1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
</tr>
<tr>
<td rowspan="8" nowrap="nowrap">Windows 10</td>
</tr>
<tr>
<td>Home</td>
<td></td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro</td>
<td>D</td>
<td></td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Education</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>D</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise</td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Mobile</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
</tr>
<tr>
<td>Mobile Enterprise</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>D</td>
<td></td>
</tr>
</table>
## Related Topics
[Windows 10 deployment scenarios](../windows-10-deployment-scenarios.md)<br>
[Windows upgrade and migration considerations](windows-upgrade-and-migration-considerations.md)<br>
[Windows 10 edition upgrade](windows-10-edition-upgrades.md)
---
title: Windows 10 upgrade paths (Windows 10)
ms.reviewer:
manager: laurawi
ms.author: greglin
description: You can upgrade to Windows 10 from a previous version of Windows if the upgrade path is supported.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.localizationpriority: medium
ms.pagetype: mobile
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Windows 10 upgrade paths
**Applies to**
- Windows 10
- Windows 10 Mobile
## Upgrade paths
This topic provides a summary of available upgrade paths to Windows 10. You can upgrade to Windows 10 from Windows 7 or a later operating system. This includes upgrading from one release of Windows 10 to later release of Windows 10. Migrating from one edition of Windows 10 to a different edition of the same release is also supported. For more information about migrating to a different edition of Windows 10, see [Windows 10 edition upgrade](windows-10-edition-upgrades.md).
> **Windows 10 version upgrade**: You can directly upgrade a supported version of Windows 10 to a newer version of Windows 10, even if it involves skipping versions. Work with your account representative if your current version of Windows is out of support. See the [Windows lifecycle fact sheet](https://support.microsoft.com/help/13853/windows-lifecycle-fact-sheet) for availability and service information.
>
> **Windows 10 LTSC/LTSB**: Due to [naming changes](https://docs.microsoft.com/windows/deployment/update/waas-overview#naming-changes), product versions that display Windows 10 LTSB will be replaced with Windows 10 LTSC in subsequent feature updates. The term LTSC is used here to refer to all long term servicing versions.
>
> In-place upgrade from Windows 7, Windows 8.1, or [Windows 10 semi-annual channel](https://docs.microsoft.com/windows/release-information/) to Windows 10 LTSC is not supported. **Note**: Windows 10 LTSC 2015 did not block this upgrade path. This was corrected in the Windows 10 LTSC 2016 release, which will now only allow data-only and clean install options. You can upgrade from Windows 10 LTSC to Windows 10 semi-annual channel, provided that you upgrade to the same or a newer build version. For example, Windows 10 Enterprise 2016 LTSB can be upgraded to Windows 10 Enterprise version 1607 or later. Upgrade is supported using the in-place upgrade process (using Windows setup). You will need to use the Product Key switch if you want to keep your apps. If you don't use the switch the option 'Keep personal files and apps' will be grayed out. The command line would be **setup.exe /pkey xxxxx-xxxxx-xxxxx-xxxxx-xxxxx**, using your relevant Windows 10 SAC product key. For example, if using a KMS, the command line would be **setup.exe /pkey NPPR9-FWDCX-D2C8J-H872K-2YT43**.
>
> **Windows N/KN**: Windows "N" and "KN" SKUs (editions without media-related functionality) follow the same upgrade paths shown below. If the pre-upgrade and post-upgrade editions are not the same type (e.g. Windows 8.1 Pro N to Windows 10 Pro), personal data will be kept but applications and settings will be removed during the upgrade process.
>
> **Windows 8.0**: You cannot upgrade directly from Windows 8.0 to Windows 10. To upgrade from Windows 8.0, you must first install the [Windows 8.1 update](https://support.microsoft.com/help/15356/windows-8-install-update-kb-2919355).
✔ = Full upgrade is supported including personal data, settings, and applications.<BR>
D = Edition downgrade; personal data is maintained, applications and settings are removed.
<br>
<table border="0" cellpadding="1">
<tr>
<td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td>
<td></td>
<td>Windows 10 Home</td>
<td>Windows 10 Pro</td>
<td>Windows 10 Pro Education</td>
<td>Windows 10 Education</td>
<td>Windows 10 Enterprise</td>
<td>Windows 10 Mobile</td>
<td>Windows 10 Mobile Enterprise</td>
</tr>
<tr>
<td rowspan="7" nowrap="nowrap">Windows 7</td>
</tr>
<tr>
<td>Starter</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Home Basic</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Home Premium</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Professional</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Ultimate</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise</td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td rowspan="10" nowrap="nowrap">Windows 8.1</td>
</tr>
<tr>
<td>(Core)</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Connected</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro Student</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro WMC</td>
<td>D</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise</td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Embedded Industry</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Windows RT</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Windows Phone 8.1</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
</tr>
<tr>
<td rowspan="8" nowrap="nowrap">Windows 10</td>
</tr>
<tr>
<td>Home</td>
<td></td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Pro</td>
<td>D</td>
<td></td>
<td>✔</td>
<td>✔</td>
<td>✔</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Education</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>D</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Enterprise</td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>Mobile</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>✔</td>
</tr>
<tr>
<td>Mobile Enterprise</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>D</td>
<td></td>
</tr>
</table>
## Related Topics
[Windows 10 deployment scenarios](../windows-10-deployment-scenarios.md)<br>
[Windows upgrade and migration considerations](windows-upgrade-and-migration-considerations.md)<br>
[Windows 10 edition upgrade](windows-10-edition-upgrades.md)

537
windows/deployment/usmt/offline-migration-reference.md
View File

@ -1,268 +1,269 @@
---
title: Offline Migration Reference (Windows 10)
description: Offline Migration Reference
ms.assetid: f347547c-d601-4c3e-8f2d-0138edeacfda
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Offline Migration Reference
Offline migration enables the ScanState tool to run inside a different Windows® operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
- **Windows.old.** The ScanState tool can now gather files and settings from the Windows.old directory that is created during Windows installation on a partition that contains a previous installation of Windows. For example, the ScanState tool can run in Windows 10, gathering files from a previous Windows 7or Windows 8 installation contained in the Windows.old directory.
When you use User State Migration Tool (USMT) 10.0 to gather and restore user state, offline migration reduces the cost of deployment by:
- **Reducing complexity.** In computer-refresh scenarios, migrations from the Windows.old directory reduce complexity by eliminating the need for the ScanState tool to be run before the operating system is deployed. Also, migrations from the Windows.old directory enable ScanState and LoadState to be run successively.
- **Improving performance.** When USMT runs in an offline Windows Preinstallation Environment (WinPE) environment, it has better access to the hardware resources. This may increase performance on older machines with limited hardware resources and numerous installed software applications.
- **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the ScanState tool from within WinPE.
## In This Topic
- [What Will Migrate Offline?](#bkmk-whatwillmigrate)
- [What Offline Environments are Supported?](#bkmk-offlineenvironments)
- [User-Group Membership and Profile Control](#bkmk-usergroupmembership)
- [Command-Line Options](#bkmk-commandlineoptions)
- [Environment Variables](#bkmk-environmentvariables)
- [Offline.xml Elements](#bkmk-offlinexml)
## <a href="" id="bkmk-whatwillmigrate"></a>What Will Migrate Offline?
The following user data and settings migrate offline, similar to an online migration:
- Data and registry keys specified in MigXML
- User accounts
- Application settings
- Limited set of operating-system settings
- EFS files
- Internet Explorer® Favorites
For exceptions to what you can migrate offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
## <a href="" id="bkmk-offlineenvironments"></a>What Offline Environments are Supported?
The following table defines the supported combination of online and offline operating systems in USMT.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Running Operating System</th>
<th align="left">Offline Operating System</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>WinPE 5.0 or greater, with the MSXML library</p></td>
<td align="left"><p>Windows Vista, Windows 7, Windows 8, Windows 10</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows 7, Windows 8, Windows 10</p></td>
<td align="left"><p>Windows.old directory</p></td>
</tr>
</tbody>
</table>
**Note**  
It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](https://go.microsoft.com/fwlink/p/?LinkId=190314).
## <a href="" id="bkmk-usergroupmembership"></a>User-Group Membership and Profile Control
User-group membership is not preserved during offline migrations. You must configure a **&lt;ProfileControl&gt;** section in the Config.xml file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group:
``` syntax
<Configuration>
<ProfileControl>
<localGroups>
<mappings>
<changeGroup from="*" to="Users" appliesTo="MigratedUsers">
<include>
<pattern>*</pattern>
</include>
</changeGroup>
</mappings>
</localGroups>
</ProfileControl>
</Configuration>
```
For information about the format of a Config.xml file, see [Config.xml File](usmt-configxml-file.md).
## <a href="" id="bkmk-commandlineoptions"></a>Command-Line Options
An offline migration can either be enabled by using a configuration file on the command line, or by using one of the following command line options:
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Component</th>
<th align="left">Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/offline:</strong><em>&lt;path to offline.xml&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.</p></td>
</tr>
<tr class="even">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/offlineWinDir:</strong><em>&lt;Windows directory&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/OfflineWinOld:</strong><em>&lt;Windows.old directory&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.</p></td>
</tr>
</tbody>
</table>
You can use only one of the **/offline**,**/offlineWinDir** , or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together.
## <a href="" id="bkmk-environmentvariables"></a>Environment Variables
The following system environment variables are necessary in the scenarios outlined below.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Value</th>
<th align="left">Scenario</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>USMT_WORKING_DIR</p></td>
<td align="left"><p>Full path to a working directory</p></td>
<td align="left"><p>Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following:</p>
<pre class="syntax" space="preserve"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre></td>
</tr>
<tr class="even">
<td align="left"><p>MIG_OFFLINE_PLATFORM_ARCH</p></td>
<td align="left"><p>32 or 64</p></td>
<td align="left"><p>While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn’t function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following:</p>
<pre class="syntax" space="preserve"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-offlinexml"></a>Offline.xml Elements
Use an offline.xml file when running the ScanState tool on a computer that has multiple Windows directories. The offline.xml file specifies which directories to scan for windows files. An offline.xml file can be used with the /offline option as an alternative to specifying a single Windows directory path with the /offlineDir option.
### <a href="" id="-offline-"></a>&lt;offline&gt;
This element contains other elements that define how an offline migration is to be performed.
Syntax: &lt;offline&gt; &lt;/offline&gt;
### <a href="" id="-windir-"></a>&lt;winDir&gt;
This element is a required child of **&lt;offline&gt;** and contains information about how the offline volume can be selected. The migration will be performed from the first element of **&lt;winDir&gt;** that contains a valid Windows system volume.
Syntax: &lt; winDir &gt; &lt;/ winDir &gt;
### <a href="" id="-path-"></a>&lt;path&gt;
This element is a required child of **&lt;winDir&gt;** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool’s working directory.
Syntax: &lt;path&gt; c:\\windows &lt;/path&gt;
-or-
Syntax, when used with the **&lt;mappings&gt;** element: &lt;path&gt; C:\\, D:\\ &lt;/path&gt;
### <a href="" id="-mappings-"></a>&lt;mappings&gt;
This element is an optional child of **&lt;offline&gt;**. When specified, the **&lt;mappings&gt;** element will override the automatically detected WinPE drive mappings. Each child **&lt;path&gt;** element will provide a mapping from one system volume to another. Additionally, mappings between folders can be provided, since an entire volume can be mounted to a specific folder.
Syntax: &lt;mappings&gt; &lt;/mappings&gt;
### <a href="" id="-failonmultiplewindir-"></a>&lt;failOnMultipleWinDir&gt;
This element is an optional child of **&lt;offline&gt;**. The **&lt;failOnMultipleWinDir&gt;** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **&lt;failOnMultipleWinDir&gt;** element isn’t present, the default behavior is that the migration does not fail.
Syntax: &lt;failOnMultipleWinDir&gt;1&lt;/failOnMultipleWinDir&gt; or Syntax: &lt;failOnMultipleWinDir&gt;0&lt;/failOnMultipleWinDir&gt;
### Offline .xml Example
The following XML example illustrates some of the elements discussed earlier in this topic.
``` syntax
<offline>
<winDir>
<path>C:\Windows</path>
<path>D:\Windows</path>
<path>E:\</path>
</winDir>
<failOnMultipleWinDir>1</failOnMultipleWinDir>
</offline>
```
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)
---
title: Offline Migration Reference (Windows 10)
description: Offline Migration Reference
ms.assetid: f347547c-d601-4c3e-8f2d-0138edeacfda
ms.reviewer:
manager: laurawi
ms.author: greglin
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
ms.date: 04/19/2017
ms.topic: article
---
# Offline Migration Reference
Offline migration enables the ScanState tool to run inside a different Windows® operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
- **Windows.old.** The ScanState tool can now gather files and settings from the Windows.old directory that is created during Windows installation on a partition that contains a previous installation of Windows. For example, the ScanState tool can run in Windows 10, gathering files from a previous Windows 7or Windows 8 installation contained in the Windows.old directory.
When you use User State Migration Tool (USMT) 10.0 to gather and restore user state, offline migration reduces the cost of deployment by:
- **Reducing complexity.** In computer-refresh scenarios, migrations from the Windows.old directory reduce complexity by eliminating the need for the ScanState tool to be run before the operating system is deployed. Also, migrations from the Windows.old directory enable ScanState and LoadState to be run successively.
- **Improving performance.** When USMT runs in an offline Windows Preinstallation Environment (WinPE) environment, it has better access to the hardware resources. This may increase performance on older machines with limited hardware resources and numerous installed software applications.
- **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the ScanState tool from within WinPE.
## In This Topic
- [What Will Migrate Offline?](#bkmk-whatwillmigrate)
- [What Offline Environments are Supported?](#bkmk-offlineenvironments)
- [User-Group Membership and Profile Control](#bkmk-usergroupmembership)
- [Command-Line Options](#bkmk-commandlineoptions)
- [Environment Variables](#bkmk-environmentvariables)
- [Offline.xml Elements](#bkmk-offlinexml)
## <a href="" id="bkmk-whatwillmigrate"></a>What Will Migrate Offline?
The following user data and settings migrate offline, similar to an online migration:
- Data and registry keys specified in MigXML
- User accounts
- Application settings
- Limited set of operating-system settings
- EFS files
- Internet Explorer® Favorites
For exceptions to what you can migrate offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
## <a href="" id="bkmk-offlineenvironments"></a>What Offline Environments are Supported?
The following table defines the supported combination of online and offline operating systems in USMT.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Running Operating System</th>
<th align="left">Offline Operating System</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>WinPE 5.0 or greater, with the MSXML library</p></td>
<td align="left"><p>Windows Vista, Windows 7, Windows 8, Windows 10</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows 7, Windows 8, Windows 10</p></td>
<td align="left"><p>Windows.old directory</p></td>
</tr>
</tbody>
</table>
**Note**  
It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](https://go.microsoft.com/fwlink/p/?LinkId=190314).
## <a href="" id="bkmk-usergroupmembership"></a>User-Group Membership and Profile Control
User-group membership is not preserved during offline migrations. You must configure a **&lt;ProfileControl&gt;** section in the Config.xml file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group:
``` xml
<Configuration>
<ProfileControl>
<localGroups>
<mappings>
<changeGroup from="*" to="Users" appliesTo="MigratedUsers">
<include>
<pattern>*</pattern>
</include>
</changeGroup>
</mappings>
</localGroups>
</ProfileControl>
</Configuration>
```
For information about the format of a Config.xml file, see [Config.xml File](usmt-configxml-file.md).
## <a href="" id="bkmk-commandlineoptions"></a>Command-Line Options
An offline migration can either be enabled by using a configuration file on the command line, or by using one of the following command line options:
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Component</th>
<th align="left">Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/offline:</strong><em>&lt;path to offline.xml&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.</p></td>
</tr>
<tr class="even">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/offlineWinDir:</strong><em>&lt;Windows directory&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/OfflineWinOld:</strong><em>&lt;Windows.old directory&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.</p></td>
</tr>
</tbody>
</table>
You can use only one of the **/offline**,**/offlineWinDir** , or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together.
## <a href="" id="bkmk-environmentvariables"></a>Environment Variables
The following system environment variables are necessary in the scenarios outlined below.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Value</th>
<th align="left">Scenario</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>USMT_WORKING_DIR</p></td>
<td align="left"><p>Full path to a working directory</p></td>
<td align="left"><p>Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following:</p>
<pre class="syntax" space="preserve"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre></td>
</tr>
<tr class="even">
<td align="left"><p>MIG_OFFLINE_PLATFORM_ARCH</p></td>
<td align="left"><p>32 or 64</p></td>
<td align="left"><p>While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn’t function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following:</p>
<pre class="syntax" space="preserve"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-offlinexml"></a>Offline.xml Elements
Use an offline.xml file when running the ScanState tool on a computer that has multiple Windows directories. The offline.xml file specifies which directories to scan for windows files. An offline.xml file can be used with the /offline option as an alternative to specifying a single Windows directory path with the /offlineDir option.
### <a href="" id="-offline-"></a>&lt;offline&gt;
This element contains other elements that define how an offline migration is to be performed.
Syntax: &lt;offline&gt; &lt;/offline&gt;
### <a href="" id="-windir-"></a>&lt;winDir&gt;
This element is a required child of **&lt;offline&gt;** and contains information about how the offline volume can be selected. The migration will be performed from the first element of **&lt;winDir&gt;** that contains a valid Windows system volume.
Syntax: &lt; winDir &gt; &lt;/ winDir &gt;
### <a href="" id="-path-"></a>&lt;path&gt;
This element is a required child of **&lt;winDir&gt;** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool’s working directory.
Syntax: &lt;path&gt; c:\\windows &lt;/path&gt;
-or-
Syntax, when used with the **&lt;mappings&gt;** element: &lt;path&gt; C:\\, D:\\ &lt;/path&gt;
### <a href="" id="-mappings-"></a>&lt;mappings&gt;
This element is an optional child of **&lt;offline&gt;**. When specified, the **&lt;mappings&gt;** element will override the automatically detected WinPE drive mappings. Each child **&lt;path&gt;** element will provide a mapping from one system volume to another. Additionally, mappings between folders can be provided, since an entire volume can be mounted to a specific folder.
Syntax: &lt;mappings&gt; &lt;/mappings&gt;
### <a href="" id="-failonmultiplewindir-"></a>&lt;failOnMultipleWinDir&gt;
This element is an optional child of **&lt;offline&gt;**. The **&lt;failOnMultipleWinDir&gt;** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **&lt;failOnMultipleWinDir&gt;** element isn’t present, the default behavior is that the migration does not fail.
Syntax: &lt;failOnMultipleWinDir&gt;1&lt;/failOnMultipleWinDir&gt; or Syntax: &lt;failOnMultipleWinDir&gt;0&lt;/failOnMultipleWinDir&gt;
### Offline .xml Example
The following XML example illustrates some of the elements discussed earlier in this topic.
``` xml
<offline>
<winDir>
<path>C:\Windows</path>
<path>D:\Windows</path>
<path>E:\</path>
</winDir>
<failOnMultipleWinDir>1</failOnMultipleWinDir>
</offline>
```
## Related topics
[Plan Your Migration](usmt-plan-your-migration.md)

1083
windows/deployment/usmt/understanding-migration-xml-files.md
View File

File diff suppressed because it is too large Load Diff

Some files were not shown because too many files have changed in this diff Show More