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

Merge remote-tracking branch 'refs/remotes/origin/master' into edu-may

Browse Source
This commit is contained in:
jdeckerMS 2016-05-18 19:36:14 -07:00
commit 9ffdfecc28
124 changed files with 3503 additions and 1063 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
devices/surface/advanced-uefi-security-features-for-surface.md
View File

@ -6,7 +6,7 @@ keywords: ["Surface, Surface Pro 3, security, features, configure, hardware, dev
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: heatherpoulsen
author: miladCA
---
# Advanced UEFI security features for Surface
@ -24,9 +24,7 @@ Before you can configure the advanced security features of your Surface device,
## Manually configure additional security settings
**Note**  To enter firmware setup on a Surface device, begin with the device powered off, press and hold the **Volume Up** button, then press and release the **Power** button, then release the **Volume Up** button after the device has begun to boot.
 
>**Note:**  To enter firmware setup on a Surface device, begin with the device powered off, press and hold the **Volume Up** button, then press and release the **Power** button, then release the **Volume Up** button after the device has begun to boot.
After the v3.11.760.0 UEFI update is installed on a Surface device, an additional UEFI menu named **Advanced Device Security** becomes available. If you click this menu, the following options are displayed:
@ -57,9 +55,8 @@ As an IT professional with administrative privileges, you can automate the confi
**Sample scripts**
**Note**  The UEFI password used in the sample scripts below is presented in clear text. We strongly recommend saving the scripts in a protected location and running them in a controlled environment.
>**Note**:  The UEFI password used in the sample scripts below is presented in clear text. We strongly recommend saving the scripts in a protected location and running them in a controlled environment.
 
Show all configurable options:

15
devices/surface/customize-the-oobe-for-surface-deployments.md
View File

@ -6,27 +6,23 @@ keywords: ["deploy, customize, automate, deployment, network, Pen, pair, boot"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: heatherpoulsen
author: jobotto
---
# Customize the OOBE for Surface deployments
This article will walk you through the process of customizing the Surface out-of-box experience for end users in your organization.
This article walks you through the process of customizing the Surface out-of-box experience for end users in your organization.
It is common practice in a Windows deployment to customize the user experience for the first startup of deployed computers — the out-of-box experience, or OOBE.
**Note**  
OOBE is also often used to describe the phase, or configuration pass, of Windows setup during which the user experience is displayed. For more information about the OOBE phase of setup, see [How Configuration Passes Work](http://msdn.microsoft.com/library/windows/hardware/dn898581(v=vs.85).aspx).
 
>**Note:**  OOBE is also often used to describe the phase, or configuration pass, of Windows setup during which the user experience is displayed. For more information about the OOBE phase of setup, see [How Configuration Passes Work](http://msdn.microsoft.com/library/windows/hardware/dn898581.aspx).
In some scenarios, you may want to provide complete automation to ensure that at the end of a deployment, computers are ready for use without any interaction from the user. In other scenarios, you may want to leave key elements of the experience for users to perform necessary actions or select between important choices. For administrators deploying to Surface devices, each of these scenarios presents a unique challenge to overcome.
This article provides a summary of the scenarios where a deployment might require additional steps. It also provides the required information to ensure that the desired experience is achieved on any newly deployed Surface device. This article is intended for administrators who are familiar with the deployment process, as well as concepts such as answer files and [reference images](http://go.microsoft.com/fwlink/p/?LinkID=618042).
**Note**  
Although the OOBE phase of setup is still run during a deployment with an automated deployment solution such as the [Microsoft Deployment Toolkit (MDT)](http://go.microsoft.com/fwlink/p/?LinkId=618117) or System Center Configuration Manager Operating System Deployment (OSD), it is automated by the settings supplied in the Deployment Wizard and task sequence. For more information see:
>**Note:**  Although the OOBE phase of setup is still run during a deployment with an automated deployment solution such as the [Microsoft Deployment Toolkit (MDT)](http://go.microsoft.com/fwlink/p/?LinkId=618117) or System Center Configuration Manager Operating System Deployment (OSD), it is automated by the settings supplied in the Deployment Wizard and task sequence. For more information see:
- [Deploy Windows 10 with the Microsoft Deployment Toolkit](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit)
@ -53,8 +49,7 @@ To provide the factory Surface Pen pairing experience in OOBE, you must copy fou
- %windir%\\system32\\oobe\\info\\default\\1033\\PenError\_en-US.png
- %windir%\\system32\\oobe\\info\\default\\1033\\PenSuccess\_en-US.png
**Note**  
You should copy the files from a factory image for the same model Surface device that you intend to deploy to. For example, you should use the files from a Surface Pro 3 to deploy to Surface Pro 3, and the files from Surface Book to deploy Surface Book, but you should not use the files from a Surface Pro 3 to deploy Surface Book or Surface Pro 4.
>**Note:**  You should copy the files from a factory image for the same model Surface device that you intend to deploy to. For example, you should use the files from a Surface Pro 3 to deploy to Surface Pro 3, and the files from Surface Book to deploy Surface Book, but you should not use the files from a Surface Pro 3 to deploy Surface Book or Surface Pro 4.
 

8
devices/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices.md
View File

@ -6,7 +6,7 @@ keywords: ["update Surface, newest, latest, download, firmware, driver, tablet,
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: heatherpoulsen
author: jobotto
---
# Download the latest firmware and drivers for Surface devices
@ -26,14 +26,12 @@ Driver and firmware updates for Surface devices are released in one of two ways:
Installation files for administrative tools, drivers for accessories, and updates for Windows are also available for some devices and are detailed here in this article.
**Note**  
To simplify the process of locating drivers for your device, downloads for Surface devices have been reorganized to separate pages for each model. Bookmark the Microsoft Download Center page for your device from the links provided on this page. Many of the filenames contain a placeholder denoted with *xxxxxx*, which identifies the current version number or date of the file.
>**Note:**  To simplify the process of locating drivers for your device, downloads for Surface devices have been reorganized to separate pages for each model. Bookmark the Microsoft Download Center page for your device from the links provided on this page. Many of the filenames contain a placeholder denoted with *xxxxxx*, which identifies the current version number or date of the file.
 
Recent additions to the downloads for Surface devices provide you with options to install Windows 10 on your Surface devices and update LTE devices with the latest Windows 10 drivers and firmware.
**Note**  A battery charge of 40% or greater is required before you install firmware to a Surface device. See [Microsoft Support article KB2909710](http://go.microsoft.com/fwlink/p/?LinkId=618106) for more information.
>**Note:**  A battery charge of 40% or greater is required before you install firmware to a Surface device. See [Microsoft Support article KB2909710](http://go.microsoft.com/fwlink/p/?LinkId=618106) for more information.
 

2
devices/surface/enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md
View File

@ -6,7 +6,7 @@ keywords: ["network", "wireless", "device", "deploy", "authenticaion", "protocol
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
author: heatherpoulsen
author: miladCA
---
# Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices

4
devices/surface/ethernet-adapters-and-surface-device-deployment.md
View File

@ -6,7 +6,7 @@ keywords: ["ethernet, deploy, removable, network, connectivity, boot, firmware,
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: heatherpoulsen
author: jobotto
---
# Ethernet adapters and Surface deployment
@ -53,7 +53,7 @@ To boot a Surface device from an alternative boot device, follow these steps:
3. Press and release the **Power** button.
4. After the system begins to boot from the USB stick or Ethernet adapter, release the **Volume Down** button.
**Note**  In addition to an Ethernet adapter, a keyboard must also be connected to the Surface device to enter the preinstallation environment and navigate the deployment wizard.
>**Note:**  In addition to an Ethernet adapter, a keyboard must also be connected to the Surface device to enter the preinstallation environment and navigate the deployment wizard.
 

17
devices/surface/index.md
View File

@ -15,6 +15,9 @@ author: heatherpoulsen
This library provides guidance to help you deploy Windows on Surface devices, keep those devices up to date, and easily manage and support Surface devices in your organization.
For more information on planning for, deploying, and managing Surface devices in your organization, see the [Surface TechCenter](https://technet.microsoft.com/en-us/windows/surface).
## In this section
@ -32,15 +35,15 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
<tbody>
<tr class="odd">
<td><p>[Advanced UEFI security features for Surface](advanced-uefi-security-features-for-surface.md)</p></td>
<td><p>This article describes how to install and configure the v3.11.760.0 UEFI update to enable additional security options for Surface Pro 3 devices.</p></td>
<td><p>Find out how to install and configure the v3.11.760.0 UEFI update to enable additional security options for Surface Pro 3 devices.</p></td>
</tr>
<tr class="even">
<td><p>[Customize the OOBE for Surface deployments](customize-the-oobe-for-surface-deployments.md)</p></td>
<td><p>This article will walk you through the process of customizing the Surface out-of-box experience for end users in your organization.</p></td>
<td><p>Walk through the process of customizing the Surface out-of-box experience for end users in your organization.</p></td>
</tr>
<tr class="odd">
<td><p>[Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)</p></td>
<td><p>This article provides a list of the available downloads for Surface devices and links to download the drivers and firmware for your device.</p></td>
<td><p>Get a list of the available downloads for Surface devices and links to download the drivers and firmware for your device.</p></td>
</tr>
<tr class="even">
<td><p>[Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices](enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md)</p></td>
@ -48,7 +51,7 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
</tr>
<tr class="odd">
<td><p>[Ethernet adapters and Surface deployment](ethernet-adapters-and-surface-device-deployment.md)</p></td>
<td><p>This article provides guidance and answers to help you perform a network deployment to Surface devices.</p></td>
<td><p>Get guidance and answers to help you perform a network deployment to Surface devices.</p></td>
</tr>
<tr class="even">
<td><p>[Manage Surface Dock firmware updates](manage-surface-dock-firmware-updates.md)</p></td>
@ -56,7 +59,7 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
</tr>
<tr class="odd">
<td><p>[Manage Surface driver and firmware updates](manage-surface-pro-3-firmware-updates.md)</p></td>
<td><p>This article describes the available options to manage firmware and driver updates for Surface devices.</p></td>
<td><p>Explore the available options to manage firmware and driver updates for Surface devices.</p></td>
</tr>
<tr class="even">
<td><p>[Surface Data Eraser](microsoft-surface-data-eraser.md)</p></td>
@ -64,7 +67,7 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
</tr>
<tr class="odd">
<td><p>[Surface Deployment Accelerator](microsoft-surface-deployment-accelerator.md)</p></td>
<td><p>Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices.</p></td>
<td><p>See how Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices.</p></td>
</tr>
<tr class="even">
<td><p>[Surface Diagnostic Toolkit](surface-diagnostic-toolkit.md)</p></td>
@ -72,7 +75,7 @@ This library provides guidance to help you deploy Windows on Surface devices, ke
</tr>
<tr class="odd">
<td><p>[Surface Dock Updater](surface-dock-updater.md)</p></td>
<td><p>This article provides a detailed walkthrough of Microsoft Surface Dock Updater.</p></td>
<td><p>Get a detailed walkthrough of Microsoft Surface Dock Updater.</p></td>
</tr>
</tbody>
</table>

20
devices/surface/manage-surface-dock-firmware-updates.md
View File

@ -5,7 +5,7 @@ ms.assetid: 86DFC0C0-C842-4CD1-A2D7-4425471FFE3F
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: heatherpoulsen
author: jobotto
---
# Manage Surface Dock firmware updates
@ -13,16 +13,15 @@ author: heatherpoulsen
Read about the different methods you can use to manage the process of Surface Dock firmware updates.
The Surface Dock provides external connectivity to Surface devices through a single cable connection that includes Power, Ethernet, Audio, USB 3.0, and DisplayPort. The numerous connections provided by the Surface Dock are enabled by a smart chipset within the Surface Dock device. Like a Surface device’s chipset, the chipset that is built into the Surface Dock is controlled by firmware.
The Surface Dock provides external connectivity to Surface devices through a single cable connection that includes Power, Ethernet, Audio, USB 3.0, and DisplayPort. The numerous connections provided by the Surface Dock are enabled by a smart chipset within the Surface Dock device. Like a Surface device’s chipset, the chipset that is built into the Surface Dock is controlled by firmware. For more information about the Surface Dock, see the [Surface Dock demonstration](https://technet.microsoft.com/en-us/mt697552) video.
Like the firmware for Surface devices, firmware for Surface Dock is also contained within a downloaded driver that is visible in Device Manager. This driver stages the firmware update files on the Surface device. When a Surface Dock is connected and the driver is loaded, the newer version of the firmware staged by the driver is detected and firmware files are copied to the Surface Dock. The Surface Dock then begins a two-phase process to apply the firmware internally. Each phase requires the Surface Dock to be disconnected from the Surface device before the firmware is applied. The driver copies the firmware into the dock, but only applies it when the user disconnects the Surface device from the Surface Dock. This ensures that there are no disruptions because the firmware is only applied when the user leaves their desk with the device.
**Note**  
You can learn more about the firmware update process for Surface devices and how firmware is updated through driver installation at the following links:
>**Note:**&nbsp;&nbsp;You can learn more about the firmware update process for Surface devices and how firmware is updated through driver installation at the following links:
- [How to manage and update your drivers and firmware for Surface](http://go.microsoft.com/fwlink/p/?LinkId=785353) from Microsoft Mechanics
- [Windows Update Makes Surface Better](http://go.microsoft.com/fwlink/p/?LinkId=785354)on the Microsoft Devices Blog
- [Windows Update Makes Surface Better](http://go.microsoft.com/fwlink/p/?LinkId=785354) on the Microsoft Devices Blog
 
@ -70,8 +69,7 @@ There are three methods you can use to update the firmware of the Surface Dock:
Windows Update is the method that most users will use. The drivers for the Surface Dock are downloaded automatically from Windows Update and the dock update process is initiated without additional user interaction. The two-phase dock update process described earlier occurs in the background as the user connects and disconnects the Surface Dock during normal use.
**Note**  
The driver version that is displayed in Device Manager may be different from the firmware version that the Surface Dock is using.
>**Note:**&nbsp;&nbsp;The driver version that is displayed in Device Manager may be different from the firmware version that the Surface Dock is using.
 
@ -82,10 +80,8 @@ This method is used mostly in environments where Surface device drivers and firm
For more information about how to deploy MSI packages see [Create and deploy an application with System Center Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=785355).
**Note**  
When drivers are installed through Windows Update or the MSI package, registry keys are added that indicate the version of firmware installed on the Surface Dock and contained within the Surface Dock driver. These registry keys can be found in:
**HLKM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\WUDF\\Services\\SurfaceDockFwUpdate\\Parameters**
>**Note:**&nbsp;&nbsp;When drivers are installed through Windows Update or the MSI package, registry keys are added that indicate the version of firmware installed on the Surface Dock and contained within the Surface Dock driver. These registry keys can be found in:<br/><br/>
**HLKM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\WUDF\\Services\\SurfaceDockFwUpdate\\Parameters**
Firmware status is displayed for both the main chipset (displayed as **Component10**) and the DisplayPort chipset (displayed as **Component20**). For each chipset there are four keys, where *xx* is **10** or **20** corresponding to each chipset:
@ -97,7 +93,7 @@ Firmware status is displayed for both the main chipset (displayed as **Component
- **Component*xx*FirmwareUpdateStatusRejectReason** – This key changes as the firmware update is processed. It should result in 0 after the successful installation of Surface Dock firmware.
These registry keys are not present unless you have installed updated Surface Dock drivers through Windows Update or MSI deployment.
>**Note:**&nbsp;&nbsp;These registry keys are not present unless you have installed updated Surface Dock drivers through Windows Update or MSI deployment.
 

2
devices/surface/manage-surface-pro-3-firmware-updates.md
View File

@ -6,7 +6,7 @@ keywords: ["Surface, Surface Pro 3, firmware, update, device, manage, deploy, dr
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: heatherpoulsen
author: jobotto
---
# Manage Surface driver and firmware updates

17
devices/surface/microsoft-surface-data-eraser.md
View File

@ -6,7 +6,7 @@ keywords: ["tool", "USB", "data", "erase"]
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: heatherpoulsen
author: miladCA
---
# Microsoft Surface Data Eraser
@ -40,15 +40,10 @@ Some scenarios where Microsoft Surface Data Eraser can be helpful include:
- Standard practice when performing reimaging for devices used with sensitive data
**Note**  
Third-party devices, Surface devices running Windows RT (including Surface and Surface 2), and Surface Pro are not compatible with Microsoft Surface Data Eraser.
>**Note:**&nbsp;&nbsp;Third-party devices, Surface devices running Windows RT (including Surface and Surface 2), and Surface Pro are not compatible with Microsoft Surface Data Eraser.
 
>**Note:**&nbsp;&nbsp;Because the ability to boot to USB is required to run Microsoft Surface Data Eraser, if the device is not configured to boot from USB or if the device is unable to boot or POST successfully, the Microsoft Surface Data Eraser tool will not function.
**Note**  
Because the ability to boot to USB is required to run Microsoft Surface Data Eraser, if the device is not configured to boot from USB or if the device is unable to boot or POST successfully, the Microsoft Surface Data Eraser tool will not function.
 
## How to create a Microsoft Surface Data Eraser USB stick
@ -74,12 +69,8 @@ After the creation tool is installed, follow these steps to create a Microsoft S
Figure 1. Start the Microsoft Surface Data Eraser tool
4. Select the USB drive of your choice from the **USB Thumb Drive Selection** page as shown in Figure 2, and then click **Start** to begin the USB creation process. The drive you select will be formatted and any existing data on this drive will be lost.
**Note**  
If the Start button is disabled, check that your removable drive has a total capacity of at least 4 GB.
>**Note:**&nbsp;&nbsp;If the Start button is disabled, check that your removable drive has a total capacity of at least 4 GB.
 
![figure 2](images/dataeraser-usb-selection.png)
Figure 2. USB thumb drive selection

10
devices/surface/microsoft-surface-deployment-accelerator.md
View File

@ -6,7 +6,7 @@ keywords: ["deploy", "install", "tool"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: heatherpoulsen
author: miladCA
---
# Microsoft Surface Deployment Accelerator
@ -20,7 +20,7 @@ Microsoft Surface Deployment Accelerator is built on the powerful suite of deplo
You can find more information about how to deploy to Surface devices, including step-by-step walkthroughs of customized deployment solution implementation, on the Deploy page of the [Surface TechCenter](http://go.microsoft.com/fwlink/p/?LinkId=691693).
### Download Microsoft Surface Deployment Accelerator
**Download Microsoft Surface Deployment Accelerator**
You can download the installation files for Microsoft Surface Deployment Accelerator from the Microsoft Download Center. To download the installation files:
@ -60,8 +60,7 @@ When the Microsoft Surface Deployment Accelerator completes, you can use the dep
You can modify the task sequence in the MDT Deployment Workbench to [include your own apps](http://go.microsoft.com/fwlink/p/?linkid=691700), or to [pause the automated installation routine](http://go.microsoft.com/fwlink/p/?linkid=691701). While the installation is paused, you can make changes to customize your reference image. After the image is captured, you can configure a deployment task sequence and distribute this custom configuration by using the same network boot capabilities as before.
**Note**  
With Microsoft Surface Deployment Accelerator v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
>**Note:**&nbsp;&nbsp;With Microsoft Surface Deployment Accelerator v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
 
@ -76,8 +75,7 @@ Figure 2. Specify a local source for Surface driver and app files
You can find a full list of available driver downloads at [Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)
**Note**  
Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one folder.
>**Note:**&nbsp;&nbsp;Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one folder.
 

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

@ -6,7 +6,7 @@ keywords: ["deploy, configure"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: heatherpoulsen
author: miladCA
---
# Step by step: Surface Deployment Accelerator
@ -37,8 +37,7 @@ The tool installs in the Surface Deployment Accelerator program group, as shown
Figure 2. The Surface Deployment Accelerator program group and icon
**Note**  
At this point the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.
>**Note:**&nbsp;&nbsp;At this point the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.
 
@ -47,8 +46,7 @@ At this point the tool has not yet prepared any deployment environment or downlo
The following steps show how you create a deployment share for Windows 10 that supports Surface Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, and the Surface Asset Tag Tool. As you follow the steps below, make the selections that are applicable for your organization. For example, you could choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.
**Note**  
SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need to run the tool twice.
>**Note:**&nbsp;&nbsp;SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need to run the tool twice.
 
@ -116,8 +114,7 @@ SDA lets you create deployment shares for both Windows 8.1 and Windows 10 depl
If you are unable to connect to the Internet with your deployment server, or if you want to download the Surface drivers and apps separately, you can specify a local source for the driver an app files at the time of deployment share creation. On the **Configure** page of the SDA wizard, select the **Copy from a Local Directory** check box, as shown in Figure 6. The **Download from the Internet** check box will be automatically deselected. Enter the folder location where you have placed the driver and app files in the **Local Path** field, as shown in Figure 6.
**Note**  
All of the downloaded driver and applications files must be located in the same folder. The driver and app files do not need to be extracted from the downloaded .zip files.
>**Note:**&nbsp;&nbsp;All of the downloaded driver and applications files must be located in the same folder. The driver and app files do not need to be extracted from the downloaded .zip files.
 
@ -125,8 +122,7 @@ All of the downloaded driver and applications files must be located in the same
Figure 6. Specify the Surface driver and app files from a local path
**Note**  
The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
>**Note:**&nbsp;&nbsp;The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
 
@ -134,8 +130,7 @@ The **Copy from a Local Directory** check box is only available in SDA version 1
You can use USB media to perform an SDA deployment if your Surface device is unable to boot from the network. For example, if you do not have a Microsoft Surface Ethernet Adapter or Microsoft Surface dock to facilitate network boot (PXE boot). The USB drive produced by following these steps includes a complete copy of the SDA deployment share and can be run on a Surface device without a network connection.
**Note**  
The offline media files for the complete SDA deployment share are approximately 9 GB in size. Your USB drive must be at least 9 GB in size. A 16 GB USB drive is recommended.
>**Note:**&nbsp;&nbsp;The offline media files for the complete SDA deployment share are approximately 9 GB in size. Your USB drive must be at least 9 GB in size. A 16 GB USB drive is recommended.
 
@ -149,8 +144,7 @@ Before you can create bootable media files within the MDT Deployment Workbench o
4. **clean** – Removes all configuration from your USB drive.
**Warning**  
This step will remove all information from your drive. Verify that your USB drive does not contain any needed data before you perform the **clean** command.
>**Warning:**&nbsp;&nbsp;This step will remove all information from your drive. Verify that your USB drive does not contain any needed data before you perform the **clean** command.
 
@ -168,8 +162,7 @@ Before you can create bootable media files within the MDT Deployment Workbench o
Figure 7. Use DiskPart to prepare a USB drive for boot
**Note**  
You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the partition as active for the drive to boot properly.
>**Note:**&nbsp;&nbsp;You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the partition as active for the drive to boot properly.
 
@ -276,8 +269,7 @@ When you run the task sequence, you will be prompted to provide the following in
- A product key, if one is required
**Note**  
If you are deploying the same version of Windows as the version that came on your device, no product key is required.
>**Note:**&nbsp;&nbsp;If you are deploying the same version of Windows as the version that came on your device, no product key is required.
 
@ -293,8 +285,7 @@ The **2 – Create Windows Reference Image** task sequence is used to perform a
Like the **1 – Deploy Microsoft Surface** task sequence, the **2 – Create Windows Reference Image** task sequence performs a deployment of the unaltered Windows image directly from the installation media. Creation of a reference image should always be performed on a virtual machine. Using a virtual machine as your reference system helps to ensure that the resulting image is compatible with different hardware configurations.
**Note**  
Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information see [Deploy a Windows 10 image using MDT 2013 Update 1](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
>**Note:**&nbsp;&nbsp;Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information see [Deploy a Windows 10 image using MDT 2013 Update 1](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
 

72
devices/surface/surface-diagnostic-toolkit.md
View File

@ -6,7 +6,7 @@ keywords: ["hardware, device, tool, test, component"]
ms.prod: W8
ms.mktglfcycl: manage
ms.sitesec: library
author: heatherpoulsen
author: miladCA
---
# Microsoft Surface Diagnostic Toolkit
@ -16,8 +16,7 @@ Find out how you can use the Microsoft Surface Diagnostic Toolkit to test the ha
The [Microsoft Surface Diagnostic Toolkit](http://go.microsoft.com/fwlink/p/?LinkId=618121) is a small, portable diagnostic tool that runs through a suite of tests to diagnose the hardware of Surface devices. The Microsoft Surface Diagnostic Toolkit executable file is less than 3 MB, which allows it to be distributed through email. It does not require installation, so it can be run directly from a USB stick or over the network. The Microsoft Surface Diagnostic Toolkit walks you through several tests of individual components including the touchscreen, cameras, and sensors.
**Note**  
A Surface device must boot into Windows to run the Microsoft Surface Diagnostic Toolkit. The Microsoft Surface Diagnostic Toolkit will run only on the following Surface devices:
>**Note:**&nbsp;&nbsp;A Surface device must boot into Windows to run the Microsoft Surface Diagnostic Toolkit. The Microsoft Surface Diagnostic Toolkit will run only on the following Surface devices:
- Surface Book
@ -33,12 +32,7 @@ A Surface device must boot into Windows to run the Microsoft Surface Diagnostic
- Surface Pro
 
**Note**  
Security software and built-in security measures in many email applications and services will block executable files that are transferred through email. To email the Surface Diagnostic Toolkit, attach the .zip archive file as downloaded from the Surface Tools for IT page without extracting it first. You can also create a custom .zip archive that contains the .exe file. (For example, if you want to localize the text as described in the [Localization](#localization) section of this article.)
 
>**Note:**&nbsp;&nbsp;Security software and built-in security measures in many email applications and services will block executable files that are transferred through email. To email the Surface Diagnostic Toolkit, attach the .zip archive file as downloaded from the Surface Tools for IT page without extracting it first. You can also create a custom .zip archive that contains the .exe file. (For example, if you want to localize the text as described in the [Localization](#localization) section of this article.)
Running the Microsoft Surface Diagnostic Toolkit is a hands-on activity. The test sequence includes several tests that require you to perform actions or observe the outcome of the test, and then click the applicable **Pass** or **Fail** button. Some tests require connectivity to external devices, like an external display. Other tests use the built in Windows troubleshooters. At the end of testing, a visual report of the test results is displayed and you are given the option to save a log file or copy the results to the clipboard.
@ -56,8 +50,7 @@ To run a full set of tests with the Microsoft Surface Diagnostic Toolkit, you sh
- External speakers or headphones
**Note**  
The Microsoft Surface Diagnostic Toolkit tests verify only the hardware of a Surface device and do not test or resolve issues with the operating system or software.
>**Note:**&nbsp;&nbsp;The Microsoft Surface Diagnostic Toolkit tests verify only the hardware of a Surface device and do not test or resolve issues with the operating system or software.
 
@ -122,8 +115,7 @@ These files and logs are stored in a .zip file saved by the Microsoft Surface Di
### <a href="" id="type-cover--test"></a>Type Cover test
**Note**  
A Surface Type Cover is required for this test.
>**Note:**&nbsp;&nbsp;A Surface Type Cover is required for this test.
 
@ -131,8 +123,7 @@ If a Surface Type Cover is not detected, the test prompts you to connect the Typ
### Integrated keyboard test
**Note**  
This test is only applicable to Surface Book and requires that the Surface Book be docked to the keyboard.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book and requires that the Surface Book be docked to the keyboard.
 
@ -140,8 +131,7 @@ This test is essentially the same as the Type Cover test, except the integrated
### Canvas mode battery test
**Note**  
This test is only applicable to Surface Book.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
@ -149,8 +139,7 @@ Depending on which mode Surface Book is in, different batteries are used to powe
### Clipboard mode battery test
**Note**  
This test is only applicable to Surface Book.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
@ -158,8 +147,7 @@ Disconnect the Surface Book from the keyboard to work in clipboard mode. In clip
### Laptop mode battery test
**Note**  
This test is only applicable to Surface Book.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
@ -171,8 +159,7 @@ In this test the battery is discharged for a few seconds and tested for health a
### Discrete graphics (dGPU) test
**Note**  
This test is only applicable to Surface Book models with a discrete graphics processor.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book models with a discrete graphics processor.
 
@ -180,8 +167,7 @@ This test will query the device information of current hardware to check for the
### Discrete graphics (dGPU) fan test
**Note**  
This test is only applicable to Surface Book models with a discrete graphics processor.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book models with a discrete graphics processor.
 
@ -189,8 +175,7 @@ The discrete graphics processor in the Surface Book includes a separate cooling
### Muscle wire test
**Note**  
This test is only applicable to Surface Book.
>**Note:**&nbsp;&nbsp;This test is only applicable to Surface Book.
 
@ -198,8 +183,7 @@ To disconnect the Surface Book from the keyboard, software must instruct the mus
### Dead pixel and display artifacts tests
**Note**  
Before you run this test, be sure to clean the screen of dust or smudges.
>**Note:**&nbsp;&nbsp;Before you run this test, be sure to clean the screen of dust or smudges.
 
@ -219,8 +203,7 @@ The Surface touchscreen should detect input across the entire screen of the devi
### <a href="" id="digitizer-pen--test"></a>Digitizer pen test
**Note**  
A Microsoft Surface Pen is required for this test.
>**Note:**&nbsp;&nbsp;A Microsoft Surface Pen is required for this test.
 
@ -240,8 +223,7 @@ This test prompts you to use the volume rocker to turn the volume all the way up
### <a href="" id="micro-sd-or-sd--slot-test--"></a>Micro SD or SD slot test
**Note**  
This test requires a micro SD or SD card that is compatible with the slot in your Surface device.
>**Note:**&nbsp;&nbsp;This test requires a micro SD or SD card that is compatible with the slot in your Surface device.
 
@ -253,8 +235,7 @@ This test displays the **Recording** tab of the Sound item in Control Panel. The
### <a href="" id="video-out--test"></a>Video out test
**Note**  
This test requires an external display with the applicable connection for your Surface device.
>**Note:**&nbsp;&nbsp;This test requires an external display with the applicable connection for your Surface device.
 
@ -262,8 +243,7 @@ Surface devices provide a Mini DisplayPort connection for connecting to an exter
### <a href="" id="bluetooth--test"></a>Bluetooth test
**Note**  
This test requires a Bluetooth device. The device must be set to pairing mode or made discoverable to perform this test.
>**Note:**&nbsp;&nbsp;This test requires a Bluetooth device. The device must be set to pairing mode or made discoverable to perform this test.
 
@ -275,8 +255,7 @@ Use this test to verify that the cameras on your Surface device are operating pr
### <a href="" id="speaker-test--"></a>Speaker test
**Note**  
Headphones or external speakers are required to test the headphone jack in this test.
>**Note:**&nbsp;&nbsp;Headphones or external speakers are required to test the headphone jack in this test.
 
@ -284,8 +263,7 @@ This test plays audio over left and right channels respectively, both for the in
### <a href="" id="network-test--"></a>Network test
**Note**  
Connect the Surface device to a Wi-Fi network before you run this test. Connections that are made during the test are removed when the test is completed.
>**Note:**&nbsp;&nbsp;Connect the Surface device to a Wi-Fi network before you run this test. Connections that are made during the test are removed when the test is completed.
 
@ -317,8 +295,7 @@ The ambient light sensor is used to automatically adjust screen brightness relat
### <a href="" id="device-orientation-test--"></a>Device orientation test
**Note**  
Before you run this test, disable rotation lock from the Action Center if enabled.
>**Note:**&nbsp;&nbsp;Before you run this test, disable rotation lock from the Action Center if enabled.
 
@ -330,8 +307,7 @@ This test cycles the screen through brightness levels from 0 percent to 100 perc
### <a href="" id="system-assessment--"></a>System assessment
**Note**  
The Surface device must be connected to AC power before you can run this test.
>**Note:**&nbsp;&nbsp;The Surface device must be connected to AC power before you can run this test.
 
@ -350,8 +326,7 @@ If your Surface device has encountered an error that caused the device to fail o
You can run the Microsoft Surface Diagnostic Toolkit from the command line or as part of a script. The tool supports the following arguments:
**Note**  
Many of the tests performed by the Microsoft Surface Diagnostic Toolkit require technician interaction. The Microsoft Surface Diagnostic Toolkit cannot run unattended.
>**Note:**&nbsp;&nbsp;Many of the tests performed by the Microsoft Surface Diagnostic Toolkit require technician interaction. The Microsoft Surface Diagnostic Toolkit cannot run unattended.
 
@ -506,8 +481,7 @@ By default, the Microsoft Surface Diagnostic Toolkit is available in English onl
6. Save the SurfaceDiagnosticTool\_v1.0.60.0.locale file.
**Note**  
The SurfaceDiganosticTool\_v1.0.60.0.locale file must be located in the same folder and have the same name other than the file extension as the Microsoft Surface Diagnostic Toolkit executable file to use the custom prompt text. The SurfaceDiganosticTool\_v1.0.60.0.locale is an .xml file and must use UTF-8 encoding.
>**Note:**&nbsp;&nbsp;The SurfaceDiganosticTool\_v1.0.60.0.locale file must be located in the same folder and have the same name other than the file extension as the Microsoft Surface Diagnostic Toolkit executable file to use the custom prompt text. The SurfaceDiganosticTool\_v1.0.60.0.locale is an .xml file and must use UTF-8 encoding.
 

12
devices/surface/surface-dock-updater.md
View File

@ -5,7 +5,7 @@ ms.assetid: 1FEFF277-F7D1-4CB4-8898-FDFE8CBE1D5C
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
author: heatherpoulsen
author: jobotto
---
# Microsoft Surface Dock Updater
@ -17,8 +17,7 @@ The [Microsoft Surface Dock Updater](http://go.microsoft.com/fwlink/p/?LinkId=61
When you run the Microsoft Surface Dock Updater installer you will be prompted to accept an End User License Agreement (EULA).
**Note**  
Updating Surface Dock firmware requires connectivity to the Surface Dock, available only on Surface Pro 3, Surface Pro 4, and Surface Book devices. A Surface Pro 3, Surface Pro 4, or Surface Book is required to successfully install Microsoft Surface Dock Updater.
>**Note:**&nbsp;&nbsp;Updating Surface Dock firmware requires connectivity to the Surface Dock, available only on Surface Pro 3, Surface Pro 4, and Surface Book devices. A Surface Pro 3, Surface Pro 4, or Surface Book is required to successfully install Microsoft Surface Dock Updater.
## Update a Surface Dock with Microsoft Surface Dock Updater
@ -73,8 +72,7 @@ To update a Surface Dock with Microsoft Surface Dock Updater, follow these steps
9. If you want to update multiple Surface Docks in one sitting, you can click the **Update another Surface Dock** button to begin the process on the next Surface Dock.
**Note**  
The LED in the Ethernet port of the dock will blink while the update is in progress. Please wait until the LED stops blinking before you unplug your Surface Dock from power.
>**Note:**&nbsp;&nbsp;The LED in the Ethernet port of the dock will blink while the update is in progress. Please wait until the LED stops blinking before you unplug your Surface Dock from power.
 
@ -96,10 +94,10 @@ Microsoft Surface Dock Updater logs its progress into the Event Log, as shown in
| 12102 | Event in the DisplayPort chipset firmware update process |
| 12105 | Error |
 
Figure 8. Surface Dock Updater events in Event Viewer
![figure 8](images/surfacedockupdater-fig8-737test.png)
Figure 8. Surface Dock Updater events in Event Viewer
## Related topics

21
windows/deploy/activate-forest-by-proxy-vamt.md
View File

@ -2,34 +2,40 @@
title: Activate by Proxy an Active Directory Forest (Windows 10)
description: Activate by Proxy an Active Directory Forest
ms.assetid: 6475fc87-a6f7-4fa8-b0aa-de19f2dea7e5
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Activate by Proxy an Active Directory Forest
You can use the Volume Activation Management Tool (VAMT) Active Directory-Based Activation (ADBA) function to activate by proxy an Active Directory (AD) forest for an isolated workgroup that does not have Internet access. ADBA enables certain volume products to inherit activation from the domain.
**Important**  
ADBA is only applicable to Generic Volume License Keys (GVLKs) and KMS Host key (CSVLK). To use ADBA, one or more KMS Host keys (CSVLK) must be installed on the AD forest, and client keys (GVLKs) must be installed on the client products.
In a typical proxy-activation scenario, the VAMT host computer distributes a product key to one or more client computers and collects the installation ID (IID) from each computer. The VAMT host computer sends the IIDs to Microsoft on behalf of the client computers and obtains the corresponding Confirmation IDs (CIDs). The VAMT host computer then installs the CIDs on the client computer to complete the activation. If you use this activation method, only the VAMT host computer needs to have Internet access.
**Note**  
For workgroups that are isolated from any larger network, you can still perform an AD forest activation. This requires installing a second instance of VAMT on a computer in the isolated group and using removable media to transfer activation data between that computer and another VAMT host computer that has Internet access. You can also activate by proxy a KMS Host key (CSVLK) in the core network if you do not want the host computer to connect to Microsoft over the Internet.
## Requirements
Before performing proxy activation, ensure that the network and the VAMT installation meet the following requirements:
- There is an instance of VAMT that is installed on a computer that has Internet access. If you are performing proxy activation for an isolated workgroup, you must also have VAMT installed on one of the computers in the workgroup.
- VAMT has administrative permissions to the Active Directory domain.
**To perform an Active Directory forest proxy activation**
1. Open VAMT.
2. In the left-side pane, click the **Active Directory-Based Activation** node.
3. In the right-side **Actions** pane, click **Proxy activate forest** to open the **Install Product Key** dialog box.
4. In the **Install Product Key** dialog box, select the KMS Host key (CSVLK) that you want to activate.
5. If you want to rename the ADBA object, enter a new Active Directory-Based Activation Object name.
**Important**  
If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
5. If you want to rename the ADBA object, enter a new Active Directory-Based Activation Object name. If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
6. Enter the name of the file where you want to save the offline installation ID, or browse to the file location and then click **Open**. If you are activating an AD forest in an isolated workgroup, save the .cilx file to a removable media device.
7. Click **Install Key**.
VAMT displays the **Activating Active Directory** dialog box until it completes the requested action. The activated object and the date that it was created appear in the **Active Directory-Based Activation** node in the center pane.
7. Click **Install Key**. VAMT displays the **Activating Active Directory** dialog box until it completes the requested action. The activated object and the date that it was created appear in the **Active Directory-Based Activation** node in the center pane.
9. Insert the removable media into the VAMT host that has Internet access. Make sure that you are on the root node, and that the **Volume Activation Management Tool** view is displayed in the center pane.
10. In the right-side **Actions** pane, click **Acquire confirmation IDs for CILX** to open the **Acquire confirmation IDs for file** dialog box.
11. In the **Acquire confirmation IDs for file** dialog box, browse to where the .cilx file you exported from the isolated workgroup host computer is located. Select the file, and then click **Open**. VAMT displays an **Acquiring Confirmation IDs** message while it contacts Microsoft and acquires the CIDs.
@ -37,6 +43,9 @@ Before performing proxy activation, ensure that the network and the VAMT install
13. Remove the storage device that contains the .cilx file from the Internet-connected VAMT host computer and insert it into the VAMT host computer in the isolated workgroup.
14. Open VAMT and then click the **Active Directory-Based Activation** node in the left-side pane.
15. In the right-side **Actions** pane, click **Apply confirmation ID to Active Directory domain**, browse to the .cilx file and then click **Open**.
VAMT displays the **Activating Active Directory** dialog box until it completes the requested action. The activated object and the date that it was created appear in the **Active Directory-Based Activation** node in the center pane.
## Related topics
- [Add and Remove Computers](add-remove-computers-vamt.md)

14
windows/deploy/activate-forest-vamt.md
View File

@ -2,32 +2,44 @@
title: Activate an Active Directory Forest Online (Windows 10)
description: Activate an Active Directory Forest Online
ms.assetid: 9b5bc193-799b-4aa5-9d3e-0e495f7195d3
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Activate an Active Directory Forest Online
You can use the Volume Activation Management Tool (VAMT) Active Directory-Based Activation (ADBA) function to activate an Active Directory (AD) forest over the Internet. ADBA enables certain products to inherit activation from the domain.
**Important**  
ADBA is only applicable to Generic Volume License Keys (GVLKs) and KMS Host keys (CSVLKs). To use ADBA, one or more KMS Host keys (CSVLKs) must be installed on the AD forest, and client keys (GVLKs) must be installed on the client products.
## Requirements
Before performing online activation, ensure that the network and the VAMT installation meet the following requirements:
- VAMT is installed on a host computer that has Internet access.
- VAMT has administrative permissions to the Active Directory domain.
- The KMS Host key (CSVLK) you intend to use is added to VAMT in the **Product Keys** node.
**To perform an online Active Directory forest activation**
1. Open VAMT.
2. In the left-side pane, click the **Active Directory-Based Activation** node.
3. In the right-side **Actions** pane, click **Online activate forest** to open the **Install Product Key** dialog box.
4. In the **Install Product Key** dialog box, select the KMS Host key (CSVLK) that you want to apply to the AD forest.
5. If required, enter a new Active Directory-Based Activation Object name
**Important**  
If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
6. Click **Install Key**.
7. VAMT displays the **Activating Active Directory** dialog box until it completes the requested action.
The activated object and the date that is was created appear in the **Active Directory-Based Activation** node in the center pane.
## Related topics
- [Scenario 1: Online Activation](scenario-online-activation-vamt.md)
- [Add and Remove Computers](add-remove-computers-vamt.md)

28
windows/deploy/activate-using-active-directory-based-activation-client.md
View File

@ -2,13 +2,14 @@
title: Activate using Active Directory-based activation (Windows 10)
description: Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects.
ms.assetid: 08cce6b7-7b5b-42cf-b100-66c363a846af
ms.pagetype: activation
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: CFaw
---
# Activate using Active Directory-based activation
**Applies to**
- Windows 10
@ -18,8 +19,10 @@ author: CFaw
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects. Active Directory-based activation requires that the forest schema be updated by adprep.exe on a computer running Windows Server 2012 R2 or Windows Server 2012, but after the schema is updated, older domain controllers can still activate clients.
Any domain-joined computers running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 with a GVLK will be activated automatically and transparently. They will stay activated as long as they remain members of the domain and maintain periodic contact with a domain controller. Activation takes place after the Licensing service starts. When this service starts, the computer contacts AD DS automatically, receives the activation object, and is activated without user intervention.
To allow computers with GVLKs to activate themselves, use the Volume Activation Tools console in Windows Server 2012 R2 or the VAMT in earlier versions of Windows Server to create an object in the AD DS forest. You create this activation object by submitting a KMS host key to Microsoft, as shown in Figure 10.
@ -29,8 +32,11 @@ The process proceeds as follows:
- Extend the domain to the Windows Server 2012 R2 schema level, and add a KMS host key by using the VAMT.
2. Microsoft verifies the KMS host key, and an activation object is created.
3. Client computers are activated by receiving the activation object from a domain controller during startup.
![Active Directory-based activation flow](images/volumeactivationforwindows81-10.jpg)
**Figure 10**. The Active Directory-based activation flow
For environments in which all computers are running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2, and they are joined to a domain, Active Directory-based activation is the best option for activating all client computers and servers, and you may be able to remove any KMS hosts from your environment.
If an environment will continue to contain earlier volume licensing operating systems and applications or if you have workgroup computers outside the domain, you need to maintain a KMS host to maintain activation status for earlier volume licensing editions of Windows and Office.
Clients that are activated with Active Directory-based activation will maintain their activated state for up to 180 days since the last contact with the domain, but they will periodically attempt to reactivate before then and at the end of the 180day period. By default, this reactivation event occurs every seven days.
@ -42,22 +48,39 @@ You must be a member of the local Administrators group on all computers mentione
1. Use an account with Domain Administrator and Enterprise Administrator credentials to sign in to a domain controller.
2. Launch Server Manager.
3. Add the Volume Activation Services role, as shown in Figure 11.
![Adding the Volume Activation Services role](images/volumeactivationforwindows81-11.jpg)
**Figure 11**. Adding the Volume Activation Services role
4. Click the link to launch the Volume Activation Tools (Figure 12).
![Launching the Volume Activation Tools](images/volumeactivationforwindows81-12.jpg)
**Figure 12**. Launching the Volume Activation Tools
5. Select the **Active Directory-Based Activation** option (Figure 13).
![Selecting Active Directory-Based Activation](images/volumeactivationforwindows81-13.jpg)
**Figure 13**. Selecting Active Directory-Based Activation
6. Enter your KMS host key and (optionally) a display name (Figure 14).
![Entering your KMS host key](images/volumeactivationforwindows81-14.jpg)
**Figure 14**. Entering your KMS host key
7. Activate your KMS host key by phone or online (Figure 15).
![Choosing how to activate your product](images/volumeactivationforwindows81-15.jpg)
**Figure 15**. Choosing how to activate your product
8. After activating the key, click **Commit**, and then click **Close**.
## Verifying the configuration of Active Directory-based activation
To verify your Active Directory-based activation configuration, complete the following steps:
1. After you configure Active Directory-based activation, start a computer that is running an edition of Windows that is configured by volume licensing.
2. If the computer has been previously configured with a MAK key, replace the MAK key with the GVLK by running the **slmgr.vbs /ipk** command and specifying the GLVK as the new product key.
@ -65,6 +88,7 @@ To verify your Active Directory-based activation configuration, complete the fol
4. Sign in to the computer.
5. Open Windows Explorer, right-click **Computer**, and then click **Properties**.
6. Scroll down to the **Windows activation** section, and verify that this client has been activated.
**Note**<br>
If you are using both KMS and Active Directory-based activation, it may be difficult to see whether a client has been activated by KMS or by Active Directory-based activation. Consider disabling KMS during the test, or make sure that you are using a client computer that has not already been activated by KMS. The **slmrg.vbs /dlv** command also indicates whether KMS has been used.

61
windows/deploy/activate-using-key-management-service-vamt.md
View File

@ -1,15 +1,17 @@
---
title: Activate using Key Management Service (Windows 10)
ms.assetid: f2417bfe-7d25-4e82-bc07-de316caa8dac
ms.pagetype: activation
description:
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Activate using Key Management Service
**Applies to**
- Windows 10
- Windows 8.1
@ -18,73 +20,118 @@ author: jdeckerMS
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
There are three possible scenarios for volume activation of Windows 10 or Windows Server 2012 R2 by using a Key Management Service (KMS) host:
- Host KMS on a computer running Windows 10
- Host KMS on a computer running Windows Server 2012 R2
- Host KMS on a computer running an earlier version of Windows
## Key Management Service in Windows 10
Installing a KMS host key on a computer running Windows 10 allows you to activate other computers running Windows 10 against this KMS host and earlier versions of the client operating system, such as Windows 8.1 or Windows 7.
Clients locate the KMS server by using resource records in DNS, so some configuration of DNS may be required. This scenario can be beneficial if your organization uses volume activation for clients and MAK-based activation for a smaller number of servers.
To enable KMS functionality, a KMS key is installed on a KMS host; then, the host is activated over the Internet or by phone using Microsoft’s activation services.
**Configure KMS in Windows 10**
1. Open an elevated command prompt.
2. Enter one of the following commands.
- To install a KMS key, type **slmgr.vbs /ipk &lt;KmsKey&gt;**.
- To activate online, type **slmgr.vbs /ato**.
- To activate by using the telephone, type **slui.exe 4**.
3. After activating the KMS key, restart the Software Protection Service.
For more information, see the information for Windows 7 in [Deploy KMS Activation](http://go.microsoft.com/fwlink/p/?LinkId=717032).
## Key Management Service in Windows Server 2012 R2
Installing a KMS host key on a computer running Windows Server allows you to activate computers running Windows Server 2012 R2, Windows Sever 2008 R2, Windows Server 2008, Windows 10, Windows 8.1, Windows 7, and Windows Vista.
**Note**  
You cannot install a client KMS key into the KMS in Windows Server.
This scenario is commonly used in larger organizations that do not find the overhead of using a server a burden.
**Note**  
If you receive error 0xC004F015 when trying to activate Windows 10 Enterprise, see [KB 3086418](http://go.microsoft.com/fwlink/p/?LinkId=620687).
**Configure KMS in Windows Server 2012 R2**
1. Sign in to a computer running Windows Server 2012 R2 with an account that has local administrative credentials.
2. Launch Server Manager.
3. Add the Volume Activation Services role, as shown in Figure 4.
![Adding the Volume Activation Services role in Server Manager](images/volumeactivationforwindows81-04.jpg)
**Figure 4**. Adding the Volume Activation Services role in Server Manager
**Figure 4**. Adding the Volume Activation Services role in Server Manager\
4. When the role installation is complete, click the link to launch the Volume Activation Tools (Figure 5).
![Launching the Volume Activation Tools](images/volumeactivationforwindows81-05.jpg)
**Figure 5**. Launching the Volume Activation Tools
5. Select the **Key Management Service (KMS)** option, and specify the computer that will act as the KMS host (Figure 6).
5. Select the **Key Management Service (KMS)** option, and specify the computer that will act as the KMS host (Figure 6).
This can be the same computer on which you installed the role or another computer. For example, it can be a client computer running Windows 10.
![Configuring the computer as a KMS host](images/volumeactivationforwindows81-06.jpg)
**Figure 6**. Configuring the computer as a KMS host
6. Install your KMS host key by typing it in the text box, and then click **Commit** (Figure 7).
![Installing your KMS host key](images/volumeactivationforwindows81-07.jpg)
**Figure 7**. Installing your KMS host key
7. If asked to confirm replacement of an existing key, click **Yes**.
8. After the product key is installed, you must activate it. Click **Next** (Figure 8).
![Activating the software](images/volumeactivationforwindows81-08.jpg)
**Figure 8**. Activating the software
The KMS key can be activated online or by phone. See Figure 9.
![Choosing to activate online](images/volumeactivationforwindows81-09.jpg)
**Figure 9**. Choosing to activate online
The KMS key can be activated online or by phone. See Figure 9.
![Choosing to activate online](images/volumeactivationforwindows81-09.jpg)
**Figure 9**. Choosing to activate online
Now that the KMS host is configured, it will begin to listen for activation requests. However, it will not activate clients successfully until the activation threshold is met.
## Verifying the configuration of Key Management Service
You can verify KMS volume activation from the KMS host server or from the client computer. KMS volume activation requires a minimum threshold of 25 computers before activation requests will be processed. The verification process described here will increment the activation count each time a client computer contacts the KMS host, but unless the activation threshold is reached, the verification will take the form of an error message rather than a confirmation message.
**Note**  
If you configured Active Directory-based activation before configuring KMS activation, you must use a client computer that will not first try to activate itself by using Active Directory-based activation. You could use a workgroup computer that is not joined to a domain or a computer running Windows 7 or Windows Server 2008 R2.
To verify that KMS volume activation works, complete the following steps:
1. On the KMS host, open the event log and confirm that DNS publishing is successful.
2. On a client computer, open a Command Prompt window, type **Slmgr.vbs /ato**, and then press ENTER.<p>
The **/ato** command causes the operating system to attempt activation by using whichever key has been installed in the operating system. The response should show the license state and detailed Windows version information.
3. On a client computer or the KMS host, open an elevated Command Prompt window, type **Slmgr /dlv**, and then press ENTER.<p>
The **/dlv** command displays the detailed licensing information. The response should return an error that states that the KMS activation count is too low. This confirms that KMS is functioning correctly, even though the client has not been activated.
For more information about the use and syntax of slmgr.vbs, see [Slmgr.vbs Options](http://go.microsoft.com/fwlink/p/?LinkId=733639).
## Key Management Service in earlier versions of Windows
If you have already established a KMS infrastructure in your organization for an earlier version of Windows, you may want to continue using that infrastructure to activate computers running Windows 10 or Windows Server 2012 R2. Your existing KMS host must be running Windows 7 or later. To upgrade your KMS host, complete the following steps:
1. Download and install the correct update for your current KMS host operating system. Restart the computer as directed.
2. Request a new KMS host key from the Volume Licensing Service Center.
3. Install the new KMS host key on your KMS host.
4. Activate the new KMS host key by running the slmrg.vbs script.
For detailed instructions, see [Update that enables Windows 8.1 and Windows 8 KMS hosts to activate a later version of Windows](http://go.microsoft.com/fwlink/p/?LinkId=618265) and [Update that enables Windows 7 and Windows Server 2008 R2 KMS hosts to activate Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=626590).
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
 

47
windows/deploy/activate-windows-10-clients-vamt.md
View File

@ -2,14 +2,16 @@
title: Activate clients running Windows 10 (Windows 10)
description: After you have configured Key Management Service (KMS) or Active Directory-based activation on your network, activating a client running Windows 10 is easy.
ms.assetid: 39446e49-ad7c-48dc-9f18-f85a11ded643
ms.pagetype: activation
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Activate clients running Windows 10
**Applies to**
- Windows 10
- Windows 8.1
@ -18,61 +20,102 @@ author: jdeckerMS
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
After you have configured Key Management Service (KMS) or Active Directory-based activation on your network, activating a client running Windows 10 is easy. If the computer has been configured with a Generic Volume License Key (GVLK), neither IT nor the user need take any action. It just works.
Enterprise edition images and installation media should already be configured with the GVLK. When the client computer starts, the Licensing service examines the current licensing condition of the computer.
If activation or reactivation is required, the following sequence occurs:
1. If the computer is a member of a domain, it asks a domain controller for a volume activation object. If Active Directory-based activation is configured, the domain controller returns the object. If the object matches the edition of the software that is installed and the computer has a matching GVLK, the computer is activated (or reactivated), and it will not need to be activated again for 180 days, although the operating system will attempt reactivation at much shorter, regular intervals.
2. If the computer is not a member of a domain or if the volume activation object is not available, the computer will issue a DNS query to attempt to locate a KMS server. If a KMS server can be contacted, activation occurs if the KMS has a key that matches the computer’s GVLK.
3. The computer tries to activate against Microsoft servers if it is configured with a MAK.
If the client is not able to activate itself successfully, it will periodically try again. The frequency of the retry attempts depends on the current licensing state and whether the client computer has been successfully activated in the past. For example, if the client computer had been previously activated by Active Directory-based activation, it will periodically try to contact the domain controller at each restart.
## How Key Management Service works
KMS uses a client–server topology. KMS client computers can locate KMS host computers by using DNS or a static configuration. KMS clients contact the KMS host by using RPCs carried over TCP/IP.
### Key Management Service activation thresholds
You can activate physical computers and virtual machines by contacting a KMS host. To qualify for KMS activation, there must be a minimum number of qualifying computers (called the activation threshold). KMS clients will be activated only after this threshold has been met. Each KMS host counts the number of computers that have requested activation until the threshold is met.
A KMS host responds to each valid activation request from a KMS client with the count of how many computers have already contacted the KMS host for activation. Client computers that receive a count below the activation threshold are not activated. For example, if the first two computers that contact the KMS host are running Windows 10, the first receives an activation count of 1, and the second receives an activation count of 2. If the next computer is a virtual machine on a computer running Windows 10, it receives an activation count of 3, and so on. None of these computers will be activated, because computers running Windows 10, like other client operating system versions, must receive an activation count of 25 or more.
When KMS clients are waiting for the KMS to reach the activation threshold, they will connect to the KMS host every two hours to get the current activation count. They will be activated when the threshold is met.
In our example, if the next computer that contacts the KMS host is running Windows Server 2012 R2, it receives an activation count of 4, because activation counts are cumulative. If a computer running Windows Server 2012 R2 receives an activation count that is 5 or more, it is activated. If a computer running Windows 10 receives an activation count of 25 or more, it is activated.
### Activation count cache
To track the activation threshold, the KMS host keeps a record of the KMS clients that request activation. The KMS host gives each KMS client a client ID designation, and the KMS host saves each client ID in a table. By default, each activation request remains in the table for up to 30 days. When a client renews its activation, the cached client ID is removed from the table, a new record is created, and the 30day period begins again. If a KMS client computer does not renew its activation within 30 days, the KMS host removes the corresponding client ID from the table and reduces the activation count by one.
However, the KMS host only caches twice the number of client IDs that are required to meet the activation threshold. Therefore, only the 50 most recent client IDs are kept in the table, and a client ID could be removed much sooner than 30 days.
The total size of the cache is set by the type of client computer that is attempting to activate. If a KMS host receives activation requests only from servers, the cache will hold only 10 client IDs (twice the required 5). If a client computer running Windows 10 contacts that KMS host, KMS increases the cache size to 50 to accommodate the higher threshold. KMS never reduces the cache size.
### Key Management Service connectivity
KMS activation requires TCP/IP connectivity. By default, KMS hosts and clients use DNS to publish and find the KMS. The default settings can be used, which require little or no administrative action, or KMS hosts and client computers can be manually configured based on network configuration and security requirements.
### Key Management Service activation renewal
KMS activations are valid for 180 days (the *activation validity interval*). To remain activated, KMS client computers must renew their activation by connecting to the KMS host at least once every 180 days. By default, KMS client computers attempt to renew their activation every 7 days. If KMS activation fails, the client computer retries every two hours. After a client computer’s activation is renewed, the activation validity interval begins again.
### Publication of the Key Management Service
The KMS uses service (SRV) resource records in DNS to store and communicate the locations of KMS hosts. KMS hosts use the DNS dynamic update protocol, if available, to publish the KMS service (SRV) resource records. If dynamic update is not available or the KMS host does not have rights to publish the resource records, the DNS records must be published manually, or you must configure client computers to connect to specific KMS hosts.
### Client discovery of the Key Management Service
By default, KMS client computers query DNS for KMS information. The first time a KMS client computer queries DNS for KMS information, it randomly chooses a KMS host from the list of service (SRV) resource records that DNS returns. The address of a DNS server that contains the service (SRV) resource records can be listed as a suffixed entry on KMS client computers, which allows one DNS server to advertise the service (SRV) resource records for KMS, and KMS client computers with other primary DNS servers to find it.
Priority and weight parameters can be added to the DnsDomainPublishList registry value for KMS. Establishing KMS host priority groupings and weighting within each group allows you to specify which KMS host the client computers should try first and balances traffic among multiple KMS hosts. Only Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 provide these priority and weight parameters.
If the KMS host that a client computer selects does not respond, the KMS client computer removes that KMS host from its list of service (SRV) resource records and randomly selects another KMS host from the list. When a KMS host responds, the KMS client computer caches the name of the KMS host and uses it for subsequent activation and renewal attempts. If the cached KMS host does not respond on a subsequent renewal, the KMS client computer discovers a new KMS host by querying DNS for KMS service (SRV) resource records.
By default, client computers connect to the KMS host for activation by using anonymous RPCs through TCP port 1688. (You can change the default port.) After establishing a TCP session with the KMS host, the client computer sends a single request packet. The KMS host responds with the activation count. If the count meets or exceeds the activation threshold for that operating system, the client computer is activated and the session is closed. The KMS client computer uses this same process for renewal requests. 250 bytes are used for communication each way.
### Domain Name System server configuration
The default KMS automatic publishing feature requires the service (SRV) resource record and support for DNS dynamic update protocol. KMS client computer default behavior and the KMS service (SRV) resource record publishing are supported on a DNS server that is running Microsoft software or any other DNS server that supports service (SRV) resource records (per Internet Engineering Task Force \[IETF\] Request for Comments \[RFC\] 2782) and dynamic updates (per IETF RFC 2136). For example, Berkeley Internet Domain Name versions 8.x and 9.x support service (SRV) resource records and dynamic update.
The KMS host must be configured so that it has the credentials needed to create and update the following resource records on the DNS servers: service (SRV), IPv4 host (A), and IPv6 host (AAAA), or the records need to be created manually. The recommended solution for giving the KMS host the needed credentials is to create a security group in AD DS, then add all KMS hosts to that group. On a DNS server that is running Microsoft software, ensure that this security group is given full control over the \_VLMCS.\_TCP record in each DNS domain that will contain the KMS service (SRV) resource records.
### Activating the first Key Management Service host
KMS hosts on the network need to install a KMS key, and then be activated with Microsoft. Installation of a KMS key enables the KMS on the KMS host. After installing the KMS key, complete the activation of the KMS host by telephone or online. Beyond this initial activation, a KMS host does not communicate any information to Microsoft. KMS keys are only installed on KMS hosts, never on individual KMS client computers.
### Activating subsequent Key Management Service hosts
Each KMS key can be installed on up to six KMS hosts. These hosts can be physical computers or virtual machines. After activating a KMS host, the same host can be reactivated up to nine times with the same key. If the organization needs more than six KMS hosts, you can request additional activations for your organization’s KMS key by calling a Microsoft Volume [Licensing Activation Center](http://go.microsoft.com/fwlink/p/?LinkID=618264) to request an exception.
## How Multiple Activation Key works
A MAK is used for one-time activation with Microsoft’s hosted activation services. Each MAK has a predetermined number of allowed activations. This number is based on volume licensing agreements, and it might not match the organization’s exact license count. Each activation that uses a MAK with the Microsoft hosted activation service counts toward the activation limit.
You can activate computers by using a MAK in two ways:
- **MAK independent activation**. Each computer independently connects and is activated with Microsoft over the Internet or by telephone. MAK independent activation is best suited to computers within an organization that do not maintain a connection to the corporate network. MAK independent activation is shown in Figure 16.
![MAK independent activation](images/volumeactivationforwindows81-16.jpg)
**Figure 16**. MAK independent activation
- **MAK proxy activation**. MAK proxy activation enables a centralized activation request on behalf of multiple computers with one connection to Microsoft. You configure MAK proxy activation by using the VAMT. MAK proxy activation is appropriate for environments in which security concerns restrict direct access to the Internet or the corporate network. It is also suited for development and test labs that lack this connectivity. MAK proxy activation with the VAMT is shown in Figure 17.
![MAK proxy activation with the VAMT](images/volumeactivationforwindows81-17.jpg)
**Figure 17**. MAK proxy activation with the VAMT
A MAK is recommended for computers that rarely or never connect to the corporate network and for environments in which the number of computers that require activation does not meet the KMS activation threshold.
You can use a MAK for individual computers or with an image that can be duplicated or installed by using Microsoft deployment solutions. You can also use a MAK on a computer that was originally configured to use KMS activation. This is useful for moving a computer off the core network to a disconnected environment.
### Multiple Activation Key architecture and activation
MAK independent activation installs a MAK product key on a client computer. The key instructs that computer to activate itself with Microsoft servers over the Internet.
In MAK proxy activation, the VAMT installs a MAK product key on a client computer, obtains the installation ID from the target computer, sends the installation ID to Microsoft on behalf of the client, and obtains a confirmation ID. The tool then activates the client computer by installing the confirmation ID.
## Activating as a standard user
Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 do not require administrator privileges for activation, but this change does not allow standard user accounts to remove computers running Windows 7 or Windows Server 2008 R2 from the activated state. An administrator account is still required for other activation- or license-related tasks, such as “rearm.”
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
 
 

8
windows/deploy/active-directory-based-activation-overview.md
View File

@ -2,19 +2,25 @@
title: Active Directory-Based Activation Overview (Windows 10)
description: Active Directory-Based Activation Overview
ms.assetid: c1dac3bd-6a86-4c45-83dd-421e63a398c0
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: CFaw
---
# Active Directory-Based Activation Overview
Active Directory-Based Activation (ADBA) enables enterprises to activate computers through a connection to their domain. Many companies have computers at offsite locations that use products that are registered to the company. Previously these computers needed to either use a retail key or a Multiple Activation Key (MAK), or physically connect to the network in order to activate their products by using Key Management Services (KMS). ADBA provides a way to activate these products if the computers can join the company’s domain. When the user joins their computer to the domain, the ADBA object automatically activates Windows installed on their computer, as long as the computer has a Generic Volume License Key (GVLK) installed. No single physical computer is required to act as the activation object, because it is distributed throughout the domain.
## Active Directory-Based Activation Scenarios
VAMT enables IT Professionals to manage and activate the Active Directory-Based Activation object. Activation can be performed by using a scenario such as the following:
- Online activation: To activate an ADBA forest online, the user selects the **Online activate forest** function, selects a KMS Host key (CSVLK) to use, and gives the Active Directory-Based Activation Object a name.
- Proxy activation: For a proxy activation, the user first selects the **Proxy activate forest** function, selects a KMS Host key (CSVLK) to use, gives the Active Directory-Based Activation Object a name, and provides a file name to save the CILx file that contains the Installation ID. Next, the user takes that file to a computer that is running VAMT with an Internet connection and then selects the **Acquire confirmation IDs for CILX** function on the VAMT landing page, and provides the original CILx file. When VAMT has loaded the Confirmation IDs into the original CILx file, the user takes this file back to the original VAMT instance, where the user completes the proxy activation process by selecting the **Apply confirmation ID to Active Directory domain** function.
## Related topics
- [How to Activate an Active Directory Forest Online](http://go.microsoft.com/fwlink/p/?LinkId=246565)
- [How to Proxy Activate an Active Directory Forest](http://go.microsoft.com/fwlink/p/?LinkId=246566)
 

6
windows/deploy/add-manage-products-vamt.md
View File

@ -2,15 +2,19 @@
title: Add and Manage Products (Windows 10)
description: Add and Manage Products
ms.assetid: a48fbc23-917d-40f7-985c-e49702c05e51
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Add and Manage Products
This section describes how to add client computers into the Volume Activation Management Tool (VAMT). After the computers are added, you can manage the products that are installed on your network.
## In this Section
|Topic |Description |
|------|------------|
|[Add and Remove Computers](add-remove-computers-vamt.md) |Describes how to add client computers to VAMT. |

15
windows/deploy/add-remove-computers-vamt.md
View File

@ -2,16 +2,21 @@
title: Add and Remove Computers (Windows 10)
description: Add and Remove Computers
ms.assetid: cb6f3a78-ece0-4dc7-b086-cb003d82cd52
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: jdeckerMS
ms.pagetype: activation
---
# Add and Remove Computers
You can add computers that have any of the supported Windows or Office products installed to a Volume Activation Management Tool (VAMT) database by using the **Discover products** function. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general LDAP query. You can remove computers from a VAMT database by using the **Delete** function. After you add the computers, you can add the products that are installed on the computers by running the **Update license status** function.
Before adding computers, ensure that the Windows Management Instrumentation (WMI) firewall exception required by VAMT has been enabled on all target computers. For more information see [Configure Client Computers](configure-client-computers-vamt.md).
## To add computers to a VAMT database
1. Open VAMT.
2. Click **Discover products** in the **Actions** menu in the right-side pane to open the **Discover Products** dialog box.
3. In the **Discover products** dialog box, click **Search for computers in the Active Directory** to display the search options, then click the search option you want to use. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general LDAP query.
@ -22,11 +27,14 @@ Before adding computers, ensure that the Windows Management Instrumentation (WMI
4. Click **Search**.
5. VAMT searches for the specified computers and adds them to the VAMT database. During the search, VAMT displays the **Finding computers** message shown below.
To cancel the search, click **Cancel**. When the search is complete the names of the newly-discovered computers appear in the product list view in the center pane.
![VAMT, Finding computers dialog box](images/dep-win8-l-vamt-findingcomputerdialog.gif)
**Important**  
This step adds only the computers to the VAMT database, and not the products that are installed on the computers. To add the products, you need to run the **Update license status** function.
## To add products to VAMT
1. In the **Products** list, select the computers that need to have their product information added to the VAMT database.
2. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
3. In the **Filter Products** dialog box, you can filter the list by computer name, product name, product key type, license status, or by any combination of these options.
@ -35,11 +43,16 @@ Before adding computers, ensure that the Windows Management Instrumentation (WMI
4. Click **Filter**. VAMT displays the filtered list in the center pane.
5. In the right-side **Actions** pane, click **Update license status** and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials different from the ones you used to log into the computer. If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and click **OK**.
6. VAMT displays the **Collecting product information** dialog box while it collects the licensing status of all supported products on the selected computers. When the process is finished, the updated licensing status of each product will appear in the product list view in the center pane.
**Note**  
If a computer has more than one supported product installed, VAMT adds an entry for each product. The entry appears under the appropriate product heading.
## To remove computers from a VAMT database
You can delete a computer by clicking on it in the product list view, and then clicking **Delete** in the **Selected Item** menu in the right-hand pane. In the **Confirm Delete Selected Products** dialog box that appears, click **Yes** to delete the computer. If a computer has multiple products listed, you must delete each product to completely remove the computer from the VAMT database.
## Related topics
- [Add and Manage Products](add-manage-products-vamt.md)
 
 

11
windows/deploy/add-remove-product-key-vamt.md
View File

@ -2,24 +2,33 @@
title: Add and Remove a Product Key (Windows 10)
description: Add and Remove a Product Key
ms.assetid: feac32bb-fb96-4802-81b8-c69220dcfcce
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Add and Remove a Product Key
Before you can use a Multiple Activation Key (MAK), retail, or KMS Host key (CSVLK) product key, you must first add it to the Volume Activation Management Tool (VAMT) database.
## To Add a Product Key
1. Open VAMT.
2. In the left-side pane, right-click the **Product Keys** node to open the **Actions** menu.
3. Click **Add product keys** to open the **Add Product Keys** dialog box.
4. In the **Add Product Keys** dialog box, select from one of the following methods to add product keys:
- To add product keys manually, click **Enter product key(s) separated by line breaks**, enter one or more product keys separated by line breaks, and click **Add Key(s)**.
- To import a Comma Separated Values (CSV) file containing a list of product keys, click **Select a product key file to import**, browse to the file location, click **Open** to import the file, and then click **Add Key(s)**.
**Note**  
If you are activating a large number of products with a MAK, you should refresh the activation count of the MAK, to ensure that the MAK can support the required number of activations. In the product key list in the center pane, select the MAK and click **Refresh product key data online** in the right-side pane to contact Microsoft and retrieve the number of remaining activations for the MAK. This step requires Internet access. You can only retrieve the remaining activation count for MAKs.
## Remove a Product Key
- To remove a product key from the list, simply select the key in the list and click **Delete** on the **Selected Items** menu in the right-side pane. Click **Yes** to confirm deletion of the product key. Removing a product key from the VAMT database will not affect the activation state of any products or computers on the network.
## Related topics
- [Manage Product Keys](manage-product-keys-vamt.md)

17
windows/deploy/appendix-information-sent-to-microsoft-during-activation-client.md
View File

@ -1,12 +1,12 @@
---
title: Appendix Information sent to Microsoft during activation (Windows 10)
ms.assetid: 4bfff495-07d0-4385-86e3-7a077cbd64b8
ms.pagetype: activation
description:
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Appendix: Information sent to Microsoft during activation
@ -18,12 +18,18 @@ author: jdeckerMS
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
When you activate a computer running Windows 10, the following information is sent to Microsoft:
- The Microsoft product code (a five-digit code that identifies the Windows product you are activating)
- A channel ID or site code that identifies how the Windows product was originally obtained
For example, a channel ID or site code identifies whether the product was originally purchased from a retail store, obtained as an evaluation copy, obtained through a volume licensing program, or preinstalled by a computer manufacturer.
- The date of installation and whether the installation was successful
- Information that helps confirm that your Windows product key has not been altered
- Computer make and model
@ -34,18 +40,25 @@ When you activate a computer running Windows 10, the following information is s
- BIOS name, revision number, and revision date
- Volume serial number (hashed) of the hard disk drive
- The result of the activation check
This includes error codes and the following information about any activation exploits and related malicious or unauthorized software that was found or disabled:
- The activation exploit’s identifier
- The activation exploit’s current state, such as cleaned or quarantined
- Computer manufacturer’s identification
- The activation exploit’s file name and hash in addition to a hash of related software components that may indicate the presence of an activation exploit
- The name and a hash of the contents of your computer’s startup instructions file
- If your Windows license is on a subscription basis, information about how your subscription works
Standard computer information is also sent, but your computer’s IP address is only retained temporarily.
## Use of information
Microsoft uses the information to confirm that you have a licensed copy of the software. Microsoft does not use the information to contact individual consumers.
For additional details, see [Windows 10 Privacy Statement](http://go.microsoft.com/fwlink/p/?LinkId=619879).
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
 
 

24
windows/deploy/assign-applications-using-roles-in-mdt-2013.md
View File

@ -2,34 +2,47 @@
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.pagetype: mdt
keywords: ["settings, database, deploy"]
keywords: settings, database, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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
@ -92,14 +105,21 @@ When the database is populated, you can use the MDT simulation environment to si
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-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)

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

@ -2,43 +2,63 @@
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.pagetype: mdt
keywords: ["replication, replicate, deploy, configure, remote"]
keywords: replication, replicate, deploy, configure, remote
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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) 2013 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 2013 Update 2
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**.
@ -47,14 +67,20 @@ Setting up DFS-R for replication is a quick and straightforward process. You pre
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
@ -75,12 +101,18 @@ When you have multiple deployment servers sharing the same content, you need to
 
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.
@ -89,16 +121,22 @@ Once the MDT01 and MDT02 servers are prepared, you are ready to configure the ac
2. On the **Replication Group Type** page, select **Multipurpose replication group**, and click **Next**.
3. On the **Name and Domain** page, assign the **MDTProduction** name, and click **Next**.
4. 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.
5. On the **Topology Selection** page, select the **Full mesh** option and click **Next**.
6. On the **Replication Group Schedule and Bandwidth** page, accept the default settings and click **Next**.
7. On the **Primary Member** page, select **MDT01** and click **Next**.
8. On the **Folders to Replicate** page, click **Add**, type in **E:\\MDTProduction** as the folder to replicate, click **OK**, and then click **Next**.
9. On the **Local Path of MDTProduction** on the **Other Members** page, select **MDT02**, and click **Edit**.
10. 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.
11. On the **Review Settings and Create Replication Group** page, click **Create**.
12. On the **Confirmation** page, click **Close**.
### Configure replicated folders
@ -111,12 +149,16 @@ Once the MDT01 and MDT02 servers are prepared, you are ready to configure the ac
``` 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.
4. In the middle pane, right-click the **MDT02** member and select **Properties**.
5. 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.
 
@ -129,14 +171,21 @@ It will take some time for the replication configuration to be picked up by the
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
@ -154,12 +203,20 @@ Now you should have a solution ready for deploying the Windows 10 client to the
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 2013 Update 2](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-2013-settings.md)
 
 

24
windows/deploy/configure-client-computers-vamt.md
View File

@ -2,20 +2,27 @@
title: Configure Client Computers (Windows 10)
description: Configure Client Computers
ms.assetid: a48176c9-b05c-4dd5-a9ef-83073e2370fc
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Configure Client Computers
To enable the Volume Activation Management Tool (VAMT) to function correctly, certain configuration changes are required on all client computers:
- An exception must be set in the client computer's firewall.
- A registry key must be created and set properly, for computers in a workgroup; otherwise, Windows® User Account Control (UAC) will not allow remote administrative operations.
Organizations where the VAMT will be widely used may benefit from making these changes inside the master image for Windows.
**Important**  
This procedure only applies to clients running Windows Vista or later. For clients running Windows XP Service Pack 1, see [Connecting Through Windows Firewall](http://go.microsoft.com/fwlink/p/?LinkId=182933).
## Configuring the Windows Firewall to allow VAMT access
Enable the VAMT to access client computers using the **Windows Firewall** Control Panel:
1. Open Control Panel and double-click **System and Security**.
2. Click **Windows Firewall**.
@ -23,17 +30,23 @@ Enable the VAMT to access client computers using the **Windows Firewall** Contro
4. Click the **Change settings** option.
5. Select the **Windows Management Instrumentation (WMI)** checkbox.
6. Click **OK**.
**Warning**  
By default, Windows Firewall Exceptions only apply to traffic originating on the local subnet. To expand the exception to apply to multiple subnets, you need to change the exception settings in the Windows Firewall with Advanced Security, as described below.
## Configure Windows Firewall to allow VAMT access across multiple subnets
Enable the VAMT to access client computers across multiple subnets using the **Windows Firewall with Advanced Security** Control Panel:
![VAMT Firewall configuration for multiple subnets](images/dep-win8-l-vamt-firewallconfigurationformultiplesubnets.gif)
1. Open the Control Panel and double-click **Administrative Tools**.
2. Click **Windows Firewall with Advanced Security**.
3. Make your changes for each of the following three WMI items, for the applicable Network Profile (Domain, Public, Private):
- Windows Management Instrumentation (ASync-In)
- Windows Management Instrumentation (DCOM-In)
- Windows Management Instrumentation (WMI-In)
4. In the **Windows Firewall with Advanced Security** dialog box, select **Inbound Rules** from the left-hand panel.
5. Right-click the desired rule and select **Properties** to open the **Properties** dialog box.
@ -41,12 +54,17 @@ Enable the VAMT to access client computers across multiple subnets using the **W
- On the **General** tab, select the **Allow the connection** checkbox.
- On the **Scope** tab, change the Remote IP Address setting from "Local Subnet" (default) to allow the specific access you need.
- On the **Advanced** tab, verify selection of all profiles that are applicable to the network (Domain or Private/Public).
In certain scenarios, only a limited set of TCP/IP ports are allowed through a hardware firewall. Administrators must ensure that WMI (which relies on RPC over TCP/IP) is allowed through these types of firewalls. By default, the WMI port is a dynamically allocated random port above 1024. The following Microsoft knowledge article discusses how administrators can limit the range of dynamically-allocated ports. This is useful if, for example, the hardware firewall only allows traffic in a certain range of ports.
For more info, see [How to configure RPC dynamic port allocation to work with firewalls](http://go.microsoft.com/fwlink/p/?LinkId=182911).
## Create a registry value for the VAMT to access workgroup-joined computer
**Caution**  
This section contains information about how to modify the registry. Make sure to back up the registry before you modify it; in addition, ensure that you know how to restore the registry, if a problem occurs. For more information about how to back up, restore, and modify the registry, see [Windows registry information for advanced users](http://go.microsoft.com/fwlink/p/?LinkId=182912).
On the client computer, create the following registry key using regedit.exe.
1. Navigate to `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system`
2. Enter the following details:
**Value Name: LocalAccountTokenFilterPolicy**
@ -54,14 +72,18 @@ On the client computer, create the following registry key using regedit.exe.
**Value Data: 1**
**Note**  
To discover VAMT-manageable Windows computers in workgroups, you must enable network discovery on each client.
## Deployment options
There are several options for organizations to configure the WMI firewall exception for computers:
- **Image.** Add the configurations to the master Windows image deployed to all clients.
- **Group Policy.** If the clients are part of a domain, then all clients can be configured using Group Policy. The Group Policy setting for the WMI firewall exception is found in GPMC.MSC at: **Computer Configuration\\Windows Settings\\Security Settings\\Windows Firewall with Advanced Security\\Windows Firewall with Advanced Security\\Inbound Rules**.
- **Script.** Execute a script using Microsoft System Center Configuration Manager or a third-party remote script execution facility.
- **Manual.** Configure the WMI firewall exception individually on each client.
The above configurations will open an additional port through the Windows Firewall on target computers and should be performed on computers that are protected by a network firewall. In order to allow VAMT to query the up-to-date licensing status, the WMI exception must be maintained. We recommend administrators consult their network security policies and make clear decisions when creating the WMI exception.
## Related topics
- [Install and Configure VAMT](install-configure-vamt.md)
 
 

23
windows/deploy/configure-mdt-2013-for-userexit-scripts.md
View File

@ -2,17 +2,22 @@
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.pagetype: mdt
keywords: ["rules, script"]
keywords: rules, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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
@ -21,9 +26,13 @@ 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
@ -38,16 +47,22 @@ Function SetName(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-2013-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-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
 
 

19
windows/deploy/configure-mdt-2013-settings.md
View File

@ -2,19 +2,25 @@
title: Configure MDT settings (Windows 10)
description: One of the most powerful features in Microsoft Deployment Toolkit (MDT) 2013 is its extension capabilities; there is virtually no limitation to what you can do in terms of customization.
ms.assetid: d3e1280c-3d1b-4fad-8ac4-b65dc711f122
ms.pagetype: mdt
keywords: ["customize, customization, deploy, features, tools"]
keywords: customize, customization, deploy, features, tools
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Configure MDT settings
One of the most powerful features in Microsoft Deployment Toolkit (MDT) 2013 is its extension capabilities; there is virtually no limitation to what you can do in terms of customization. In this topic, you learn about configuring customizations for your environment.
For the purposes of this topic, we will use four machines: DC01, MDT01, HV01, and PC0001. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 Standard server, and PC0001 is a Windows 10 Enterprise x64 client used for the MDT simulation environment. OR01 has Microsoft System Center 2012 R2 Orchestrator installed. MDT01, OR01, and PC0001 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-09-fig01.png)
Figure 1. The machines used in this topic.
## In this section
- [Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
- [Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
- [Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
@ -23,12 +29,17 @@ Figure 1. The machines used in this topic.
- [Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
- [Use web services in MDT](use-web-services-in-mdt-2013.md)
- [Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
## 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 2013 Update 2](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)
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
 
 

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

@ -2,25 +2,35 @@
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.pagetype: mdt
keywords: ["rules, configuration, automate, deploy"]
keywords: rules, configuration, automate, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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
@ -29,9 +39,13 @@ 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
@ -40,9 +54,13 @@ 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
@ -50,12 +68,16 @@ Priority=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
@ -63,9 +85,13 @@ Priority=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
@ -76,13 +102,19 @@ Subsection=Laptop-%IsLaptop%
[Laptop-True]
MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com
```
## Related topics
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-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-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
 
 

137
windows/deploy/create-a-windows-10-reference-image.md
View File

@ -2,32 +2,43 @@
title: Create a Windows 10 reference image (Windows 10)
description: Creating a reference image is important because that image serves as the foundation for the devices in your organization.
ms.assetid: 9da2fb57-f2ff-4fce-a858-4ae4c237b5aa
ms.pagetype: mdt
keywords: ["deploy, deployment, configure, customize, install, installation"]
keywords: deploy, deployment, configure, customize, install, installation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Create a Windows 10 reference image
**Applies to**
- Windows 10
Creating a reference image is important because that image serves as the foundation for the devices in your organization. In this topic, you will learn how to create a Windows 10 reference image using the Microsoft Deployment Toolkit (MDT) 2013 Update 2. You will create a deployment share, configure rules and settings, and import all the applications and operating system files required to build a Windows 10 reference image. After completing the steps outlined in this topic, you will have a Windows 10 reference image that can be used in your deployment solution.
For the purposes of this topic, we will use four machines: DC01, MDT01, HV01, and PC0001. DC01 is a domain controller, PC0001 is a Windows 10 Enterprise x64 client, and MDT01 is a Windows Server 2012 R2 standard server. HV01 is a Hyper-V host server, but HV01 could be replaced by PC0001 as long as PC0001 has enough memory and is capable of running Hyper-V. MDT01, HV01, and PC0001 are members of the domain contoso.com for the fictitious Contoso Corporation.
**Note**  
For important details about the setup for the steps outlined in this article, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md#proof).
 
![figure 1](images/mdt-08-fig01.png)
Figure 1. The machines used in this topic.
## The reference image
The reference image described in this documentation is designed primarily for deployment to physical machines. However, the reference image is created on a virtual platform, before being automatically run through the System Preparation (Sysprep) tool process and captured to a Windows Imaging (WIM) file. The reasons for creating the reference image on a virtual platform are the following:
- You reduce development time and can use snapshots to test different configurations quickly.
- You rule out hardware issues. You simply get the best possible image, and if you have a problem, it's not likely to be hardware related.
- It ensures that you won't have unwanted applications that could be installed as part of a driver install but not removed by the Sysprep process.
- It's easy to move between lab, test, and production.
## <a href="" id="sec01"></a>Set up the MDT build lab deployment share
With Windows 10, there is no hard requirement to create reference images; however, to reduce the time needed for deployment, you may want to create a reference image that contains a few base applications as well as all of the latest updates. This section will show you how to create and configure the MDT Build Lab deployment share to create a Windows 10 reference image. Because reference images will be deployed only to virtual machines during the creation process and have specific settings (rules), you should always create a separate deployment share specifically for this process.
### Create the MDT build lab deployment share
- On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd**.
- Using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**.
- Use the following settings for the New Deployment Share Wizard:
@ -36,26 +47,40 @@ With Windows 10, there is no hard requirement to create reference images; howev
- Deployment share description: MDT Build Lab
- &lt;default&gt;
- Verify that you can access the \\\\MDT01\\MDTBuildLab$ share.
![figure 2](images/mdt-08-fig02.png)
Figure 2. The Deployment Workbench with the MDT Build Lab deployment share created.
### Configure permissions for the deployment share
In order to write the reference image back to the deployment share, you need to assign Modify permissions to the MDT Build Account (MDT\_BA) for the **Captures** subfolder in the **E:\\MDTBuildLab** folder
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Modify the NTFS permissions for the **E:\\MDTBuildLab\\Captures** folder by running the following command in an elevated Windows PowerShell prompt:
``` syntax
icacls E:\MDTBuildLab\Captures /grant '"MDT_BA":(OI)(CI)(M)'
```
![figure 3](images/mdt-08-fig03.png)
Figure 3. Permissions configured for the MDT\_BA user.
## <a href="" id="sec02"></a>Add the setup files
This section will show you how to populate the MDT 2013 Update 2 deployment share with the Windows 10 operating system source files, commonly referred to as setup files, which will be used to create a reference image. Setup files are used during the reference image creation process and are the foundation for the reference image.
### Add the Windows 10 installation files
MDT 2013 supports adding both full source Windows 10 DVDs (ISOs) and custom images that you have created. In this case, you create a reference image, so you add the full source setup files from Microsoft.
**Note**  
Due to the Windows limits on path length, we are purposely keeping the operating system destination directory short, using the folder name W10EX64RTM rather than a more descriptive name like Windows 10 Enterprise x64 RTM.
 
### Add Windows 10 Enterprise x64 (full source)
In these steps we assume that you have copied the content of a Windows 10 Enterprise x64 ISO to the **E:\\Downloads\\Windows 10 Enterprise x64** folder.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Build Lab**.
3. Right-click the **Operating Systems** node, and create a new folder named **Windows 10**.
@ -64,12 +89,18 @@ In these steps we assume that you have copied the content of a Windows 10 Enter
6. Source directory: E:\\Downloads\\Windows 10 Enterprise x64
7. Destination directory name: W10EX64RTM
8. After adding the operating system, in the **Operating Systems / Windows 10** folder, double-click the added operating system name in the **Operating System** node and change the name to the following: **Windows 10 Enterprise x64 RTM Default Image**
![figure 4](images/figure4-deployment-workbench.png)
Figure 4. The imported Windows 10 operating system after renaming it.
## <a href="" id="sec03"></a>Add applications
Before you create an MDT task sequence, you need to add all of the applications and other sample scripts to the MDT Build Lab share.
The steps in this section use a strict naming standard for your MDT applications. You add the "Install - " prefix for typical application installations that run a setup installer of some kind, and you use the "Configure - " prefix when an application configures a setting in the operating system. You also add an " - x86", " - x64", or "- x86-x64" suffix to indicate the application's architecture (some applications have installers for both architectures). Using a script naming standard is always recommended when using MDT as it helps maintain order and consistency.
By storing configuration items as MDT applications, it is easy to move these objects between various solutions, or between test and production environments. In this topic's step-by-step sections, you will add the following applications:
- Install - Microsoft Office 2013 Pro Plus - x86
- Install - Microsoft Silverlight 5.0 - x64
- Install - Microsoft Visual C++ 2005 SP1 - x86
@ -80,19 +111,27 @@ By storing configuration items as MDT applications, it is easy to move these obj
- Install - Microsoft Visual C++ 2010 SP1 - x64
- Install - Microsoft Visual C++ 2012 Update 4 - x86
- Install - Microsoft Visual C++ 2012 Update 4 - x64
In these examples, we assume that you downloaded the software in this list to the E:\\Downloads folder. The first application is added using the UI, but because MDT supports Windows PowerShell, you add the other applications using Windows PowerShell.
**Note**  
All the Microsoft Visual C++ downloads can be found on [The latest supported Visual C++ downloads](http://go.microsoft.com/fwlink/p/?LinkId=619523).
 
### Create the install: Microsoft Office Professional Plus 2013 x86
You can customize Office 2013. In the volume license versions of Office 2013, there is an Office Customization Tool you can use to customize the Office installation. In these steps we assume you have copied the Office 2013 installation files to the E:\\Downloads\\Office2013 folder.
### Add the Microsoft Office Professional Plus 2013 x86 installation files
After adding the Microsoft Office Professional Plus 2013 x86 application, you then automate its setup by running the Office Customization Tool. In fact, MDT 2013 detects that you added the Office Professional Plus 2013 x86 application and creates a shortcut for doing this.
You also can customize the Office installation using a Config.xml file. But we recommend that you use the Office Customization Tool as described in the following steps, as it provides a much richer way of controlling Office 2013 settings.
1. Using the Deployment Workbench in the MDT Build Lab deployment share, expand the **Applications / Microsoft** node, and double-click **Install - Microsoft Office 2013 Pro Plus x86**.
2. In the **Office Products** tab, click **Office Customization Tool**, and click **OK** in the **Information** dialog box.
![figure 5](images/mdt-08-fig05.png)
Figure 5. The Install - Microsoft Office 2013 Pro Plus - x86 application properties.
**Note**  
If you don't see the Office Products tab, verify that you are using a volume license version of Office. If you are deploying Office 365, you need to download the Admin folder from Microsoft.
 
@ -104,18 +143,24 @@ You also can customize the Office installation using a Config.xml file. But we r
1. Select Use KMS client key
2. Select I accept the terms in the License Agreement.
3. Select Display level: None
![figure 6](images/mdt-08-fig06.png)
Figure 6. The licensing and user interface screen in the Microsoft Office Customization Tool
3. Modify Setup properties
- Add the **SETUP\_REBOOT** property and set the value to **Never**.
4. Modify user settings
- In the **Microsoft Office 2013** node, expand **Privacy**, select **Trust Center**, and enable the Disable Opt-in Wizard on first run setting.
5. From the **File** menu, select **Save**, and save the configuration as 0\_Office2013ProPlusx86.msp in the **E:\\MDTBuildLab\\Applications\\Install - Microsoft Office 2013 Pro Plus - x86\\Updates** folder.
**Note**  
The reason for naming the file with a 0 (zero) at the beginning is that the Updates folder also handles Microsoft Office updates, and they are installed in alphabetical order. The Office 2013 setup works best if the customization file is installed before any updates.
 
6. Close the Office Customization Tool, click Yes in the dialog box, and in the **Install - Microsoft Office 2013 Pro Plus - x86 Properties** window, click **OK**.
### Connect to the deployment share using Windows PowerShell
If you need to add many applications, you can take advantage of the PowerShell support that MDT has. To start using PowerShell against the deployment share, you must first load the MDT PowerShell snap-in and then make the deployment share a PowerShell drive (PSDrive).
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Import the snap-in and create the PSDrive by running the following commands in an elevated PowerShell prompt:
@ -123,7 +168,9 @@ If you need to add many applications, you can take advantage of the PowerShell s
Import-Topic "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "E:\MDTBuildLab"
```
### Create the install: Microsoft Visual C++ 2005 SP1 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2005SP1x86.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -134,7 +181,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -Commandline $Commandline -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2005 SP1 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2005SP1x64.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -145,7 +194,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -Commandline $Commandline -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2008 SP1 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2008SP1x86.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -156,7 +207,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -Commandline $Commandline -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2008 SP1 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2008SP1x64.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -167,7 +220,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2008 SP1
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -Commandline $Commandline -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2010 SP1 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2010SP1x86.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -178,7 +233,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2010 SP1 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2010SP1x64.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -189,7 +246,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2010 SP1
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2012 Update 4 x86
In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Update 4 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2012Ux86.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -200,7 +259,9 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Upda
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
### Create the install: Microsoft Visual C++ 2012 Update 4 x64
In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Update 4 x64. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2012Ux64.
1. On MDT01, log on as **CONTOSO\\Administrator**.
2. Create the application by running the following commands in an elevated PowerShell prompt:
@ -211,13 +272,20 @@ In these steps we assume that you have downloaded Microsoft Visual C++ 2012 Upda
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory ".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder $ApplicationName
-Verbose
```
## <a href="" id="sec04"></a>Create the reference image task sequence
In order to build and capture your Windows 10 reference image for deployment using MDT, you will create a task sequence. The task sequence will reference the operating system and applications that you previously imported into the MDT Build Lab deployment share to build a Windows 10 reference image.
After creating the task sequence, you configure it to enable patching against the Windows Server Update Services (WSUS) server. The Task Sequence Windows Update action supports getting updates directly from Microsoft Update, but you get more stable patching if you use a local WSUS server. WSUS also allows for an easy process of approving the patches that you are deploying.
### Drivers and the reference image
Because we use modern virtual platforms for creating our reference images, we don’t need to worry about drivers when creating reference images for Windows 10. We use Hyper-V in our environment, and Windows Preinstallation Environment (Windows PE) already has all the needed drivers built-in for Hyper-V.
### Create a task sequence for Windows 10 Enterprise
To create a Windows 10 reference image task sequence, the process is as follows:
1. Using the Deployment Workbench in the MDT Build Lab deployment share, right-click **Task Sequences**, and create a new folder named **Windows 10**.
2. Expand the **Task Sequences** node, right-click the new **Windows 10** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
1. Task sequence ID: REFW10X64-001
@ -230,8 +298,11 @@ To create a Windows 10 reference image task sequence, the process is as follows
8. Organization: Contoso
9. Internet Explorer home page: http://www.contoso.com
10. Admin Password: Do not specify an Administrator Password at this time
### Edit the Windows 10 task sequence
The steps below walk you through the process of editing the Windows 10 reference image task sequence to include the actions required to update the reference image with the latest updates from WSUS, install roles and features, and utilities, and install Microsoft Office 2013.
1. In the Task Sequences / Windows 10 folder, right-click the Windows 10 Enterprise x64 RTM Default Image task sequence, and select Properties.
2. On the **Task Sequence** tab, configure the Windows 10 Enterprise x64 RTM Default Image task sequence with the following settings:
1. State Restore. Enable the Windows Update (Pre-Application Installation) action.
@ -249,11 +320,14 @@ The steps below walk you through the process of editing the Windows 10 referenc
1. Name: Install - Microsoft NET Framework 3.5.1
2. Select the operating system for which roles are to be installed: Windows 8.1
3. Select the roles and features that should be installed: .NET Framework 3.5 (includes .NET 2.0 and 3.0)
**Important**  
This is probably the most important step when creating a reference image. Many applications need the .NET Framework, and we strongly recommend having it available in the image. The one thing that makes this different from other components is that .NET Framework 3.5.1 is not included in the WIM file. It is installed from the **Sources\\SxS** folder on the media, and that makes it more difficult to add after the image has been deployed.
 
![figure 7](images/fig8-cust-tasks.png)
Figure 7. The task sequence after creating the Custom Tasks (Pre-Windows Update) group and adding the Install - Microsoft NET Framework 3.5.1 action.
6. State Restore - Custom Tasks (Pre-Windows Update). After the **Install - Microsoft NET Framework 3.5.1** action, add a new **Install Application** action with the following settings:
1. Name: Install - Microsoft Visual C++ 2005 SP1 - x86
2. Install a Single Application: Install - Microsoft Visual C++ 2005 SP1 - x86-x64
@ -268,18 +342,29 @@ The steps below walk you through the process of editing the Windows 10 referenc
8. Install - Microsoft Office 2013 Pro Plus - x86
8. After the Install - Microsoft Office 2013 Pro Plus - x86 action, add a new Restart computer action.
3. Click **OK**.
### Optional configuration: Add a suspend action
The goal when creating a reference image is of course to automate everything. But sometimes you have a special configuration or application setup that is too time-consuming to automate. If you need to do some manual configuration, you can add a little-known feature called Lite Touch Installation (LTI) Suspend. If you add the LTISuspend.wsf script as a custom action in the task sequence, it will suspend the task sequence until you click the Resume Task Sequence shortcut icon on the desktop. In addition to using the LTI Suspend feature for manual configuration or installation, you can also use it simply for verifying a reference image before you allow the task sequence to continue and use Sysprep and capture the virtual machine.
![figure 8](images/fig8-suspend.png)
Figure 8. A task sequence with optional Suspend action (LTISuspend.wsf) added.
![figure 9](images/fig9-resumetaskseq.png)
Figure 9. The Windows 10 desktop with the Resume Task Sequence shortcut.
### Edit the Unattend.xml file for Windows 10 Enterprise
When using MDT, you don't need to edit the Unattend.xml file very often because most configurations are taken care of by MDT. However if, for example, you want to configure Internet Explorer 11 behavior, then you can edit the Unattend.xml for this. Editing the Unattend.xml for basic Internet Explorer settings is easy, but for more advanced settings, you will want to use Internet Explorer Administration Kit (IEAK).
**Note**  
You also can use the Unattend.xml to enable components in Windows 10, like the Telnet Client or Hyper-V client. Normally we prefer to do this via the Install Roles and Features action, or using Deployment Image Servicing and Management (DISM) command-line tools, because then we can add that as an application, being dynamic, having conditions, and so forth. Also, if you are adding packages via Unattend.xml, it is version specific, so Unattend.xml must match the exact version of the operating system you are servicing.
 
Follow these steps to configure Internet Explorer settings in Unattend.xml for the Windows 10 Enterprise x64 RTM Default Image task sequence:
1. Using the Deployment Workbench, right-click the **Windows 10 Enterprise x64 RTM Default Image** task sequence and select **Properties**.
2. In the **OS Info** tab, click **Edit Unattend.xml**. MDT now generates a catalog file. This will take a few minutes, and then Windows System Image Manager (Windows SIM) will start.
3. In Windows SIM, expand the **4 specialize** node in the **Answer File** pane and select the amd64\_Microsoft-Windows-IE-InternetExplorer\_neutral entry.
@ -287,11 +372,17 @@ Follow these steps to configure Internet Explorer settings in Unattend.xml for t
- DisableDevTools: true
5. Save the Unattend.xml file, and close Windows SIM.
6. On the Windows 10 Enterprise x64 RTM Default Image Properties, click **OK**.
![figure 10](images/fig10-unattend.png)
Figure 10. Windows System Image Manager with the Windows 10 Unattend.xml.
## <a href="" id="sec05"></a>Configure the MDT deployment share rules
Understanding rules is critical to successfully using MDT. Rules are configured using the Rules tab of the deployment share's properties. The Rules tab is essentially a shortcut to edit the CustomSettings.ini file that exists in the E:\\MDTBuildLab\\Control folder. This section discusses how to configure the MDT deployment share rules as part of your Windows 10 Enterprise deployment.
### MDT deployment share rules overview
In MDT, there are always two rule files: the CustomSettings.ini file and the Bootstrap.ini file. You can add almost any rule to either; however, the Bootstrap.ini file is copied from the Control folder to the boot image, so the boot image needs to be updated every time you change that file.
For that reason, add only a minimal set of rules to Bootstrap.ini, such as which deployment server and share to connect to - the DEPLOYROOT value. Put the other rules in CustomSettings.ini because that file is updated immediately when you click OK. By taking the following steps, you will configure the rules for the MDT Build Lab deployment share:
1. Using the Deployment Workbench, right-click the **MDT Build Lab deployment share** and select **Properties**.
@ -328,9 +419,13 @@ For that reason, add only a minimal set of rules to Bootstrap.ini, such as which
SkipCapture=NO
SkipFinalSummary=YES
```
![figure 11](images/mdt-08-fig14.png)
Figure 11. The server-side rules for the MDT Build Lab deployment share.
3. Click **Edit Bootstrap.ini** and modify using the following information:
``` syntax
Settings]
Priority=Default
@ -341,8 +436,11 @@ For that reason, add only a minimal set of rules to Bootstrap.ini, such as which
UserPassword=P@ssw0rd
SkipBDDWelcome=YES
```
![figure 12](images/mdt-08-fig15.png)
Figure 12. The boot image rules for the MDT Build Lab deployment share.
**Note**  
For security reasons, you normally don't add the password to the Bootstrap.ini file; however, because this deployment share is for creating reference image builds only, and should not be published to the production network, it is acceptable to do so in this situation.
 
@ -355,25 +453,36 @@ For that reason, add only a minimal set of rules to Bootstrap.ini, such as which
1. Image description: MDT Build Lab x64
2. ISO file name: MDT Build Lab x64.iso
8. Click **OK**.
**Note**  
In MDT, the x86 boot image can deploy both x86 and x64 operating systems (except on computers based on Unified Extensible Firmware Interface).
 
### Update the deployment share
After the deployment share has been configured, it needs to be updated. This is the process when the Windows Windows PE boot images are created.
1. Using the Deployment Workbench, right-click the **MDT Build Lab deployment share** and select **Update Deployment Share**.
2. Use the default options for the Update Deployment Share Wizard.
**Note**  
The update process will take 5 to 10 minutes.
 
### The rules explained
Now that the MDT Build Lab deployment share (the share used to create the reference images) has been configured, it is time to explain the various settings used in the Bootstrap.ini and CustomSettings.ini files.
The Bootstrap.ini and CustomSettings.ini files work together. The Bootstrap.ini file is always present on the boot image and is read first. The basic purpose for Bootstrap.ini is to provide just enough information for MDT to find the CustomSettings.ini.
The CustomSettings.ini file is normally stored on the server, in the Deployment share\\Control folder, but also can be stored on the media (when using offline media).
**Note**  
The settings, or properties, that are used in the rules (CustomSettings.ini and Bootstrap.ini) are listed in the MDT documentation, in the Microsoft Deployment Toolkit Reference / Properties / Property Definition section.
 
### The Bootstrap.ini file
The Bootstrap.ini file is available via the deployment share's Properties dialog box, or via the E:\\MDTBuildLab\\Control folder on MDT01.
``` syntax
[Settings]
Priority=Default
@ -384,19 +493,24 @@ UserID=MDT_BA
UserPassword=P@ssw0rd
SkipBDDWelcome=YES
```
So, what are these settings?
- **Priority.** This determines the order in which different sections are read. This Bootstrap.ini has only one section, named \[Default\].
- **DeployRoot.** This is the location of the deployment share. Normally, this value is set by MDT, but you need to update the DeployRoot value if you move to another server or other share. If you don't specify a value, the Windows Deployment Wizard prompts you for a location.
- **UserDomain, UserID, and UserPassword.** These values are used for automatic log on to the deployment share. Again, if they are not specified, the wizard prompts you.
**Note**  
Caution is advised. These values are stored in clear text on the boot image. Use them only for the MDT Build Lab deployment share and not for the MDT Production deployment share that you learn to create in the next topic.
 
- **SkipBDDWelcome.** Even if it is nice to be welcomed every time we start a deployment, we prefer to skip the initial welcome page of the Windows Deployment Wizard.
**Note**  
All properties beginning with "Skip" control only whether to display that pane in the Windows Deployment Wizard. Most of the panes also require you to actually set one or more values.
 
### The CustomSettings.ini file
The CustomSettings.ini file, whose content you see on the Rules tab of the deployment share Properties dialog box, contains most of the properties used in the configuration.
``` syntax
[Settings]
Priority=Default
@ -436,6 +550,7 @@ SkipFinalSummary=YES
- **OSInstall.** Must be set to Y or YES (the code actually just looks for the Y character) for the setup to proceed.
- **AdminPassword.** Sets the local Administrator account password.
- **TimeZoneName.** Establishes the time zone to use. Don't confuse this value with TimeZone, which is only for legacy operating systems (Windows 7 and Windows Server 2003).
**Note**  
The easiest way to find the current time zone name on a Windows 10 machine is to run tzutil /g in a command prompt. You can also run tzutil /l to get a listing of all available time zone names.
 
@ -459,10 +574,14 @@ SkipFinalSummary=YES
- **SkipRoles.** Skips the Install Roles and Features pane.
- **SkipCapture.** Skips the Capture pane.
- **SkipFinalSummary.** Skips the final Windows Deployment Wizard summary. Because you use FinishAction=Shutdown, you don't want the wizard to stop in the end so that you need to click OK before the machine shuts down.
## <a href="" id="sec06"></a>Build the Windows 10 reference image
Once you have created your task sequence, you are ready to create the Windows 10 reference image. This will be performed by launching the task sequence from a virtual machine which will then automatically perform the reference image creation and capture process.
This steps below outline the process used to boot a virtual machine using an ISO boot image created by MDT, and then execute the reference image task sequence image to create and capture the Windows 10 reference image.
1. Copy the E:\\MDTBuildLab\\Boot\\MDT Build Lab x86.iso on MDT01 to C:\\ISO on the Hyper-V host.
**Note**  
Remember, in MDT you can use the x86 boot image to deploy both x86 and x64 operating system images. That's why you can use the x86 boot image instead of the x64 boot image.
 
@ -474,6 +593,7 @@ This steps below outline the process used to boot a virtual machine using an ISO
5. Hard disk: 60 GB (dynamic disk)
6. Image file: C:\\ISO\\MDT Build Lab x86.iso
3. Take a snapshot of the REFW10X64-001 virtual machine, and name it **Clean with MDT Build Lab x86 ISO**.
**Note**  
Taking a snapshot is useful if you need to restart the process and want to make sure you can start clean.
 
@ -482,8 +602,11 @@ This steps below outline the process used to boot a virtual machine using an ISO
2. Specify whether to capture an image: Capture an image of this reference computer
- Location: \\\\MDT01\\MDTBuildLab$\\Captures
3. File name: REFW10X64-001.wim
![figure 13](images/fig13-captureimage.png)
Figure 13. The Windows Deployment Wizard for the Windows 10 reference image.
5. The setup now starts and does the following:
1. Installs the Windows 10 Enterprise operating system.
2. Installs the added applications, roles, and features.
@ -492,13 +615,19 @@ This steps below outline the process used to boot a virtual machine using an ISO
5. Runs System Preparation (Sysprep) and reboots into Windows PE.
6. Captures the installation to a Windows Imaging (WIM) file.
7. Turns off the virtual machine.
After some time, you will have a Windows 10 Enterprise x64 image that is fully patched and has run through Sysprep, located in the E:\\MDTBuildLab\\Captures folder on your deployment server. The file name is REFW10X64-001.wim.
## Related topics
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
[Deploy a Windows 10 image using MDT 2013 Update 2](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)
[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-2013-settings.md)
 
 

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

@ -2,24 +2,32 @@
title: Deploy a Windows 10 image using MDT 2013 Update 2 (Windows 10)
description: This topic will show you how to take your reference image for Windows 10, and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically.
ms.assetid: 1d70a3d8-1b1d-4051-b656-c0393a93f83c
ms.pagetype: mdt
keywords: ["deployment, automate, tools, configure"]
keywords: [eployment, automate, tools, configure
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Deploy a Windows 10 image using MDT 2013 Update 2
**Applies to**
- Windows 10
This topic will show you how to take your reference image for Windows 10, and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically. You will prepare for this by creating a MDT deployment share that is used solely for image deployment. Separating the processes of creating reference images from the processes used to deploy them in production allows greater control of on both processes. You will then configure the deployment share, create a new task sequence, add applications, add drivers, add rules, and configure Active Directory permissions for deployment.
For the purposes of this topic, we will use three machines: DC01, MDT01, and PC0005. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 standard server, and PC0005 is a blank machine to which you deploy Windows 10. MDT01 and PC0005 are members of the domain contoso.com for the fictitious Contoso Corporation.
**Note**  
For important details about the setup for the steps outlined in this article, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
 
![figure 1](images/mdt-07-fig01.png)
Figure 1. The machines used in this topic.
## <a href="" id="sec01"></a>Step 1: Configure Active Directory permissions
These steps will show you how to configure an Active Directory account with the permissions required to deploy a Windows 10 machine to the domain using MDT. These steps assume you have downloaded the sample [Set-OUPermissions.ps1 script](http://go.microsoft.com/fwlink/p/?LinkId=619362) and copied it to C:\\Setup\\Scripts on DC01. The account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01. In order for MDT to join machines into the contoso.com domain you need to create an account and configure permissions in Active Directory.
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
2. Select the **Service Accounts** organizational unit (OU) and create the MDT\_JD account using the following settings:
@ -49,9 +57,14 @@ These steps will show you how to configure an Active Directory account with the
6. Reset Password
7. Validated write to DNS host name
8. Validated write to service principal name
## <a href="" id="sec02"></a>Step 2: Set up the MDT production deployment share
When you are ready to deploy Windows 10 in a production environment, you will first create a new MDT deployment share. You should not use the same deployment share that you used to create the reference image for a production deployment. For guidance on creating a custom Windows 10 image, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
When you are ready to deploy Windows 10 in a production environment, you will first create a new MDT deployment share. You should not use the same deployment share that you used to create the reference image for a production deployment. For guidance on creating a custom Windows 10 image, see
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
### Create the MDT production deployment share
The steps for creating the deployment share for production are the same as when you created the deployment share for creating the custom reference image:
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd.**
2. Using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**.
@ -60,9 +73,13 @@ The steps for creating the deployment share for production are the same as when
5. On the **Descriptive Name** page, in the **Deployment share description** text box, type **MDT Production** and click **Next**.
6. On the **Options** page, accept the default settings and click **Next** twice, and then click **Finish**.
7. Using File Explorer, verify that you can access the **\\\\MDT01\\MDTProduction$** share.
## <a href="" id="sec03"></a>Step 3: Add a custom image
The next step is to add a reference image into the deployment share with the setup files required to successfully deploy Windows 10. When adding a custom image, you still need to copy setup files (an option in the wizard) because Windows 10 stores additional components in the Sources\\SxS folder which is outside the image and may be required when installing components.
### Add the Windows 10 Enterprise x64 RTM custom image
In these steps, we assume that you have completed the steps in the [Create a Windows 10 reference image](create-a-windows-10-reference-image.md) topic, so you have a Windows 10 reference image in the E:\\MDTBuildLab\\Captures folder on MDT01.
1. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Production**; select the **Operating Systems** node, and create a folder named **Windows 10**.
2. Right-click the **Windows 10** folder and select **Import Operating System**.
@ -71,14 +88,20 @@ In these steps, we assume that you have completed the steps in the [Create a Win
5. On the **Setup** page, select the **Copy Windows 7, Windows Server 2008 R2, or later setup files from the specified path** option; in the **Setup source directory** text box, browse to **E:\\MDTBuildLab\\Operating Systems\\W10EX64RTM** and click **Next**.
6. On the **Destination** page, in the **Destination directory name** text box, type **W10EX64RTM**, click **Next** twice, and then click **Finish**.
7. After adding the operating system, double-click the added operating system name in the **Operating Systems / Windows 10** node and change the name to match the following: **Windows 10 Enterprise x64 RTM Custom Image**.
**Note**  
The reason for adding the setup files has changed since earlier versions of MDT. MDT 2010 used the setup files to install Windows. MDT uses DISM to apply the image; however, you still need the setup files because some components in roles and features are stored outside the main image.
 
![figure 2](images/fig2-importedos.png)
Figure 2. The imported operating system after renaming it.
## <a href="" id="sec04"></a>Step 4: Add an application
When you configure your MDT Build Lab deployment share, you will also add any applications to the new deployment share before creating your task sequence. This section walks you through the process of adding an application to the MDT Production deployment share using Adobe Reader as an example.
### Create the install: Adobe Reader XI x86
In this example, we assume that you have downloaded the Adobe Reader XI installation file (AdbeRdr11000\_eu\_ES.msi) to E:\\Setup\\Adobe Reader on MDT01.
1. Using the Deployment Workbench, expand the **MDT Production** node and navigate to the **Applications** node.
2. Right-click the **Applications** node, and create a new folder named **Adobe**.
@ -88,20 +111,27 @@ In this example, we assume that you have downloaded the Adobe Reader XI installa
6. On the **Source** page, in the **Source Directory** text box, browse to **E:\\Setup\\Adobe Reader XI** and click **Next**.
7. On the **Destination** page, in the **Specify the name of the directory that should be created** text box, type **Install - Adobe Reader XI - x86** and click **Next**.
8. On the **Command Details** page, in the **Command Line** text box, type **msiexec /i AdbeRdr11000\_eu\_ES.msi /q**, click **Next** twice, and then click **Finish**.
![figure 3](images/mdt-07-fig03.png)
Figure 3. The Adobe Reader application added to the Deployment Workbench.
## <a href="" id="sec05"></a>Step 5: Prepare the drivers repository
In order to deploy Windows 10 with MDT 2013 Update 2 successfully, you need drivers for the boot images and for the actual operating system. This section will show you how to add drivers for the boot image and operating system, using the following hardware models as examples:
- Lenovo ThinkPad T420
- Dell Latitude E6440
- HP EliteBook 8560w
- Microsoft Surface Pro
For boot images, you need to have storage and network drivers; for the operating system, you need to have the full suite of drivers.
**Note**  
You should only add drivers to the Windows PE images if the default drivers don't work. Adding drivers that are not necessary will only make the boot image larger and potentially delay the download time.
 
### Create the driver source structure in the file system
The key to successful management of drivers for MDT 2013 Update 2, as well as for any other deployment solution, is to have a really good driver repository. From this repository, you import drivers into MDT for deployment, but you should always maintain the repository for future use.
1. On MDT01, using File Explorer, create the **E:\\Drivers** folder.
2. In the **E:\\Drivers** folder, create the following folder structure:
1. WinPE x86
@ -116,10 +146,12 @@ The key to successful management of drivers for MDT 2013 Update 2, as well as fo
- ThinkPad T420 (4178)
- Microsoft Corporation
- Surface Pro 3
**Note**  
Even if you are not going to use both x86 and x64 boot images, we still recommend that you add the support structure for future use.
 
### Create the logical driver structure in MDT 2013 Update 2
When you import drivers to the MDT 2013 Update 2 driver repository, MDT creates a single instance folder structure based on driver class names. However, you can, and should, mimic the driver structure of your driver source repository in the Deployment Workbench. This is done by creating logical folders in the Deployment Workbench.
1. On MDT01, using Deployment Workbench, select the **Out-of-Box Drivers** node.
2. In the **Out-Of-Box Drivers** node, create the following folder structure:
@ -135,6 +167,7 @@ When you import drivers to the MDT 2013 Update 2 driver repository, MDT creates
- 4178
- Microsoft Corporation
- Surface Pro 3
The preceding folder names are selected because they match the actual make and model values that MDT reads from the machines during deployment. You can find out the model values for your machines via the following command in Windows PowerShell:
``` syntax
Get-WmiObject -Class:Win32_ComputerSystem
@ -143,10 +176,15 @@ Or, you can use this command in a normal command prompt:
``` syntax
wmic csproduct get name
```
If you want a more standardized naming convention, try the ModelAliasExit.vbs script from the Deployment Guys blog post entitled [Using and Extending Model Aliases for Hardware Specific Application Installation](http://go.microsoft.com/fwlink/p/?LinkId=619536).
![figure 4](images/fig4-oob-drivers.png)
Figure 4. The Out-of-Box Drivers structure in Deployment Workbench.
### Create the selection profiles for boot image drivers
By default, MDT adds any storage and network drivers that you import to the boot images. However, you should add only the drivers that are necessary to the boot image. You can control which drivers are added by using selection profiles.
The drivers that are used for the boot images (Windows PE) are Windows 10 drivers. If you can’t locate Windows 10 drivers for your device, a Windows 7 or Windows 8.1 driver will most likely work, but Windows 10 drivers should be your first choice.
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Advanced Configuration** node, right-click the **Selection Profiles** node, and select **New Selection Profile**.
@ -157,44 +195,70 @@ The drivers that are used for the boot images (Windows PE) are Windows 10 driver
4. In the New Selection Profile Wizard, create a selection profile with the following settings:
1. Selection Profile name: WinPE x64
2. Folders: Select the WinPE x64 folder in Out-of-Box Drivers.
![figure 5](images/fig5-selectprofile.png)
Figure 5. Creating the WinPE x64 selection profile.
### Extract and import drivers for the x64 boot image
Windows PE supports all the hardware models that we have, but here you learn to add boot image drivers to accommodate any new hardware that might require additional drivers. In this example, you add the latest Intel network drivers to the x64 boot image.
In these steps, we assume you have downloaded PROWinx64.exe from Intel.com and saved it to a temporary folder.
1. Extract PROWinx64.exe to a temporary folder - in this example to the **C:\\Tmp\\ProWinx64** folder.
2. Using File Explorer, create the **E:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
3. Copy the content of the **C:\\Tmp\\PROWinx64\\PRO1000\\Winx64\\NDIS64** folder to the **E:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
4. Using Deployment Workbench, expand the **Out-of-Box Drivers** node, right-click the **WinPE x64** node, and select **Import Drivers**. Use the following setting for the Import Drivers Wizard:
- Driver source directory: **E:\\Drivers\\WinPE x64\\Intel PRO1000**
### Download, extract, and import drivers
### For the ThinkPad T420
For the Lenovo T420 model, you use the Lenovo ThinkVantage Update Retriever software to download the drivers. With Update Retriever, you need to specify the correct Lenovo Machine Type for the actual hardware (the first four characters of the model name). As an example, the Lenovo T420 model has the 4178B9G model name, meaning the Machine Type is 4178.
To get the updates, you download the drivers from the Lenovo ThinkVantage Update Retriever using its export function. You can download the drivers from the [Lenovo website](http://go.microsoft.com/fwlink/p/?LinkId=619543).
In these steps, we assume you have downloaded and extracted the drivers using ThinkVantage Update Retriever v5.0 to the E:\\Drivers\\Lenovo\\ThinkPad T420 (4178) folder.
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Lenovo** node.
2. Right-click the **4178** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Lenovo\\ThinkPad T420 (4178)**
### For the Latitude E6440
For the Dell Latitude E6440 model, you use the Dell Driver CAB file, which is accessible via the [Dell TechCenter website](http://go.microsoft.com/fwlink/p/?LinkId=619544).
In these steps, we assume you have downloaded and extracted the CAB file for the Latitude E6440 model to the E:\\Drivers\\Dell\\Latitude E6440 folder.
1. On **MDT01**, using the **Deployment Workbench**, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Dell** node.
2. Right-click the **Latitude E6440** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Dell\\Latitude E6440**
### For the HP EliteBook 8560w
For the HP EliteBook 8560w, you use HP SoftPaq Download Manager to get the drivers. The HP SoftPaq Download Manager can be accessed on the [HP Support site](http://go.microsoft.com/fwlink/p/?LinkId=619545).
In these steps, we assume you have downloaded and extracted the drivers for the HP EliteBook 8650w model to the E:\\Drivers\\Windows 10 x64\\HP\\HP EliteBook 8560w folder.
1. On **MDT01**, using the **Deployment Workbench**, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Hewlett-Packard** node.
2. Right-click the **HP EliteBook 8560w** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\HP\\HP EliteBook 8560w**
### For the Microsoft Surface Pro 3
For the Microsoft Surface Pro model, you find the drivers on the Microsoft website. In these steps we assume you have downloaded and extracted the Surface Pro 3 drivers to the E:\\Drivers\\Windows 10 x64\\Microsoft\\Surface Pro 3 folder.
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Microsoft** node.
2. Right-click the **Surface Pro 3** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Microsoft\\Surface Pro 3**
## <a href="" id="sec06"></a>Step 6: Create the deployment task sequence
This section will show you how to create the task sequence used to deploy your production Windows 10 reference image. You will then configure the tasks sequence to enable patching via a Windows Server Update Services (WSUS) server.
### Create a task sequence for Windows 10 Enterprise
1. Using the Deployment Workbench, select **Task Sequences** in the **MDT Production** node, and create a folder named **Windows 10**.
2. Right-click the new **Windows 10** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
1. Task sequence ID: W10-X64-001
@ -208,6 +272,7 @@ This section will show you how to create the task sequence used to deploy your p
9. Internet Explorer home page: about:blank
10. Admin Password: Do not specify an Administrator Password at this time
### Edit the Windows 10 task sequence
1. Right-click the **Windows 10 Enterprise x64 RTM Custom Image** task sequence, and select **Properties**.
2. On the **Task Sequence** tab, configure the **Windows 10 Enterprise x64 RTM Custom Image** task sequence with the following settings:
1. Preinstall. After the **Enable BitLocker (Offline)** action, add a **Set Task Sequence Variable** action with the following settings:
@ -223,11 +288,17 @@ This section will show you how to create the task sequence used to deploy your p
3. State Restore. Enable the **Windows Update (Pre-Application Installation)** action.
4. State Restore. Enable the **Windows Update (Post-Application Installation)** action.
3. Click **OK**.
![figure 6](images/fig6-taskseq.png)
Figure 6. The task sequence for production deployment.
## <a href="" id="sec07"></a>Step 7: Configure the MDT production deployment share
In this section, you will learn how to configure the MDT Build Lab deployment share with the rules required to create a simple and dynamic deployment process. This includes configuring commonly used rules and an explanation of how these rules work.
### Configure the rules
1. On MDT01, using File Explorer, copy the following files from the **D:\\Setup\\Sample Files\\MDT Production\\Control** folder to **E:\\MDTProduction\\Control**. Overwrite the existing files.
1. Bootstrap.ini
2. CustomSettings.ini
@ -295,14 +366,21 @@ In this section, you will learn how to configure the MDT Build Lab deployment sh
10. In the **Drivers and Patches** sub tab, select the **WinPE x64** selection profile and select the **Include all drivers from the selection profile** option.
11. In the **Monitoring** tab, select the **Enable monitoring for this deployment share** check box.
12. Click **OK**.
**Note**  
It will take a while for the Deployment Workbench to create the monitoring database and web service.
 
![figure 8](images/mdt-07-fig08.png)
Figure 7. The Windows PE tab for the x64 boot image.
### The rules explained
The rules for the MDT Production deployment share are somewhat different from those for the MDT Build Lab deployment share. The biggest differences are that you deploy the machines into a domain instead of a workgroup and that you do not automate the logon.
### The Bootstrap.ini file
This is the MDT Production Bootstrap.ini without the user credentials (except domain information):
``` syntax
[Settings]
@ -314,6 +392,7 @@ UserID=MDT_BA
SkipBDDWelcome=YES
```
### The CustomSettings.ini file
This is the CustomSettings.ini file with the new join domain information:
``` syntax
[Settings]
@ -360,9 +439,14 @@ The additional properties to use in the MDT Production rules file are as follows
- **ScanStateArgs.** Arguments for the User State Migration Tool (USMT) ScanState command.
- **USMTMigFiles(\*).** List of USMT templates (controlling what to backup and restore).
- **EventService.** Activates logging information to the MDT monitoring web service.
### Optional deployment share configuration
If your organization has a Microsoft Software Assurance agreement, you also can subscribe to the additional Microsoft Desktop Optimization Package (MDOP) license (at an additional cost). Included in MDOP is Microsoft Diagnostics and Recovery Toolkit (DaRT), which contains tools that can help you troubleshoot MDT deployments, as well as troubleshoot Windows itself.
If your organization has a Microsoft Software Assurance agreement, you also can subscribe to the additional Microsoft Desktop Optimization Package (MDOP) license (at an additional cost). Included in MDOP is Microsoft Diagnostics and Recovery Toolkit (DaRT), which contains tools that can help you
troubleshoot MDT deployments, as well as troubleshoot Windows itself.
### Add DaRT 10 to the boot images
If you have licensing for MDOP and DaRT, you can add DaRT to the boot images using the steps in this section. If you do not have DaRT licensing, or don't want to use it, simply skip to the next section, [Update the Deployment Share](#bkmk-update-deployment). To enable the remote connection feature in MDT 2013 Update 2, you need to do the following:
- Install DaRT 10 (part of MDOP 2015 R1).
- Copy the two tools CAB files (Toolsx86.cab and Toolsx64.cab) to the deployment share.
@ -375,27 +459,40 @@ In these steps, we assume that you downloaded MDOP 2015 R1 and copied DaRT 10 to
5. Using the Deployment Workbench, right-click the **MDT Production** deployment share and select **Properties**.
6. In the **Windows PE** tab, in the **Platform** drop-down list, make sure **x86** is selected.
7. In the **Features** sub tab, select the **Microsoft Diagnostics and Recovery Toolkit (DaRT)** check box.
![figure 8](images/mdt-07-fig09.png)
Figure 8. Selecting the DaRT 10 feature in the deployment share.
8. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
9. In the **Features** sub tab, in addition to the default selected feature pack, select the **Microsoft Diagnostics and Recovery Toolkit (DaRT)** check box.
10. Click **OK**.
### <a href="" id="bkmk-update-deployment"></a>Update the deployment share
Like the MDT Build Lab deployment share, the MDT Production deployment share needs to be updated after it has been configured. This is the process during which the Windows PE boot images are created.
1. Right-click the **MDT Production** deployment share and select **Update Deployment Share**.
2. Use the default options for the Update Deployment Share Wizard.
**Note**  
The update process will take 5 to 10 minutes.
 
## <a href="" id="sec08"></a>Step 8: Deploy the Windows 10 client image
These steps will walk you throug the process of using task sequences to deploy Windows 10 images through a fully automated process. First, you need to add the boot image to Windows Deployment Services (WDS) and then start the deployment. In contrast with deploying images from the MDT Build Lab deployment share, we recommend using the Pre-Installation Execution Environment (PXE) to start the full deployments in the datacenter, even though you technically can use an ISO/CD or USB to start the process.
### Configure Windows Deployment Services
You need to add the MDT Production Lite Touch x64 Boot image to WDS in preparation for the deployment. For the following steps, we assume that Windows Deployment Services has already been installed on MDT01.
1. 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.
![figure 9](images/mdt-07-fig10.png)
Figure 9. The boot image added to the WDS console.
### Deploy the Windows 10 client
At this point, you should have a solution ready for deploying the Windows 10 client. We recommend starting by trying a few deployments at a time until you are confident that your configuration works as expected. We find it useful to try some initial tests on virtual machines before testing on physical hardware. This helps rule out hardware issues when testing or troubleshooting. Here are the steps to deploy your Windows 10 image to a virtual machine:
1. Create a virtual machine with the following settings:
1. Name: PC0005
@ -404,8 +501,11 @@ At this point, you should have a solution ready for deploying the Windows 10 cl
4. Memory: 2048 MB
5. Hard disk: 60 GB (dynamic disk)
2. Start the PC0005 virtual machine, and press **Enter** to start the PXE boot. The machine will now load the Windows PE boot image from the WDS server.
![figure 10](images/mdt-07-fig11.png)
Figure 10. The initial PXE boot process of PC0005.
3. After Windows PE has booted, complete the Windows Deployment Wizard using the following setting:
1. Password: P@ssw0rd
2. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Custom Image
@ -415,33 +515,57 @@ At this point, you should have a solution ready for deploying the Windows 10 cl
1. Installs the Windows 10 Enterprise operating system.
2. Installs the added application.
3. Updates the operating system via your local Windows Server Update Services (WSUS) server.
### Use the MDT 2013 monitoring feature
Now that you have enabled the monitoring on the MDT Production deployment share, you can follow your deployment of PC0005 via the monitoring node.
1. On MDT01, using Deployment Workbench, expand the **MDT Production** deployment share folder.
2. Select the **Monitoring** node, and wait until you see PC0005.
3. Double-click PC0005, and review the information.
![figure 11](images/mdt-07-fig13.png)
Figure 11. The Monitoring node, showing the deployment progress of PC0005.
### Use information in the Event Viewer
When monitoring is enabled, MDT also writes information to the event viewer on MDT01. This information can be used to trigger notifications via scheduled tasks when deployment is completed. For example, you can configure scheduled tasks to send an email when a certain event is created in the event log.
![figure 12](images/mdt-07-fig14.png)
Figure 12. The Event Viewer showing a successful deployment of PC0005.
## <a href="" id="sec09"></a>Multicast deployments
Multicast deployment allows for image deployment with reduced network load during simultaneous deployments. Multicast is a useful operating system deployment feature in MDT deployments, however it is important to ensure that your network supports it and is designed for it.
### Requirements
Multicast requires that Windows Deployment Services (WDS) is running on Windows Server 2008 or later. In addition to the core MDT 2013 setup for multicast, the network needs to be configured to support multicast. In general, this means involving the organization networking team to make sure that Internet Group Management Protocol (IGMP) snooping is turned on and that the network is designed for multicast traffic. The multicast solution uses IGMPv3.
Multicast requires that Windows Deployment Services (WDS) is running on Windows Server 2008 or later. In addition to the core MDT 2013 setup for multicast, the network needs to be configured to support multicast. In general, this means involving the organization networking team to make sure that
Internet Group Management Protocol (IGMP) snooping is turned on and that the network is designed for multicast traffic. The multicast solution uses IGMPv3.
### Set up MDT for multicast
Setting up MDT for multicast is straightforward. You enable multicast on the deployment share, and MDT takes care of the rest.
1. On MDT01, right-click the **MDT Production** deployment share folder and select **Properties**.
2. In the **General** tab, select the **Enable multicast for this deployment share (requires Windows Server 2008 R2 Windows Deployment Services)** check box, and click **OK**.
3. Right-click the **MDT Production** deployment share folder and select **Update Deployment Share**.
4. After updating the deployment share, use the Windows Deployment Services console to, verify that the multicast namespace was created.
![figure 13](images/mdt-07-fig15.png)
Figure 13. The newly created multicast namespace.
## <a href="" id="sec10"></a>Use offline media to deploy Windows 10
In addition to network-based deployments, MDT supports the use of offline media-based deployments of Windows 10. You can very easily generate an offline version of your deployment share - either the full deployment share or a subset of it - by the use of selection profiles. The generated offline media can be burned to a DVD or copied to a USB stick for deployment.
Offline media are useful not only when you do not have network connectivity to the deployment share, but also when you have limited connection to the deployment share and do not want to copy 5 GB of data over the wire. Offline media can still join the domain, but you save the transfer of operating system images, drivers, and applications over the wire.
### Create the offline media selection profile
To filter what is being added to the media, you create a selection profile. When creating selection profiles, you quickly realize the benefits of having created a good logical folder structure in the Deployment Workbench.
1. On MDT01, using Deployment Workbench, in the **MDT Production / Advanced Configuration** node, right-click **Selection Profile**, and select **New Selection Profile**.
2. Use the following settings for the New Selection Profile Wizard:
@ -453,8 +577,11 @@ To filter what is being added to the media, you create a selection profile. When
3. Out-Of-Box Drivers / WinPE x64
4. Out-Of-Box Drivers / Windows 10 x64
5. Task Sequences / Windows 10
### Create the offline media
In these steps, you generate offline media from the MDT Production deployment share. To filter what is being added to the media, you use the previously created selection profile.
1. On MDT01, using File Explorer, create the **E:\\MDTOfflineMedia** folder.
**Note**  
When creating offline media, you need to create the target folder first. It is crucial that you do not create a subfolder inside the deployment share folder because it will break the offline media.
@ -464,8 +591,11 @@ In these steps, you generate offline media from the MDT Production deployment sh
- General Settings
1. Media path: **E:\\MDTOfflineMedia**
2. Selection profile: Windows 10 Offline Media
### Configure the offline media
Offline media has its own rules, its own Bootstrap.ini and CustomSettings.ini files. These files are stored in the Control folder of the offline media; they also can be accessed via properties of the offline media in the Deployment Workbench.
1. On MDT01, using File Explorer, copy the CustomSettings.ini file from the **E:\\MDTBuildLab\\Control** folder to **E:\\MDTOfflineMedia\\Content\\Deploy\\Control**. Overwrite the existing files.
2. Using Deployment Workbench, in the **MDT Production / Advanced Configuration / Media** node, right-click the **MEDIA001** media, and select **Properties**.
3. In the **General** tab, configure the following:
@ -478,29 +608,44 @@ Offline media has its own rules, its own Bootstrap.ini and CustomSettings.ini fi
2. In the **Windows PE Customizations** area, set the Scratch space size to 128.
6. In the **Drivers and Patches** sub tab, select the **WinPE x64** selection profile and select the **Include all drivers from the selection profile** option.
7. Click **OK**.
### Generate the offline media
You have now configured the offline media deployment share however the share has not yet been populated with the files required for deployment. Now everything is ready you populate the deployment share content folder and generate the offline media ISO.
1. On MDT01, using Deployment Workbench, navigate to the **MDT Production / Advanced Configuration / Media** node.
2. Right-click the **MEDIA001** media, and select **Update Media Content**. The Update Media Content process now generates the offline media in the **E:\\MDTOfflineMedia\\Content** folder.
### Create a bootable USB stick
The ISO that you got when updating the offline media item can be burned to a DVD and used directly (it will be bootable), but it is often more efficient to use USB sticks instead since they are faster and can hold more data. (A dual-layer DVD is limited to 8.5 GB.)
Follow these steps to create a bootable USB stick from the offline media content:
1. On a physical machine running Windows 7 or later, insert the USB stick you want to use.
2. Copy the content of the **MDTOfflineMedia\\Content** folder to the root of the USB stick.
3. Start an elevated command prompt (run as Administrator), and start the Diskpart utility by typing **Diskpart** and pressing **Enter**.
4. In the Diskpart utility, you can type **list volume** (or the shorter **list vol**) to list the volumes, but you really only need to remember the drive letter of the USB stick to which you copied the content. In our example, the USB stick had the drive letter F.
5. In the Diskpart utility, type **select volume F** (replace F with your USB stick drive letter).
6. In the Diskpart utility, type **active**, and then type **exit**.
## <a href="" id="sec11"></a>Unified Extensible Firmware Interface (UEFI)-based deployments
As referenced in [Windows 10 deployment tools](http://go.microsoft.com/fwlink/p/?LinkId=619546), Unified Extensible Firmware Interface (UEFI)-based deployments are becoming more common. In fact, when you create a generation 2 virtual machine in Hyper-V, you get a UEFI-based computer. During deployment, MDT automatically detects that you have an UEFI-based machine and creates the partitions UEFI requires. You do not need to update or change your task sequences in any way to accommodate UFEI.
![figure 14](images/mdt-07-fig16.png)
Figure 14. The partitions when deploying an UEFI-based machine.
## 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)
[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)
[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-2013-settings.md)
 
 

34
windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit.md
View File

@ -2,21 +2,28 @@
title: Deploy Windows 10 with the Microsoft Deployment Toolkit (Windows 10)
description: This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically.
ms.assetid: 837f009c-617e-4b3f-9028-2246067ee0fb
ms.pagetype: mdt
keywords: ["deploy", "tools", "configure", "script"]
keywords: deploy, tools, configure, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: mtniehaus
ms.pagetype: mdt
---
# Deploy Windows 10 with the Microsoft Deployment Toolkit
**Applies to**
- Windows 10
This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 specifically.
The Microsoft Deployment Toolkit is a unified collection of tools, processes, and guidance for automating desktop and server deployment. In addition to reducing deployment time and standardizing desktop and server images, MDT enables you to more easily manage security and ongoing configurations. MDT builds on top of the core deployment tools in the Windows Assessment and Deployment Kit (Windows ADK) with additional guidance and features designed to reduce the complexity and time required for deployment in an enterprise environment.
MDT 2013 Update 2 supports the deployment of Windows 10, as well as Windows 7, Windows 8, Windows 8.1, and Windows Server 2012 R2. It also includes support for zero-touch installation (ZTI) with Microsoft System Center 2012 R2 Configuration Manager.
To download the latest version of MDT, visit the [MDT resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
## In this section
- [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 2013 Update 2](deploy-a-windows-10-image-using-mdt.md)
@ -24,14 +31,23 @@ To download the latest version of MDT, visit the [MDT resource page](http://go.m
- [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-2013-settings.md)
## <a href="" id="proof"></a>Proof-of-concept environment
For the purposes of this guide, and the topics discussed herein, we will use the following servers and client machines: DC01, MDT01, CM01, PC0001, and PC0002.
![figure 1](images/mdt-01-fig01.png)
Figure 1. The servers and machines used for examples in this guide.
DC01 is a domain controller; the other servers and client machines are members of the domain contoso.com for the fictitious Contoso Corporation.
![figure 2](images/mdt-01-fig02.jpg)
Figure 2. The organizational unit (OU) structure used in this guide.
### Server details
- **DC01.** A Windows Server 2012 R2 Standard machine, fully patched with the latest security updates, and configured as Active Directory Domain Controller, DNS Server, and DHCP Server in the contoso.com domain.
- Server name: DC01
- IP Address: 192.168.1.200
@ -42,25 +58,35 @@ Figure 2. The organizational unit (OU) structure used in this guide.
- **CM01.** A Windows Server 2012 R2 Standard machine, fully patched with the latest security updates, and configured as a member server in the contoso.com domain.
- Server name: CM01
- IP Address: 192.168.1.214
### Client machine details
- **PC0001.** A Windows 10 Enterprise x64 machine, fully patched with the latest security updates, and configured as a member in the contoso.com domain. This machine is referenced as the admin workstation.
- Client name: PC0001
- IP Address: DHCP
- **PC0002.** A Windows 7 SP1 Enterprise x64 machine, fully patched with the latest security updates, and configured as a member in the contoso.com domain. This machine is referenced during the migration scenarios.
- Client name: PC0002
- IP Address: DHCP
## Sample files
The information in this guide is designed to help you deploy Windows 10. In order to help you put the information you learn into practice more quickly, we recommend that you download a small set of sample files for the fictitious Contoso Corporation:
- [Gather.ps1](http://go.microsoft.com/fwlink/p/?LinkId=619361). This sample Windows PowerShell script performs the MDT Gather process in a simulated MDT environment. This allows you to test the MDT gather process and check to see if it is working correctly without performing a full Windows deployment.
- [Set-OUPermissions.ps1](http://go.microsoft.com/fwlink/p/?LinkId=619362). This sample Windows PowerShell script creates a domain account and then configures OU permissions to allow the account to join machines to the domain in the specified OU.
- [MDTSample.zip](http://go.microsoft.com/fwlink/p/?LinkId=619363). This sample web service shows you how to configure a computer name dynamically using MDT.
## Related topics
[Microsoft Deployment Toolkit downloads and resources](http://go.microsoft.com/fwlink/p/?LinkId=618117)
[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
[Windows 10 deployment tools](windows-deployment-scenarios-and-tools.md)
[Deploy Windows 10 with System Center 2012 R2 Configuration Manager](deploy-windows-10-with-system-center-2012-r2-configuration-manager.md)
[Deploy Windows To Go in your organization](deploy-windows-to-go.md)
[Sideload apps in Windows 10](sideload-apps-in-windows-10.md)
[Volume Activation for Windows 10](volume-activation-windows-10.md)
 
 

26
windows/deploy/get-started-with-the-microsoft-deployment-toolkit.md
View File

@ -2,32 +2,48 @@
title: Get started with the Microsoft Deployment Toolkit (MDT) (Windows 10)
description: This topic will help you gain a better understanding of how to use the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 in particular, as part of a Windows operating system deployment.
ms.assetid: a256442c-be47-4bb9-a105-c831f58ce3ee
ms.pagetype: mdt
keywords: ["deploy", "image", "feature", "install", "tools"]
keywords: deploy, image, feature, install, tools
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Get started with the Microsoft Deployment Toolkit (MDT)
**Applies to**
- Windows 10
This topic will help you gain a better understanding of how to use the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 2 in particular, as part of a Windows operating system deployment. MDT is one of the most important tools available to IT professionals today. You can use it to create reference images or as a complete deployment solution. MDT 2013 Update 2 also can be used to extend the operating system deployment features available in Microsoft System Center 2012 R2 Configuration Manager.
In addition to familiarizing you with the features and options available in MDT 2013 Update 2, this topic will walk you through the process of preparing for deploying Windows 10 using MDT by configuring Active Directory, creating an organizational unit (OU) structure, creating service accounts, configuring log files and folders, and installing the tools needed to view the logs and continue with the deployment process.
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).
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).
![figure 1](images/mdt-05-fig01.png)
Figure 1. The machines used in this topic.
## In this section
- [Key features in MDT 2013 Update 2](key-features-in-mdt-2013.md)
- [MDT 2013 Update 2 Lite Touch components](mdt-2013-lite-touch-components.md)
- [Prepare for deployment with MDT 2013 Update 2](prepare-for-windows-deployment-with-mdt-2013.md)
## Related topics
[Microsoft Deployment Toolkit downloads and documentation](http://go.microsoft.com/fwlink/p/?LinkId=618117)
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
[Deploy a Windows 10 image using MDT 2013 Update 2](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)
[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-2013-settings.md)
 
 

14
windows/deploy/import-export-vamt-data.md
View File

@ -2,25 +2,33 @@
title: Import and Export VAMT Data (Windows 10)
description: Import and Export VAMT Data
ms.assetid: 09a2c595-1a61-4da6-bd46-4ba8763cfd4f
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Import and Export VAMT Data
You can use the Volume Activation Management Tool (VAMT) to import product-activation data from a Computer Information List (.cilx or .cil) file into SQL Server, and to export product-activation data into a .cilx file. A .cilx file is an XML file that stores computer and product-activation data. You can import data or export data during the following scenarios:
You can use the Volume Activation Management Tool (VAMT) to import product-activation data from a Computer Information List (.cilx or .cil) file into SQL Server, and to export product-activation data into a .cilx file. A .cilx file is an XML file that stores computer and product-activation data.
You can import data or export data during the following scenarios:
- Import and merge data from previous versions of VAMT.
- Export data to use to perform proxy activations.
**Warning**  
Editing a .cilx file using an application other than VAMT can corrupt the .cilx file and is not supported.
## Import VAMT Data
**To import data into VAMT**
1. Open VAMT.
2. In the right-side **Actions** pane, click **Import list** to open the **Import List** dialog box.
3. In the **Import List** dialog box, navigate to the .cilx file location, select the file, and click **Open**.
4. In the **Volume Activation Management Tool** dialog box, click **OK** to begin the import. VAMT displays a progress message while the file is being imported. Click **OK** when a message appears and confirms that the import has completed successfully.
## Export VAMT Data
Exporting VAMT data from a non-Internet-connected VAMT host computer is the first step of proxy activation using multiple VAMT hosts. To export product-activation data to a .cilx file:
1. In the left-side pane, you can click a product you want to export data for, or click **Products** if the list contains data for all products.
2. If you want to export only part of the data in a product list, in the product list view in the center pane select the products you want to export.
@ -32,5 +40,7 @@ Exporting VAMT data from a non-Internet-connected VAMT host computer is the firs
- Export proxy activation data only. Selecting this option ensures that the export contains only the licensing information required for the proxy web service to obtain CIDs from Microsoft. No Personally Identifiable Information (PII) is contained in the exported .cilx file when this selection is checked.
6. If you have selected products to export, select the **Export selected product rows only** check box.
7. Click **Save**. VAMT displays a progress message while the data is being exported. Click **OK** when a message appears and confirms that the export has completed successfully.
## Related topics
- [Perform Proxy Activation](proxy-activation-vamt.md)

8
windows/deploy/install-configure-vamt.md
View File

@ -2,21 +2,27 @@
title: Install and Configure VAMT (Windows 10)
description: Install and Configure VAMT
ms.assetid: 5c7ae9b9-0dbc-4277-bc4f-8b3e4ab0bf50
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Install and Configure VAMT
This section describes how to install and configure the Volume Activation Management Tool (VAMT).
## In this Section
|Topic |Description |
|------|------------|
|[VAMT Requirements](vamt-requirements.md) |Provides system requirements for installing VAMT on a host computer. |
|[Install VAMT](install-vamt.md) |Describes how to get and install VAMT. |
|[Configure Client Computers](configure-client-computers-vamt.md) |Describes how to configure client computers on your network to work with VAMT. |
## Related topics
- [Introduction to VAMT](introduction-vamt.md)
 
 

10
windows/deploy/install-kms-client-key-vamt.md
View File

@ -2,16 +2,20 @@
title: Install a KMS Client Key (Windows 10)
description: Install a KMS Client Key
ms.assetid: d234468e-7917-4cf5-b0a8-4968454f7759
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Install a KMS Client Key
You can use the Volume Activation Management Tool (VAMT) to install Generic Volume License Key (GVLK), or KMS client, product keys. For example, if you are converting a MAK-activated product to KMS activation.
**Note**  
By default, volume license editions of Windows Vista, Windows® 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. GVLKs are already installed in volume license editions of these products.
**To install a KMS Client key**
1. Open VAMT.
2. In the left-side pane click **Products** to open the product list view in the center pane.
@ -23,7 +27,11 @@ By default, volume license editions of Windows Vista, Windows® 7, Windows 8,
6. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
7. The **Install Product Key** dialog box displays the keys that are available to be installed.
8. Select the **Automatically select an AD or KMS client key** option and then click **Install Key**.
VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the product list view in the center pane.
## Related topics
- [Perform KMS Activation](kms-activation-vamt.md)

12
windows/deploy/install-product-key-vamt.md
View File

@ -2,14 +2,17 @@
title: Install a Product Key (Windows 10)
description: Install a Product Key
ms.assetid: 78812c87-2208-4f8b-9c2c-5a8a18b2d648
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Install a Product Key
You can use the Volume Activation Management Tool (VAMT) to install retail, Multiple Activation Key (MAK), and KMS Host key (CSVLK).
**To install a Product key**
1. Open VAMT.
2. In the left-side pane, click the product that you want to install keys onto.
@ -22,10 +25,15 @@ You can use the Volume Activation Management Tool (VAMT) to install retail, Mult
7. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
8. The **Select Product Key** dialog box displays the keys that are available to be installed. Under **Recommended MAKs**, VAMT might display one or more recommended MAK based on the selected products. You can select a recommended product key or a product key from the **All Product Keys** list. Use the scroll bar if you need to view the **Description** for each key. When you have selected the product key you want to install, click **Install Key**. Note that only one key can be installed at a time.
9. VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the product list view in the center pane.
**Note**  
Product key installation will fail if VAMT finds mismatched key types or editions. VAMT will display the failure status and will continue the installation for the next product in the list. For more information on choosing the correct MAK or KMS Host key (CSVLK), see [How to Choose the Right Volume License Key for Windows](http://go.microsoft.com/fwlink/p/?linkid=238382).
Product key installation will fail if VAMT finds mismatched key types or editions. VAMT will display the failure status and will continue the installation for the next product in the list. For more information on choosing the correct MAK or KMS Host key (CSVLK), see [How to Choose the Right
Volume License Key for Windows](http://go.microsoft.com/fwlink/p/?linkid=238382).
## Related topics
- [Manage Product Keys](manage-product-keys-vamt.md)
 
 

16
windows/deploy/install-vamt.md
View File

@ -2,33 +2,47 @@
title: Install VAMT (Windows 10)
description: Install VAMT
ms.assetid: 2eabd3e2-0a68-43a5-8189-2947e46482fc
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Install VAMT
This topic describes how to install the Volume Activation Management Tool (VAMT).
## Install VAMT
You can install VAMT as part of the [Windows Assessment and Deployment Kit (ADK)](http://go.microsoft.com/fwlink/p/?LinkId=526740) for Windows 10.
**Important**  
VAMT requires local administrator privileges on all managed computers in order to deposit confirmation IDs (CIDs), get the client products’ license status, and install product keys. If VAMT is being used to manage products and product keys on the local host computer and you do not have administrator privileges, start VAMT with elevated privileges. For Active Directory-Based Activation use, for best results we recommend running VAMT while logged on as a domain administrator. 
**Note**  
The VAMT Microsoft Management Console snap-in ships as an x86 package.
After you install VAMT, if you have a computer information list (CIL) that was created in a previous version of VAMT, you must import the list into a SQL database. If you do not have SQL installed, you can download a free copy of Microsoft SQL Server Express and create a new database into which you can import the CIL. To install SQL Server Express:
1. Install the Windows ADK.
2. Ensure that **Volume Activation Management Tool** and **Microsoft® SQL Server® 2012 Express** are selected to be installed.
3. Click **Install**.
## Select a Database
**Using a SQL database installed during ADK setup**
If SQL Server 2012 Express was installed during ADK setup, the default database name will be **ADK**.By default, VAMT is configure to use a SQL database that is installed on the local machine during ADK setup and displays the server name as **.\\ADK**. If the SQL database was installed on another machine, you must configure the database to allow remote connections and you must provide the corresponding server name. If a new VAMT database needs to be created, provide a name for the new database.
**Using a SQL database installed outside of ADK setup**
You must configure SQL installation to allow remote connections and you must provide the corresponding server name in the format: *Machine Name\\SQL Server Name*. If a new VAMT database needs to be created, provide a name for the new database.
## Uninstall VAMT
To uninstall VAMT via the **Programs and Features** Control Panel:
1. Open the **Control Panel** and select **Programs and Features**.
2. Select **Assessment and Deployment Kit** from the list of installed programs and click **Change**. Follow the instructions in the Windows ADK installer to remove VAMT.
## Related topics
- [Install and Configure VAMT](install-configure-vamt.md)
 

42
windows/deploy/integrate-configuration-manager-with-mdt-2013.md
View File

@ -3,21 +3,29 @@ title: Integrate Configuration Manager with MDT 2013 Update 2 (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.pagetype: mdt
keywords: ["deploy, image, customize, task sequence"]
keywords: deploy, image, customize, task sequence
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: mtniehaus
---
# Integrate Configuration Manager with MDT 2013 Update 2
**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 2013 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 2013 Update 2 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 2013 Update 2 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
@ -42,22 +50,39 @@ The task sequence uses instructions that allow you to reduce the number of task
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-2013-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.
@ -65,15 +90,24 @@ You can create reference images for Configuration Manager in Configuration Manag
- 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](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](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)
 
 
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-client-with-windows-10-using-configuration-manager.md) 

19
windows/deploy/introduction-vamt.md
View File

@ -2,42 +2,59 @@
title: Introduction to VAMT (Windows 10)
description: Introduction to VAMT
ms.assetid: 0439685e-0bae-4967-b0d4-dd84ca6d7fa7
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Introduction to VAMT
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office®, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has one of the following Windows operating systems: Windows® 7, Windows 8, Windows 8.1, Windows 10,Windows Server 2008 R2, or Windows Server 2012.
**Note**  
VAMT can be installed on, and can manage, physical or virtual instances. VAMT cannot detect whether or not the remote products are virtual. As long as the products can respond to Windows Management Instrumentation (WMI) calls, they will be discovered and activated.
## In this Topic
- [Managing Multiple Activation Key (MAK) and Retail Activation](#bkmk-managingmak)
- [Managing Key Management Service (KMS) Activation](#bkmk-managingkms)
- [Enterprise Environment](#bkmk-enterpriseenvironment)
- [VAMT User Interface](#bkmk-userinterface)
## Managing Multiple Activation Key (MAK) and Retail Activation
You can use a MAK or a retail product key to activate Windows, Windows Server, or Office on an individual computer or a group of computers. VAMT enables two different activation scenarios:
- **Online activation.** Many enterprises maintain a single Windows system image or Office installation package for deployment across the enterprise. Occasionally there is also a need to use retail product keys in special situations. Online activation enables you to activate over the Internet any products installed with MAK, KMS host, or retail product keys on one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
- **Proxy activation.** This activation method enables you to perform volume activation for products installed on client computers that do not have Internet access. The VAMT host computer distributes a MAK, KMS Host key (CSVLK), or retail product key to one or more client products and collects the installation ID (IID) from each client product. The VAMT host sends the IIDs to Microsoft on behalf of the client products and obtains the corresponding Confirmation IDs (CIDs). The VAMT host then installs the CIDs on the client products to complete the activation. Using this method, only the VAMT host computer needs Internet access. You can also activate products installed on computers in a workgroup that is completely isolated from any larger network, by installing a second instance of VAMT on a computer within the workgroup. Then, use removable media to transfer activation data between this new instance of VAMT and the Internet-connected VAMT host.
## Managing Key Management Service (KMS) Activation
In addition to MAK or retail activation, you can use VAMT to perform volume activation using the Key Management Service (KMS). VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by Volume License editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 as well as Microsoft Office 2010.
VAMT treats a KMS Host key (CSVLK) product key identically to a retail-type product key; therefore, the experience for product key entry and activation management are identical for both these product key types.
## Enterprise Environment
VAMT is commonly implemented in enterprise environments. The following illustrates three common environments—Core Network, Secure Zone, and Isolated Lab.
![VAMT in the enterprise](images/dep-win8-l-vamt-image001-enterprise.jpg)
In the Core Network environment, all computers are within a common network managed by Active Directory® Domain Services (AD DS). The Secure Zone represents higher-security Core Network computers that have additional firewall protection.
The Isolated Lab environment is a workgroup that is physically separate from the Core Network, and its computers do not have Internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the Isolated Lab.
## VAMT User Interface
The following screenshot shows the VAMT graphical user interface.
![VAMT user interface](images/vamtuserinterfaceupdated.jpg)
VAMT provides a single, graphical user interface for managing activations, and for performing other activation-related tasks such as:
- **Adding and removing computers.** You can use VAMT to discover computers in the local environment. VAMT can discover computers by querying AD DS, workgroups, by individual computer name or IP address, or via a general LDAP query.
- **Discovering products.** You can use VAMT to discover Windows, Windows Server, Office, and select other products installed on the client computers.
- **Monitoring activation status.** You can collect activation information about each product, including the last 5 characters of the product key being used, the current license state (such as Licensed, Grace, Unlicensed), and the product edition information.
- **Managing product keys.** You can store multiple product keys and use VAMT to install these keys to remote client products. You can also determine the number of activations remaining for MAKs.
- **Managing activation data.** VAMT stores activation data in a SQL database. VAMT can export this data to other VAMT hosts or to an archive in XML format.
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
 

17
windows/deploy/key-features-in-mdt-2013.md
View File

@ -2,17 +2,21 @@
title: Key features in MDT 2013 Update 2 (Windows 10)
description: The Microsoft Deployment Toolkit (MDT) has been in existence since 2003, when it was first introduced as Business Desktop Deployment (BDD) 1.0.
ms.assetid: 858e384f-e9db-4a93-9a8b-101a503e4868
ms.pagetype: mdt
keywords: ["deploy, feature, tools, upgrade, migrate, provisioning"]
keywords: deploy, feature, tools, upgrade, migrate, provisioning
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Key features in MDT 2013 Update 2
**Applies to**
- Windows 10
The Microsoft Deployment Toolkit (MDT) has been in existence since 2003, when it was first introduced as Business Desktop Deployment (BDD) 1.0. The toolkit has evolved, both in functionality and popularity, and today it is considered fundamental to Windows operating system and enterprise application deployment.
MDT 2013 has many useful features, the most important of which are:
- **Windows Client support.** Supports Windows 7, Windows 8, Windows 8.1, and Windows 10.
- **Windows Server support.** Supports Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.
@ -20,8 +24,11 @@ MDT 2013 has many useful features, the most important of which are:
- **UEFI support.** Supports deployment to machines using Unified Extensible Firmware Interface (UEFI) version 2.3.1.
- **GPT support.** Supports deployment to machines that require the new GUID (globally unique identifier) partition table (GPT) format. This is related to UEFI.
- **Enhanced Windows PowerShell support.** Provides support for running PowerShell scripts.
![figure 2](images/mdt-05-fig02.png)
Figure 2. The deployment share mounted as a standard PSDrive allows for administration using PowerShell.
- **Add local administrator accounts.** Allows you to add multiple user accounts to the local Administrators group on the target computers, either via settings or the deployment wizard.
- **Automated participation in CEIP and WER.** Provides configuration for participation in Windows Customer Experience Improvement Program (CEIP) and Windows Error Reporting (WER).
- **Deploy Windows RE.** Enables deployment of a customized Windows Recovery Environment (Windows RE) as part of the task sequence.
@ -32,8 +39,11 @@ MDT 2013 has many useful features, the most important of which are:
- **Partitioning routines.** Provides improved partitioning routines to ensure that deployments work regardless of the current hard drive structure.
- **Offline BitLocker.** Provides the capability to have BitLocker enabled during the Windows Preinstallation Environment (Windows PE) phase, thus saving hours of encryption time.
- **USMT offline user-state migration.** Provides support for running the User State Migration Tool (USMT) capture offline, during the Windows PE phase of the deployment.
![figure 3](images/mdt-05-fig03.png)
Figure 3. The offline USMT backup in action.
- **Install or uninstall Windows roles or features.** Enables you to select roles and features as part of the deployment wizard. MDT also supports uninstall of roles and features.
- **Microsoft System Center 2012 Orchestrator integration.** Provides the capability to use Orchestrator runbooks as part of the task sequence.
- **Support for DaRT.** Supports optional integration of the DaRT components into the boot image.
@ -41,8 +51,11 @@ MDT 2013 has many useful features, the most important of which are:
- **Support for Modern UI app package provisioning.** Provisions applications based on the new Windows app package standard, which is used in Windows 8 and later.
- **Extensibility.** Provides the capability to extend MDT far beyond the built-in features by adding custom scripts, web services, System Center Orchestrator runbooks, PowerShell scripts, and VBScripts.
- **Upgrade task sequence.** Provides a new upgrade task sequence template that you can use to upgrade existing Windows 7, Windows 8, and Windows 8.1 systems directly to Windows 10, automatically preserving all data, settings, applications, and drivers. For more information about using this new upgrade task sequence, refer to the [Microsoft Deployment Toolkit resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
## Related topics
[Prepare for deployment with MDT 2013 Update 2](prepare-for-windows-deployment-with-mdt-2013.md)
[MDT 2013 Update 2 Lite Touch components](mdt-2013-lite-touch-components.md)
 
 

9
windows/deploy/kms-activation-vamt.md
View File

@ -2,22 +2,28 @@
title: Perform KMS Activation (Windows 10)
description: Perform KMS Activation
ms.assetid: 5a3ae8e6-083e-4153-837e-ab0a225c1d10
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Perform KMS Activation
The Volume Activation Management Tool (VAMT) can be used to perform volume activation using the Key Management Service (KMS). You can use VAMT to activate Generic Volume Licensing Keys, or KMS client keys, on products accessible to VAMT. GVLKs are the default product keys used by the volume-license editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server® 2012, and Microsoft Office 2010. GVLKs are already installed in volume-license editions of these products.
## Requirements
Before configuring KMS activation, ensure that your network and VAMT installation meet the following requirements:
- KMS host is set up and enabled.
- KMS clients can access the KMS host.
- VAMT is installed on a central computer with network access to all client computers.
- The products to be activated have been added to VAMT. For more information on adding product keys, see [Install a KMS Client Key](install-kms-client-key-vamt.md).
- VAMT has administrative permissions on all computers to be activated, and Windows Management Instrumentation (WMI) is accessible through the Windows Firewall. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
## To configure devices for KMS activation
**To configure devices for KMS activation**
1. Open VAMT.
2. If necessary, set up the KMS activation preferences. If you don’t need to set up the preferences, skip to step 6 in this procedure. Otherwise, continue to step 2.
@ -36,4 +42,3 @@ Before configuring KMS activation, ensure that your network and VAMT installatio
10. If you are supplying alternate credentials, at the prompt, type the appropriate user name and password and click **OK**.
VAMT displays the **Volume Activation** dialog box until it completes the requested action. When the process is finished, the updated activation status of each product appears in the product list view in the center pane.
 
 

10
windows/deploy/local-reactivation-vamt.md
View File

@ -2,18 +2,23 @@
title: Perform Local Reactivation (Windows 10)
description: Perform Local Reactivation
ms.assetid: aacd5ded-da11-4d27-a866-3f57332f5dec
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Perform Local Reactivation
If you reinstall Windows® or Microsoft® Office 2010 on a computer that was initially activated using proxy activation (MAK, retail, or CSLVK (KMS host)), and have not made significant changes to the hardware, use this local reactivation procedure to reactivate the program on that computer.
Local reactivation relies upon data that was created during the initial proxy activation and stored in the Volume Activation Management Tool (VAMT) database. The database contains the installation ID (IID) and confirmation ID (Pending CID). Local reactivation uses this data to reapply the CID and reactivate those products. Reapplying the same CID conserves the remaining activations on the key.
**Note**  
During the initial proxy activation, the CID is bound to a digital “fingerprint”, which is calculated from values assigned to several different hardware components in the computer. If the computer has had significant hardware changes, this fingerprint will no longer match the CID. In this case, you must obtain a new CID for the computer from Microsoft.
## To Perform a Local Reactivation
**To perform a local reactivation**
1. Open VAMT. Make sure that you are connected to the desired database.
2. In the left-side pane, click the product you want to reactivate to display the products list.
@ -27,8 +32,11 @@ During the initial proxy activation, the CID is bound to a digital “fingerprin
8. If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and click **OK**.
VAMT displays the **Apply Confirmation ID** dialog box.
10. If you are using a different product key than the product key used for initial activation, you must complete a new activation to obtain a new CID.
11. If you are activating a product that requires administrator credentials different from the ones you are currently using, select the **Use Alternate Credentials** check box.
12. Click **OK**.
## Related topics
- [Manage Activations](manage-activations-vamt.md)

6
windows/deploy/manage-activations-vamt.md
View File

@ -2,15 +2,19 @@
title: Manage Activations (Windows 10)
description: Manage Activations
ms.assetid: 53bad9ed-9430-4f64-a8de-80613870862c
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Manage Activations
This section describes how to activate a client computer, by using a variety of activation methods.
## In this Section
|Topic |Description |
|------|------------|
|[Perform Online Activation](online-activation-vamt.md) |Describes how to activate a client computer over the Internet. |

5
windows/deploy/manage-product-keys-vamt.md
View File

@ -2,15 +2,18 @@
title: Manage Product Keys (Windows 10)
description: Manage Product Keys
ms.assetid: 4c6c4216-b4b7-437c-904e-4cb257f913cd
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Manage Product Keys
This section describes how to add and remove a product key from the Volume Activation Management Tool (VAMT). After you add a product key to VAMT, you can install that product key on a product or products you select in the VAMT database.
## In this Section
|Topic |Description |
|------|------------|
|[Add and Remove a Product Key](add-remove-product-key-vamt.md) |Describes how to add a product key to the VAMT database. |

5
windows/deploy/manage-vamt-data.md
View File

@ -2,14 +2,17 @@
title: Manage VAMT Data (Windows 10)
description: Manage VAMT Data
ms.assetid: 233eefa4-3125-4965-a12d-297a67079dc4
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Manage VAMT Data
This section describes how to save, import, export, and merge a Computer Information List (CILX) file using the Volume Activation Management Tool (VAMT).
## In this Section
|Topic |Description |
|------|------------|

43
windows/deploy/mdt-2013-lite-touch-components.md
View File

@ -2,52 +2,80 @@
title: MDT 2013 Update 2 Lite Touch components (Windows 10)
description: This topic provides an overview of the features in the Microsoft Deployment Toolkit (MDT) 2013 Update 2 that support Lite Touch Installation (LTI) for Windows 10.
ms.assetid: 7d6fc159-e338-439e-a2e6-1778d0da9089
ms.pagetype: mdt
keywords: ["deploy, install, deployment, boot, log, monitor"]
keywords: deploy, install, deployment, boot, log, monitor
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# MDT 2013 Update 2 Lite Touch components
**Applies to**
- Windows 10
This topic provides an overview of the features in the Microsoft Deployment Toolkit (MDT) 2013 Update 2 that support Lite Touch Installation (LTI) for Windows 10. An LTI deployment strategy requires very little infrastructure or user interaction, and can be used to deploy an operating system from a network share or from a physical media, such as a USB flash drive or disc.
When deploying the Windows operating system using MDT, most of the administration and configuration is done through the Deployment Workbench, but you also can perform many of the tasks using Windows PowerShell. The easiest way to find out how to use PowerShell in MDT is to use the Deployment Workbench to perform an operation and at the end of that task, click View Script. That will give you the PowerShell command.
![figure 4](images/mdt-05-fig04.png)
Figure 4. If you click **View Script** on the right side, you will get the PowerShell code that was used to perform the task.
## <a href="" id="sec01"></a>Deployment shares
A deployment share is essentially a folder on the server that is shared and contains all the setup files and scripts needed for the deployment solution. It also holds the configuration files (called rules) that are gathered when a machine is deployed. These configuration files can reach out to other sources, like a database, external script, or web server to get additional settings for the deployment. For Lite Touch deployments, it is common to have two deployment shares: one for creating the reference images and one for deployment. For Zero Touch, it is common to have only the deployment share for creating reference images because Microsoft System Center 2012 R2 Configuration Manager deploys the image in the production environment.
## <a href="" id="sec02"></a>Rules
The rules (CustomSettings.ini and Bootstrap.ini) make up the brain of MDT. The rules control the Windows Deployment Wizard on the client and, for example, can provide the following settings to the machine being deployed:
- Computer name
- Domain to join, and organizational unit (OU) in Active Directory to hold the computer object
- Whether to enable BitLocker
- Regional settings
You can manage hundreds of settings in the rules. For more information, see the [Microsoft Deployment Toolkit resource center](http://go.microsoft.com/fwlink/p/?LinkId=618117).
![figure 5](images/mdt-05-fig05.png)
Figure 5. Example of a MDT rule. In this example, the new computer name is being calculated based on PC- plus the first seven (Left) characters from the serial number
## <a href="" id="sec03"></a>Boot images
Boot images are the Windows Preinstallation Environment (Windows PE) images that are used to start the deployment. They can be started from a CD or DVD, an ISO file, a USB device, or over the network using a Pre-Boot Execution Environment (PXE) server. The boot images connect to the deployment share on the server and start the deployment.
Boot images are the Windows Preinstallation Environment (Windows PE) images that are used to start the deployment. They can be started from a CD or DVD, an ISO file, a USB device, or over the network using a Pre-Boot Execution Environment (PXE) server. The boot images connect to the deployment
share on the server and start the deployment.
## <a href="" id="sec04"></a>Operating systems
Using the Deployment Workbench, you import the operating systems you want to deploy. You can import either the full source (like the full Windows 10 DVD/ISO) or a custom image that you have created. The full-source operating systems are primarily used to create reference images; however, they also can be used for normal deployments.
## <a href="" id="sec05"></a>Applications
Using the Deployment Workbench, you also add the applications you want to deploy. MDT supports virtually every executable Windows file type. The file can be a standard .exe file with command-line switches for an unattended install, a Microsoft Windows Installer (MSI) package, a batch file, or a VBScript. In fact, it can be just about anything that can be executed unattended. MDT also supports the new Universal Windows apps.
## <a href="" id="sec06"></a>Driver repository
You also use the Deployment Workbench to import the drivers your hardware needs into a driver repository that lives on the server, not in the image.
## <a href="" id="sec07"></a>Packages
With the Deployment Workbench, you can add any Microsoft packages that you want to use. The most commonly added packages are language packs, and the Deployment Workbench Packages node works well for those. You also can add security and other updates this way. However, we generally recommend that you use Windows Server Update Services (WSUS) for operating system updates. The rare exceptions are critical hotfixes that are not available via WSUS, packages for the boot image, or any other package that needs to be deployed before the WSUS update process starts.
## <a href="" id="sec08"></a>Task sequences
Task sequences are the heart and soul of the deployment solution. When creating a task sequence, you need to select a template. The templates are located in the Templates folder in the MDT installation directory, and they determine which default actions are present in the sequence.
You can think of a task sequence as a list of actions that need to be executed in a certain order. Each action can also have conditions. Some examples of actions are as follows:
- **Gather.** Reads configuration settings from the deployment server.
- **Format and Partition.** Creates the partition(s) and formats them.
- **Inject Drivers.** Finds out which drivers the machine needs and downloads them from the central driver repository.
- **Apply Operating System.** Uses ImageX to apply the image.
- **Windows Update.** Connects to a WSUS server and updates the machine.
## <a href="" id="sec09"></a>Task sequence templates
MDT comes with nine default task sequence templates. You can also create your own templates. As long as you store them in the Templates folder, they will be available when you create a new task sequence.
- **Sysprep and Capture task sequence.** Used to run the System Preparation (Sysprep) tool and capture an image of a reference computer.
**Note**  
It is preferable to use a complete build and capture instead of the Sysprep and Capture task sequence. A complete build and capture can be automated, whereas Sysprep and Capture cannot.
 
@ -60,22 +88,31 @@ MDT comes with nine default task sequence templates. You can also create your ow
- **Deploy to VHD Client task sequence.** Similar to the Standard Client task sequence template but also creates a virtual hard disk (VHD) file on the target computer and deploys the image to the VHD file.
- **Deploy to VHD Server task sequence.** Same as the Deploy to VHD Client task sequence but for servers.
- **Standard Client Upgrade task sequence.** A simple task sequence template used to perform an in-place upgrade from Windows 7, Windows 8, or Windows 8.1 directly to Windows 10, automatically preserving existing data, settings, applications, and drivers.
## <a href="" id="sec10"></a>Selection profiles
Selection profiles, which are available in the Advanced Configuration node, provide a way to filter content in the Deployment Workbench. Selection profiles are used for several purposes in the Deployment Workbench and in Lite Touch deployments. For example, they can be used to:
- Control which drivers and packages are injected into the Lite Touch (and generic) boot images.
- Control which drivers are injected during the task sequence.
- Control what is included in any media that you create.
- Control what is replicated to other deployment shares.
- Filter which task sequences and applications are displayed in the Deployment Wizard.
## <a href="" id="sec11"></a>Logging
MDT uses many log files during operating system deployments. By default the logs are client side, but by configuring the deployment settings, you can have MDT store them on the server, as well.
**Note**  
The easiest way to view log files is to use Configuration Manager Trace (CMTrace), which is included in the [System Center 2012 R2 Configuration Manager Toolkit](http://go.microsoft.com/fwlink/p/?LinkId=734717).
 
## <a href="" id="sec12"></a>Monitoring
On the deployment share, you also can enable monitoring. After you enable monitoring, you will see all running deployments in the Monitor node in the Deployment Workbench.
## Related topics
[Key features in MDT 2013 Update 2](key-features-in-mdt-2013.md)
[Prepare for deployment with MDT 2013 Update 2](prepare-for-windows-deployment-with-mdt-2013.md)
 
 

11
windows/deploy/monitor-activation-client.md
View File

@ -1,15 +1,17 @@
---
title: Monitor activation (Windows 10)
ms.assetid: 264a3e86-c880-4be4-8828-bf4c839dfa26
ms.pagetype: activation
description:
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: CFaw
---
# Monitor activation
**Applies to**
- Windows 10
- Windows 8.1
@ -18,8 +20,11 @@ author: CFaw
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
You can monitor the success of the activation process for a computer running Windows 8.1 in several ways. The most popular methods include:
- Using the Volume Licensing Service Center website to track use of MAK keys.
- Using the **Slmgr /dlv** command on a client computer or on the KMS host. (For a full list of options, see [Slmgr.vbs Options](http://technet.microsoft.com/library/ff793433.aspx).)
@ -27,7 +32,9 @@ You can monitor the success of the activation process for a computer running Win
- Most licensing actions and events are recorded in the Event log.
- Microsoft System Center Operations Manager and the KMS Management Pack can provide insight and information to users of System Center Operations Manager.
- The VAMT provides a single site from which to manage and monitor volume activations. This is explained in the next section.
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
 
 

15
windows/deploy/online-activation-vamt.md
View File

@ -2,22 +2,30 @@
title: Perform Online Activation (Windows 10)
description: Perform Online Activation
ms.assetid: 8381792b-a454-4e66-9b4c-e6e4c9303823
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Perform Online Activation
You can use the Volume Activation Management Tool (VAMT) to enable client products to be activated over the Internet. You can install the client products with any kind of product key that is eligible for online activation—Multiple Activation Key (MAK), retail, and Windows Key Management Services (KMS) host key.
## Requirements
Before performing online activation, ensure that the network and the VAMT installation meet the following requirements:
- VAMT is installed on a central computer that has network access to all client computers.
- Both the VAMT host and client computers have Internet access.
- The products that you want to activate are added to VAMT.
- VAMT has administrative permissions on all computers that you intend to activate, and that Windows Management Instrumentation (WMI) can be accessed through the Windows firewall. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
The product keys that are installed on the client products must have a sufficient number of remaining activations. If you are activating a MAK key, you can retrieve the remaining number of activations for that key by selecting the MAK in the product key list in the center pane and then clicking **Refresh product key data online** in the right-side pane. This retrieves the number of remaining activations for the MAK from Microsoft. Note that this step requires Internet access and that the remaining activation count can only be retrieved for MAKs.
The product keys that are installed on the client products must have a sufficient number of remaining activations. If you are activating a MAK key, you can retrieve the remaining number of activations for that key by selecting the MAK in the product key list in the center pane and then clicking
**Refresh product key data online** in the right-side pane. This retrieves the number of remaining activations for the MAK from Microsoft. Note that this step requires Internet access and that the remaining activation count can only be retrieved for MAKs.
## To Perform an Online Activation
**To perform an online activation**
1. Open VAMT.
2. In the products list view in the center pane, sort the list if necessary. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
@ -29,11 +37,14 @@ The product keys that are installed on the client products must have a sufficien
6. Click **Activate** in the **Selected Items** menu in the right-side **Actions** pane and then point to **Activate**. If the **Actions** pane is not displayed, click the Show/Hide Action Pane button, which is located on the toolbar to the right of the Help button.
7. Point to **Online activate**, and then select the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
8. VAMT displays the **Activating products** dialog box until it completes the requested action. When activation is complete, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the products list view in the center pane.
**Note**  
Online activation does not enable you to save the Confirmation IDs (CIDs). As a result, you cannot perform local reactivation.
**Note**
You can use online activation to select products that have different key types and activate the products at the same time.
## Related topics
- [Manage Activations](manage-activations-vamt.md)

90
windows/deploy/plan-for-volume-activation-client.md
View File

@ -2,14 +2,16 @@
title: Plan for volume activation (Windows 10)
description: Product activation is the process of validating software with the manufacturer after it has been installed on a specific computer.
ms.assetid: f84b005b-c362-4a70-a84e-4287c0d2e4ca
ms.pagetype: activation
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Plan for volume activation
**Applies to**
- Windows 10
- Windows 8.1
@ -18,87 +20,147 @@ author: jdeckerMS
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
*Product activation* is the process of validating software with the manufacturer after it has been installed on a specific computer. Activation confirms that the product is genuine—not a fraudulent copy—and that the product key or serial number is valid and has not been compromised or revoked. Activation also establishes a link or relationship between the product key and the particular installation.
During the activation process, information about the specific installation is examined. In the case of online activations, this information is sent to a server at Microsoft. This information may include the software version, the product key, the IP address of the computer, and information about the device. The activation methods that Microsoft uses are designed to help protect user privacy, and they cannot be used to track back to the computer or user. The gathered data confirms that the software is a legally licensed copy, and this data is used for statistical analysis. Microsoft does not use this information to identify or contact the user or the organization.
**Note**  
The IP address is used only to verify the location of the request, because some editions of Windows (such as “Starter” editions) can only be activated within certain geographical target markets.
## Distribution channels and activation
In general, Microsoft software is obtained through three main channels: retail, original equipment manufacturer (OEM), and volume licensing agreements. Different activations methods are available through each channel. Because organizations are free to obtain software through multiple channels (for example, buying some at retail and others through a volume licensing program) most organizations choose to use a combination of activation methods.
### Retail activations
The retail activation method has not changed in several versions of Windows and Windows Server. Each purchased copy comes with one unique product key (often referred to as a retail key). The user enters this key during product installation. The computer uses this retail key to complete the activation after the installation is complete. Most activations are performed online, but telephone activation is also available.
Recently, retail keys have been expanded into new distribution scenarios. Product key cards are available to activate products that have been preinstalled or downloaded. Programs such as Windows Anytime Upgrade and Get Genuine allow users to acquire legal keys separately from the software. These electronically distributed keys may come with media that contains software, they can come as a software shipment, or they may be provided on a printed card or electronic copy. Products are activated the same way with any of these retail keys.
### Original equipment manufacturer
Most original equipment manufacturers (OEMs) sell systems that include a standard build of the Windows operating system. The hardware vendor activates Windows by associating the operating system with the firmware (BIOS) of the computer. This occurs before the computer is sent to the customer, and no additional actions are required.
OEM activation is valid as long as the customer uses the OEM-provided image on the system. OEM activation is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled.
### Volume licensing
Volume licensing offers customized programs that are tailored to the size and purchasing preference of the organization. To become a volume licensing customer, the organization must set up a volume licensing agreement with Microsoft.There is a common misunderstanding about acquiring licenses for a new computer through volume licensing. There are two legal ways to acquire a full Windows client license for a new computer:
- Have the license preinstalled through the OEM.
- Purchase a fully packaged retail product.
The licenses that are provided through volume licensing programs such as Open License, Select License, and Enterprise Agreements cover upgrades to Windows client operating systems only. An existing retail or OEM operating system license is needed for each computer running Windows 10, Windows 8.1 Pro, Windows 8 Pro, Windows 7 Professional or Ultimate, or Windows XP Professional before the upgrade rights obtained through volume licensing can be exercised.
Volume licensing is also available through certain subscription or membership programs, such as the Microsoft Partner Network and MSDN. These volume licenses may contain specific restrictions or other changes to the general terms applicable to volume licensing.
**Note**  
Some editions of the operating system, such as Windows 10 Enterprise, and some editions of application software are available only through volume licensing agreements or subscriptions.
## Activation models
For a user or IT department, there are no significant choices about how to activate products that are acquired through retail or OEM channels. The OEM performs the activation at the factory, and the user or the IT department need take no activation steps.
With a retail product, the Volume Activation Management Tool (VAMT), which is discussed later in this guide, helps you track and manage keys. For each retail activation, you can choose:
- Online activation
- Telephone activation
- VAMT proxy activation
Telephone activation is primarily used in situations where a computer is isolated from all networks. VAMT proxy activation (with retail keys) is sometimes used when an IT department wants to centralize retail activations or when a computer with a retail version of the operating system is isolated from the Internet but connected to the LAN. For volume-licensed products, however, you must determine the best method or combination of methods to use in your environment. For Windows 10 Pro and Enterprise, you can choose from three models:
- MAKs
- KMS
- Active Directory-based activation
**Note**  
A specialized method, Token-based activation, is available for specific situations when approved customers rely on a public key infrastructure in a completely isolated, and usually high-security, environment. For more information, contact your Microsoft Account Team or your service representative.
### Multiple activation key
A Multiple Activation Key (MAK) is commonly used in small- or mid-sized organizations that have a volume licensing agreement, but they do not meet the requirements to operate a KMS or they prefer a simpler approach. A MAK also allows permanent activation of computers that are isolated from the KMS or are part of an isolated network that does not have enough computers to use the KMS.
A Multiple Activation Key (MAK) is commonly used in small- or mid-sized organizations that have a volume licensing agreement, but they do not meet the requirements to operate a KMS or they prefer a simpler approach. A MAK also
allows permanent activation of computers that are isolated from the KMS or are part of an isolated network that does not have enough computers to use the KMS.
To use a MAK, the computers to be activated must have a MAK installed. The MAK is used for one-time activation with the Microsoft online hosted activation services, by telephone, or by using VAMT proxy activation.
In the simplest terms, a MAK acts like a retail key, except that a MAK is valid for activating multiple computers. Each MAK can be used a specific number of times. The VAMT can assist in tracking the number of activations that have been performed with each key and how many remain.
Organizations can download MAK and KMS keys from the [Volume Licensing Service Center](http://go.microsoft.com/fwlink/p/?LinkId=618213) website. Each MAK has a preset number of activations, which are based on a percentage of the count of licenses the organization purchases; however, you can increase the number of activations that are available with your MAK by calling Microsoft.
### Key Management Service
With the Key Management Service (KMS), IT pros can complete activations on their local network, eliminating the need for individual computers to connect to Microsoft for product activation. The KMS is a lightweight service that does not require a dedicated system and can easily be cohosted on a system that provides other services.
Volume editions of Windows 10 and Windows Server 2012 R2 (in addition to volume editions of operating system editions since Windows Vista and Windows Server 2008) automatically connect to a system that hosts the KMS to request activation. No action is required from the user.
The KMS requires a minimum number of computers (physical computers or virtual machines) in a network environment. The organization must have at least five computers to activate Windows Server 2012 R2 and at least 25 computers to activate client computers that are running Windows 10. These minimums are referred to as *activation thresholds*.
Planning to use the KMS includes selecting the best location for the KMS host and how many KMS hosts to have. One KMS host can handle a large number of activations, but organizations will often deploy two KMS hosts to ensure availability. Only rarely would more than two KMS hosts be used. The KMS can be hosted on a client computer or on a server, and it can be run on older versions of the operating system if proper configuration steps are taken. Setting up your KMS is discussed later in this guide.
### Active Directory-based activation
Active Directory-based activation is the newest type of volume activation, and it was introduced in Windows 8. In many ways, Active Directory-based activation is similar to activation by using the KMS, but the activated computer does not need to maintain periodic connectivity with the KMS host. Instead, a domain-joined computer running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2 queries AD DS for a volume activation object that is stored in the domain. The operating system checks the digital signatures that are contained in the activation object, and then activates the device.
Active Directory-based activation allows enterprises to activate computers through a connection to their domain. Many companies have computers at remote or branch locations, where it is impractical to connect to a KMS, or would not reach the KMS activation threshold. Rather than use MAKs, Active Directory-based activation provides a way to activate computers running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2 as long as the computers can contact the company’s domain. Active Directory-based activation offers the advantage of extending volume activation services everywhere you already have a domain presence.
## Network and connectivity
A modern business network has many nuances and interconnections. This section examines evaluating your network and the connections that are available to determine how volume activations will occur.
### Core network
Your core network is that part of your network that enjoys stable, high-speed, reliable connectivity to infrastructure servers. In many cases, the core network is also connected to the Internet, although that is not a requirement to use the KMS or Active Directory-based activation after the KMS server or AD DS is configured and active. Your core network likely consists of many network segments. In many organizations, the core network makes up the vast majority of the business network.
In the core network, a centralized KMS solution is usually recommended. You can also use Active Directory-based activation, but in many organizations, KMS will still be required to activate older client computers and computers that are not joined to the domain. Some administrators prefer to run both solutions to have the most flexibility, while others prefer to choose only a KMS-based solution for simplicity. Active Directory-based activation as the only solution is workable if all of the clients in your organization are running Windows 10, Windows 8.1, or Windows 8.
A typical core network that includes a KMS host is shown in Figure 1.
![Typical core network](images/volumeactivationforwindows81-01.jpg)
**Figure 1**. Typical core network
### Isolated networks
In a large network, it is all but guaranteed that some segments will be isolated, either for security reasons or because of geography or connectivity issues.
**Isolated for security**<p>
**Isolated for security**
Sometimes called a *high-security zone*, a particular network segment may be isolated from the core network by a firewall or disconnected from other networks totally. The best solution for activating computers in an isolated network depends on the security policies in place in the organization.
If the isolated network can access the core network by using outbound requests on TCP port 1688, and it is allowed to receive remote procedure calls (RPCs), you can perform activation by using the KMS in the core network, thereby avoiding the need to reach additional activation thresholds.
If the isolated network participates fully in the corporate forest, and it can make typical connections to domain controllers, such as using Lightweight Directory Access Protocol (LDAP) for queries and Domain Name Service (DNS) for name resolution, this is a good opportunity to use Active Directory-based activation for Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, and Windows Server 2012 R2.
If the isolated network cannot communicate with the core network’s KMS server, and it cannot use Active Directory-based activation, you can set up a KMS host in the isolated network. This configuration is shown in Figure 2. However, if the isolated network contains only a few computers, it will not reach the KMS activation threshold. In that case, you can activate by using MAKs.
If the network is fully isolated, MAK-independent activation would be the recommended choice, perhaps using the telephone option. But VAMT proxy activation may also be possible. You can also use MAKs to activate new computers during setup, before they are placed in the isolated network.
![New KMS host in an isolated network](images/volumeactivationforwindows81-02.jpg)
**Figure 2**. New KMS host in an isolated network
**Branch offices and distant networks**
From mining operations to ships at sea, organizations often have a few computers that are not easily connected to the core network or the Internet. Some organizations have network segments at branch offices that are large and well-connected internally, but have a slow or unreliable WAN link to the rest of the organization. In these situations, you have several options:
- **Active Directory-based activation**. In any site where the client computers are running Windows 10, Active Directory-based activation is supported, and it can be activated by joining the domain.
- **Local KMS**. If a site has 25 or more client computers, it can activate against a local KMS server.
- **Remote (core) KMS**. If the remote site has connectivity to an existing KMS (perhaps through a virtual private network (VPN) to the core network), that KMS can be used. Using the existing KMS means that you only need to meet the activation threshold on that server.
- **MAK activation**. If the site has only a few computers and no connectivity to an existing KMS host, MAK activation is the best option.
### Disconnected computers
Some users may be in remote locations or may travel to many locations. This scenario is common for roaming clients, such as the computers that are used by salespeople or other users who are offsite but not at branch locations. This scenario can also apply to remote branch office locations that have no connection to the core network. You can consider this an “isolated network,” where the number of computers is one. Disconnected computers can use Active Directory-based activation, the KMS, or MAK depending on the client version and how often the computers connect to the core network.
If the computer is joined to the domain and running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2 8, you can use Active Directory-based activation—directly or through a VPN—at least once every 180 days. If the computer connects to a network with a KMS host at least every 180 days, but it does not support Active Directory-based activation, you can use KMS activation. Otherwise for computers that rarely or never connect to the network, use MAK independent activation (by using the telephone or the Internet).
### Test and development labs
Lab environments often have large numbers of virtual machines, and physical computers and virtual machines in labs are reconfigured frequently. Therefore, first determine whether the computers in test and development labs require activation. Editions of Windows 10 that include volume licensing will operate normally, even if they cannot activate immediately.
If you have ensured that your test or development copies of the operating system are within the license agreement, you may not need to activate the lab computers if they will be rebuilt frequently. If you require that the lab computers be activated, treat the lab as an isolated network and use the methods described earlier in this guide.
In labs that have a high turnover of computers and a small number of KMS clients, you must monitor the KMS activation count. You might need to adjust the time that the KMS caches the activation requests. The default is 30 days.
## Mapping your network to activation methods
Now it’s time to assemble the pieces into a working solution. By evaluating your network connectivity, the numbers of computers you have at each site, and the operating system versions in use in your environment, you have collected the information you need to determine which activation methods will work best for you. You can fill-in information in Table 1 to help you make this determination.
**Table 1**. Criteria for activation methods
|Criterion |Activation method |
|----------|------------------|
|Number of domain-joined computers that support Active Directory-based activation (computers running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 R2) and will connect to a domain controller at least every 180 days. Computers can be mobile, semi-isolated, or located in a branch office or the core network. |Active Directory-based activation |
@ -110,25 +172,40 @@ Now it’s time to assemble the pieces into a working solution. By evaluating yo
|Number of computers in test and development labs that will not be activated |None|
|Number of computers that do not have a retail volume license |Retail (online or phone) |
|Number of computers that do not have an OEM volume license |OEM (at factory) |
|Total number of computer activations<p><strong>Note</strong><br>This total should match the total number of licensed computers in your organization. | |
|Total number of computer activations<p><strong>Note</strong><br>This total should match the total number of licensed computers in your organization. |
## Choosing and acquiring keys
When you know which keys you need, you must obtain them. Generally speaking, volume licensing keys are collected in two ways:
- Go to the **Product Keys** section of the [Volume Licensing Service Center](http://go.microsoft.com/fwlink/p/?LinkID=618213) for the following agreements: Open, Open Value, Select, Enterprise, and Services Provider License.
- Contact your [Microsoft Activation Center](http://go.microsoft.com/fwlink/p/?LinkId=618264).
### KMS host keys
A KMS host needs a key that activates, or authenticates, the KMS host with Microsoft. This key is usually referred to as the *KMS host key*, but it is formally known as a *Microsoft Customer Support Volume License Key* (CSVLK). Most documentation and Internet references earlier than Windows 8.1 use the term KMS key, but CSVLK is becoming more common in current documentation and management tools.
A KMS host running Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 can activate both Windows Server and Windows client operating systems. A KMS host key is also needed to create the activation objects in AD DS, as described later in this guide. You will need a KMS host key for any KMS that you want to set up and if you are going to use Active Directory-based activation.
### Generic volume licensing keys
When you create installation media or images for client computers that will be activated by KMS or Active Directory-based activation, install a generic volume license key (GVLK) for the edition of Windows you are creating. GVLKs are also referred to as KMS client setup keys.
Installation media from Microsoft for Enterprise editions of the Windows operating system may already contain the GVLK. One GVLK is available for each type of installation. Note that the GLVK will not activate the software against Microsoft activation servers, only against a KMS or Active Directory-based activation object. In other words, the GVLK does not work unless a valid KMS host key can be found. GVLKs are the only product keys that do not need to be kept confidential.
Typically, you will not need to manually enter a GVLK unless a computer has been activated with a MAK or a retail key and it is being converted to a KMS activation or to Active Directory-based activation. If you need to locate the GVLK for a particular client edition, see [Appendix A: KMS Client Setup Keys](http://technet.microsoft.com/library/jj612867.aspx).
### Multiple activation keys
You will also need MAK keys with the appropriate number of activations available. You can see how many times a MAK has been used on the Volume Licensing Service Center website or in the VAMT.
## Selecting a KMS host
The KMS does not require a dedicated server. It can be cohosted with other services, such as AD DS domain controllers and read-only domain controllers.
KMS hosts can run on physical computers or virtual machines that are running any supported Windows operating system. A KMS host that is running Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 can activate any Windows client or server operating system that supports volume activation. A KMS host that is running Windows 10 can activate only computers running Windows 10, Windows 8.1, Windows 8, Windows 7, or Windows Vista.
A single KMS host can support unlimited numbers of KMS clients, but Microsoft recommends deploying a minimum of two KMS hosts for failover purposes. However, as more clients are activated through Active Directory-based activation, the KMS and the redundancy of the KMS will become less important. Most organizations can use as few as two KMS hosts for their entire infrastructure.
The flow of KMS activation is shown in Figure 3, and it follows this sequence:
1. An administrator uses the VAMT console to configure a KMS host and install a KMS host key.
2. Microsoft validates the KMS host key, and the KMS host starts to listen for requests.
3. The KMS host updates resource records in DNS to allow clients to locate the KMS host. (Manually adding DNS records is required if your environment does not support DNS dynamic update protocol.)
@ -137,8 +214,11 @@ The flow of KMS activation is shown in Figure 3, and it follows this sequence:
6. The KMS host records information about the requesting client (by using a client ID). Client IDs are used to maintain the count of clients and detect when the same computer is requesting activation again. The client ID is only used to determine whether the activation thresholds are met. The IDs are not stored permanently or transmitted to Microsoft. If the KMS is restarted, the client ID collection starts again.
7. If the KMS host has a KMS host key that matches the products in the GVLK, the KMS host sends a single packet back to the client. This packet contains a count of the number of computers that have requested activation from this KMS host.
8. If the count exceeds the activation threshold for the product that is being activated, the client is activated. If the activation threshold has not yet been met, the client will try again.
![KMS activation flow](images/volumeactivationforwindows81-03.jpg)
**Figure 3**. KMS activation flow
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
 

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

@ -2,19 +2,25 @@
title: Prepare for deployment with MDT 2013 Update 2 (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) 2013 Update 2.
ms.assetid: 5103c418-0c61-414b-b93c-a8e8207d1226
ms.pagetype: mdt
keywords: ["deploy, system requirements"]
keywords: deploy, system requirements
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Prepare for deployment with MDT 2013 Update 2
**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) 2013 Update 2. 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 2013 Update 2 requires the following components:
- Any of the following operating systems:
- Windows 7
@ -27,7 +33,9 @@ MDT 2013 Update 2 requires the following components:
- 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](http://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 **P@ssw0rd**.
2. Start the **ADK Setup** (E:\\Downloads\\ADK\\adksetup.exe), and on the first wizard page, click **Continue**.
@ -35,11 +43,16 @@ These steps assume that you have the MDT01 member server installed and configure
1. Deployment Tools
2. Windows Preinstallation Environment (Windows PE)
3. User State Migration Tool (UMST)
## <a href="" id="sec03"></a>Install MDT 2013 Update 2
These steps assume that you have downloaded [MDT 2013 Update 2](http://go.microsoft.com/fwlink/p/?LinkId=618117 ) to the E:\\Downloads\\MDT 2013 folder on MDT01.
1. On MDT01, log on as Administrator in the CONTOSO domain using a password of **P@ssw0rd**.
2. Install **MDT** (E:\\Downloads\\MDT 2013\\MicrosoftDeploymentToolkit2013\_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 2013 Update 2.
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:
@ -55,9 +68,13 @@ If you do not have an organizational unit (OU) structure in your Active Director
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:
@ -67,8 +84,11 @@ When creating a reference image, you need an account for MDT. The MDT Build Acco
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
@ -76,16 +96,25 @@ By default MDT stores the log files locally on the client. In order to capture a
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](http://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 2013 Update 2](key-features-in-mdt-2013.md)
[MDT 2013 Update 2 Lite Touch components](mdt-2013-lite-touch-components.md)
 
 

12
windows/deploy/proxy-activation-vamt.md
View File

@ -2,26 +2,35 @@
title: Perform Proxy Activation (Windows 10)
description: Perform Proxy Activation
ms.assetid: 35a919ed-f1cc-4d10-9c88-9bd634549dc3
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Perform Proxy Activation
You can use the Volume Activation Management Tool (VAMT) to perform activation for client computers that do not have Internet access. The client products can be installed with any type of product key that is eligible for proxy activation: Multiple activation Key (MAK), KMS Host key (CSVLK), or retail key.
In a typical proxy-activation scenario, the VAMT host computer distributes a MAK to one or more client computers and collects the installation ID (IID) from each computer. The VAMT host computer sends the IIDs to Microsoft on behalf of the client computers and obtains the corresponding Confirmation IDs (CIDs). The VAMT host computer then installs the CIDs on the client computer to complete the activation. Using this activation method, only the VAMT host computer needs Internet access.
**Note**  
For workgroups that are completely isolated from any larger network, you can still perform MAK, KMS Host key (CSVLK), or retail proxy activation. This requires installing a second instance of VAMT on a computer within the isolated group and using removable media to transfer activation data between that computer and another VAMT host computer that has Internet access. For more information about this scenario, see [Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md). Similarly, you can proxy activate a KMS Host key (CSVLK) located in an isolated network. You can also proxy activate a KMS Host key (CSVLK) in the core network if you do not want the KMS host computer to connect to Microsoft over the Internet. 
## Requirements
Before performing proxy activation, ensure that your network and the VAMT installation meet the following requirements:
- There is an instance of VAMT that is installed on a computer that has Internet access. If you are performing proxy activation for an isolated workgroup, you also need to have VAMT installed on one of the computers in the workgroup.
- The products to be activated have been added to VAMT and are installed with a retail product key, a KMS Host key (CSVLK) or a MAK. If the products have not been installed with a proper product key, refer to the steps in the [Add and Remove a Product Key](add-remove-product-key-vamt.md) section for instructions on how to install a product key.
- VAMT has administrative permissions on all products to be activated and Windows Management Instrumentation (WMI) is accessible through the Windows firewall.
- For workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
The product keys that are installed on the client products must have a sufficient number of remaining activations. If you are activating a MAK key, you can retrieve the remaining number of activations for that key by selecting the MAK in the product key list in the center pane and then clicking **Refresh product key data online** in the right-side pane. This retrieves the number of remaining activations for the MAK from Microsoft. Note that this step requires Internet access and that the remaining activation count can only be retrieved for MAKs.
## To Perform Proxy Activation
**To perform proxy activation**
1. Open VAMT.
2. If necessary, install product keys. For more information see:
- [Install a Product Key](install-product-key-vamt.md) to install retail, MAK, or KMS Host key (CSVLK).
@ -36,6 +45,7 @@ The product keys that are installed on the client products must have a sufficien
8. If you are activating products that require administrator credentials different from the ones you are currently using, select the **Use Alternate Credentials** checkbox.
9. Click **OK**.
10. VAMT displays the **Activating products** dialog box until it completes the requested action. If you selected the **Alternate Credentials** option, you will be prompted to enter the credentials.
**Note**  
You can use proxy activation to select products that have different key types and activate the products at the same time.
 

40
windows/deploy/refresh-a-windows-7-computer-with-windows-10.md
View File

@ -2,21 +2,29 @@
title: Refresh a Windows 7 computer with Windows 10 (Windows 10)
description: This topic will show you how to use MDT 2013 Update 2 Lite Touch Installation (LTI) to upgrade a Windows 7 computer to a Windows 10 computer using the computer refresh process.
ms.assetid: 2866fb3c-4909-4c25-b083-6fc1f7869f6f
ms.pagetype: mdt
keywords: ["reinstallation, customize, template, script, restore"]
keywords: reinstallation, customize, template, script, restore
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Refresh a Windows 7 computer with Windows 10
**Applies to**
- Windows 10
This topic will show you how to use MDT 2013 Update 2 Lite Touch Installation (LTI) to upgrade a Windows 7 computer to a Windows 10 computer using the computer refresh process. The refresh scenario, or computer refresh, is a reinstallation of an operating system on the same machine. You can refresh the machine to the same operating system as it is currently running, or to a later version.
For the purposes of this topic, we will use three machines: DC01, MDT01, and PC0001. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 Standard server. PC0001 is a machine with Windows 7 Service Pack 1 (SP1) that is going to be refreshed into a Windows 10 machine, with data and settings restored. MDT01 and PC0001 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-04-fig01.png)
Figure 1. The machines used in this topic.
## <a href="" id="sec01"></a>The computer refresh process
Even though a computer will appear, to the end user, to be upgraded, a computer refresh is not, technically, an in-place upgrade. A computer refresh also involves taking care of user data and settings from the old installation and making sure to restore those at the end of the installation.
For a computer refresh with MDT, you use the User State Migration Tool (USMT), which is part of the Windows Assessment and Deployment Kit (ADK) for Windows 10, to migrate user data and settings. To complete a computer refresh you will:
1. Back up data and settings locally, in a backup folder.
@ -25,18 +33,26 @@ For a computer refresh with MDT, you use the User State Migration Tool (USMT), w
4. Install other applications.
5. Restore data and settings.
During the computer refresh, USMT uses a feature called Hard-Link Migration Store. When you use this feature, the files are simply linked in the file system, which allows for fast migration, even when there is a lot of data.
**Note**  
In addition to the USMT backup, you can enable an optional full Windows Imaging (WIM) backup of the machine by configuring the MDT rules. If you do this, a .wim file is created in addition to the USMT backup. The .wim file will contain the entire volume from the computer, and helpdesk personnel can extract content from it if needed. Please note that this is a data WIM backup only. Using this backup to restore the entire machine is not a supported scenario.
 
### Multi-user migration
By default, ScanState in USMT backs up all profiles on the machine, including local computer profiles. If you have a machine that has been in your environment for a while, it likely has several domain-based profiles on it, including those of former users. You can limit which profiles are backed up by configuring command-line switches to ScanState (added as rules in MDT).
By default, ScanState in USMT backs up all profiles on the machine, including local computer profiles. If you have a machine that has been in your environment for a while, it likely has several domain-based profiles on it, including those of former users. You can limit which profiles are backed up
by configuring command-line switches to ScanState (added as rules in MDT).
As an example, the following line configures USMT to migrate only domain user profiles and not profiles from the local SAM account database: ScanStateArgs=/ue:\*\\\* /ui:CONTOSO\\\*
**Note**  
You also can combine the preceding switches with the /uel switch, which excludes profiles that have not been accessed within a specific number of days. For example, adding /uel:60 will configure ScanState (or LoadState) not to include profiles that haven't been accessed for more than 60 days.
 
### Support for additional settings
In addition to the command-line switches that control which profiles to migrate, the XML templates control exactly what data is being migrated. You can control data within and outside the user profiles
## <a href="" id="sec02"></a>Create a custom User State Migration Tool (USMT) template
In this section, you learn to migrate additional data using a custom template. You configure the environment to use a custom USMT XML template that will:
1. Back up the **C:\\Data** folder (including all files and folders).
2. Scan the local disk for PDF documents (\*.pdf files) and restore them into the **C:\\Data\\PDF Documents** folder on the destination machine.
@ -44,7 +60,9 @@ The custom USMT template is named MigContosoData.xml, and you can find it in the
- [Gather script](http://go.microsoft.com/fwlink/p/?LinkId=619361)
- [Set-OUPermissions](http://go.microsoft.com/fwlink/p/?LinkId=619362) script
- [MDT Sample Web Service](http://go.microsoft.com/fwlink/p/?LinkId=619363)
### Add the custom XML template
In order to use the custom MigContosoData.xml USMT template, you need to copy it to the MDT Production deployment share and update the CustomSettings.ini file. In these steps, we assume you have downloaded the MigContosoData.xml file.
1. Using File Explorer, copy the MigContosoData.xml file to the **E:\\MDTProduction\\Tools\\x64\\USMT5** folder.
2. Using Notepad, edit the E:\\MDTProduction\\Control\\CustomSettings.ini file. After the USMTMigFiles002=MigUser.xml line add the following line:
@ -52,12 +70,16 @@ In order to use the custom MigContosoData.xml USMT template, you need to copy it
USMTMigFiles003=MigContosoData.xml
```
3. Save the CustomSettings.ini file.
## <a href="" id="sec03"></a>Refresh a Windows 7 SP1 client
After adding the additional USMT template and configuring the CustomSettings.ini file to use it, you are now ready to refresh a Windows 7 SP1 client to Windows 10. In these steps, we assume you have a Windows 7 SP1 client named PC0001 in your environment that is ready for a refresh to Windows 10.
**Note**  
MDT also supports an offline computer refresh. For more info on that scenario, see the USMTOfflineMigration property in the [MDT resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
 
### Upgrade (refresh) a Windows 7 SP1 client
1. On PC0001, log on as **CONTOSO\\Administrator**. Start the Lite Touch Deploy Wizard by executing **\\\\MDT01\\MDTProduction$\\Scripts\\Litetouch.vbs**. Complete the deployment guide using the following settings:
1. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM
2. Computer name: &lt;default&gt;
@ -72,14 +94,22 @@ MDT also supports an offline computer refresh. For more info on that scenario, s
3. Installs the added application(s).
4. Updates the operating system via your local Windows Server Update Services (WSUS) server.
5. Restores user settings and data using USMT.
![figure 2](images/fig2-taskseq.png)
Figure 2. Starting the computer refresh from the running Windows 7 SP1 client.
## 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 2013 Update 2](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)
[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-2013-settings.md)
 
 

6
windows/deploy/remove-products-vamt.md
View File

@ -2,14 +2,17 @@
title: Remove Products (Windows 10)
description: Remove Products
ms.assetid: 4d44379e-dda1-4a8f-8ebf-395b6c0dad8e
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Remove Products
To remove one or more products from the Volume Activation Management Tool (VAMT), you can delete them from the product list view in the center pane.
**To delete one or more products**
1. Click a product node in the left-side pane.
2. You can use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
@ -20,6 +23,7 @@ To remove one or more products from the Volume Activation Management Tool (VAMT)
5. Select the products you want to delete.
6. Click **Delete** in the **Selected Items** menu in the right-side pane.
7. On the **Confirm Delete Selected Products** dialog box, click **OK**.
## Related topics
- [Add and Manage Products](add-manage-products-vamt.md)
 

42
windows/deploy/replace-a-windows-7-computer-with-a-windows-10-computer.md
View File

@ -2,26 +2,37 @@
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.pagetype: mdt
keywords: ["deploy, deployment, replace"]
keywords: deploy, deployment, replace
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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).
![figure 1](images/mdt-03-fig01.png)
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
@ -31,6 +42,7 @@ When preparing for the computer replace, you need to create a folder in which to
icacls E:\MigData /grant '"MDT_BA":(OI)(CI)(M)'
```
### Create a backup only (replace) task sequence
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the **Task Sequences** node and create a new folder named **Other**.
2. Right-click the **Other** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
1. Task sequence ID: REPLACE-001
@ -38,13 +50,19 @@ When preparing for the computer replace, you need to create a folder in which to
3. Task sequence comments: Run USMT to backup user data and settings
4. Template: Standard Client Replace Task Sequence
3. 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.
![figure 2](images/mdt-03-fig02.png)
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**.
@ -57,13 +75,21 @@ During a computer replace, these are the high-level steps that occur:
 
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.
![figure 3](images/mdt-03-fig03.png)
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.
![figure 4](images/mdt-03-fig04.png)
Figure 4. The USMT backup of PC0002.
### Deploy the PC0007 virtual machine
1. Create a virtual machine with the following settings:
1. Name: PC0007
2. Location: C:\\VMs
@ -71,8 +97,11 @@ During a computer replace, these are the high-level steps that occur:
4. Memory: 2048 MB
5. 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.
![figure 5](images/mdt-03-fig05.png)
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:
1. Password: P@ssw0rd
2. Select a task sequence to execute on this computer:
@ -84,12 +113,17 @@ During a computer replace, these are the high-level steps that occur:
2. Installs the added application.
3. Updates the operating system via your local Windows Server Update Services (WSUS) server.
4. 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 2013 Update 2](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-2013-settings.md)
 
 

9
windows/deploy/scenario-kms-activation-vamt.md
View File

@ -2,18 +2,23 @@
title: Scenario 3 KMS Client Activation (Windows 10)
description: Scenario 3 KMS Client Activation
ms.assetid: 72b04e8f-cd35-490c-91ab-27ea799b05d0
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Scenario 3: KMS Client Activation
In this scenario, you use the Volume Activation Management Tool (VAMT) to activate Key Management Service (KMS) client keys or Generic Volume License Keys (GVLKs). This can be performed on either Core Network or Isolated Lab computers. By default, volume license editions of Windows Vista, Windows® 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. GVLKs are already installed in volume license editions of these products. You do not have to enter a key to activate a product as a GVLK, unless you are converting a MAK-activated product to a KMS activation. For more information, see [Install a KMS Client Key](install-kms-client-key-vamt.md).
The procedure that is described below assumes the following:
- The KMS Service is enabled and available to all KMS clients.
- VAMT has been installed and computers have been added to the VAMT database. See Parts 1 through 4 in either [Scenario 1: Online Activation](scenario-online-activation-vamt.md) or [Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md) for more information.
## Activate KMS Clients
1. Open VAMT.
2. To set the KMS activation options, on the menu bar click **View**. Then click **Preferences** to open the **Volume Activation Management Tool Preferences** dialog box.
3. In the **Volume Activation Management Tool Preferences** dialog box, under **KMS Management Services host selection** select from the following options:
@ -29,7 +34,9 @@ The procedure that is described below assumes the following:
8. Select the products that you want to activate.
9. Click **Activate** in the **Selected Items** menu in the right-side **Actions** pane, click **Activate**, point to **Volume activate**, and then click the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
10. VAMT displays the **Activating products** dialog box until it completes the requested action. When activation is complete, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status is shown under the **Status of Last Action** column in the products list view in the center pane.
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
 

33
windows/deploy/scenario-online-activation-vamt.md
View File

@ -2,13 +2,15 @@
title: Scenario 1 Online Activation (Windows 10)
description: Scenario 1 Online Activation
ms.assetid: 94dba40e-383a-41e4-b74b-9e884facdfd3
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Scenario 1: Online Activation
In this scenario, the Volume Activation Management Tool (VAMT) is deployed in the Core Network environment. VAMT is installed on a central computer that has network access to all of the client computers. Both the VAMT host and the client computers have Internet access. The following illustration shows a diagram of an online activation scenario for Multiple Activation Keys (MAKs). You can use this scenario for online activation of the following key types:
- Multiple Activation Key (MAK)
- Windows Key Management Service (KMS) keys:
@ -16,7 +18,9 @@ In this scenario, the Volume Activation Management Tool (VAMT) is deployed in th
- Generic Volume License Key (GVLK), or KMS client key
- Retail
The Secure Zone represents higher-security Core Network computers that have additional firewall protection.
![VAMT firewall configuration for multiple subnets](images/dep-win8-l-vamt-makindependentactivationscenario.jpg)
## In This Topic
- [Install and start VAMT on a networked host computer](#bkmk-partone)
- [Configure the Windows Management Instrumentation firewall exception on target computers](#bkmk-parttwo)
@ -27,18 +31,27 @@ The Secure Zone represents higher-security Core Network computers that have addi
- [Add product keys and determine the remaining activation count](#bkmk-partseven)
- [Install the product keys](#bkmk-parteight)
- [Activate the client products](#bkmk-partnine)
## <a href="" id="bkmk-partone"></a>Step 1: Install and start VAMT on a networked host computer
1. Install VAMT on the host computer.
2. Click the VAMT icon in the **Start** menu to open VAMT.
## <a href="" id="bkmk-parttwo"></a>Step 2: Configure the Windows Management Instrumentation firewall exception on target computers
- Ensure that the Windows Management Instrumentation (WMI) firewall exception has been enabled for all target computers. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
**Note**  
To retrieve product license status, VAMT must have administrative permissions on the remote computers and WMI must be available through the Windows Firewall. In addition, for workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
## <a href="" id="bkmk-partthree"></a>Step 3: Connect to a VAMT database
1. If you are not already connected to a database, the **Database Connection Settings** dialog box appears when you open VAMT. Select the server and database where the keys that must be activated are located.
2. Click **Connect**.
3. If you are already connected to a database, VAMT displays an inventory of the products and product keys in the center pane, and a license overview of the computers in the database. If you need to connect to a different database, click **Successfully connected to Server** to open **the Database Connection Settings** dialog box. For more information about how to create VAMT databases and adding VAMT data, see [Manage VAMT Data](manage-vamt-data.md)
## <a href="" id="bkmk-partfour"></a>Step 4: Discover products
1. In the left-side pane, in the **Products** node Products, click the product that you want to activate.
2. To open the **Discover Products** dialog box, click **Discover products** in the **Actions** menu in the right-side pane.
3. In the **Discover Products** dialog box, click **Search for computers in the Active Directory** to display the search options, and then click the search options that you want to use. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general Lightweight Directory Access Protocol (LDAP) query:
@ -47,8 +60,11 @@ The Secure Zone represents higher-security Core Network computers that have addi
- To search for computers in a workgroup, click **Search for computers in the workgroup**. Then under **Workgroup Filter Criteria**, in the list of workgroup names, click the name of the workgroup that you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for a specific computer in the workgroup. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only computer names that start with the letter "a".
- To search for computers by using a general LDAP query, click **Search with LDAP query** and enter your query in the text box that appears. VAMT will validate the LDAP query syntax, but will otherwise run the query without additional checks.
4. Click **Search**.
When the search is complete, the products that VAMT discovers appear in the product list view in the center pane.
## <a href="" id="bkmk-partfive"></a>Step 5: Sort and filter the list of computers
You can sort the list of products so that it is easier to find the computers that require product keys to be activated:
1. On the menu bar at the top of the center pane, click **Group by**, and then click **Product**, **Product Key Type**, or **License Status**.
2. To sort the list further, you can click one of the column headings to sort by that column.
@ -57,43 +73,58 @@ You can sort the list of products so that it is easier to find the computers tha
- To filter the list by computer name, enter a name in the **Computer Name** box.
- To filter the list by product name, product key type, or license status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
5. Click **Filter**. VAMT displays the filtered list in the product list view in the center pane.
## <a href="" id="bkmk-partsix"></a>Step 6: Collect status information from the computers in the list
To collect the status from select computers in the database, you can select computers in the product list view by using one of the following methods:
- To select a block of consecutively listed computers, click the first computer that you want to select, and then click the last computer while pressing the **Shift** key.
- To select computers which are not listed consecutively, hold down the **Ctrl** key and select each computer for which you want to collect the status information.
**To collect status information from the selected computers**
1. In the right-side **Actions** pane, click **Update license status** in the **Selected Items** menu and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials that are different from the ones that you used to log on to the computer. Otherwise, click **Current Credentials** and continue to step 2.If you are supplying alternate credentials, in the **Windows Security** dialog box, type the appropriate user name and password and then click **OK**.
2. VAMT displays the **Collecting product information** dialog box while it collects the license status of all supported products on the selected computers. When the process is finished, the updated license status of each product will appear in the product list view in the center pane.
**Note**  
If a computer has more than one supported product installed, VAMT adds an entry for each product. The entry appears under the appropriate product heading.
## <a href="" id="bkmk-partseven"></a>Step 7: Add product keys and determine the remaining activation count
1. Click the **Product Keys** node in the left-side pane, and then click **Add Product Keys** in the right-side pane to open the **Add Product Keys** dialog box.
2. In the **Add Product Key** dialog box, you can select from one of the following methods to add product keys:
- To add product keys manually, click **Enter product key(s) separated by line breaks**, enter one or more product keys, and then click **Add Key(s)**.
- To import a Comma Separated Values File (CSV) that contains a list of product keys, click **Select a product key file to import**, browse to the file location, click **Open** to import the file, and then click **Add Key(s)**.
The keys that you have added appear in the **Product Keys** list view in the center pane.
**Important**  
If you are activating many products with a MAK, refresh the activation count of the MAK to ensure that the MAK can support the required number of activations. In the product key list in the center pane, select the MAK and then click **Refresh product key data online** in the right-side pane to contact Microsoft and retrieve the number of remaining activations for the MAK. This step requires Internet access. You can only retrieve the remaining activation count for MAKs.
## <a href="" id="bkmk-parteight"></a>Step 8: Install the product keys
1. In the left-side pane, click the product that you want to install keys on to.
2. If necessary, sort and filter the list of products so that it is easier to find the computers that must have a product key installed. See [Step 5: Sort and filter the list of computers](#bkmk-partfive).
3. In the **Products** list view pane, select the individual products which must have keys installed. You can use the **CTRL** key or the **SHIFT** key to select more than one product.
4. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
5. The **Select Product Key** dialog box displays the keys that are available to be installed. Under **Recommended MAKs**, VAMT might display one or more recommended MAKs based on the selected products. If you are installing a MAK you can select a recommended product key or any other MAK from the **All Product Keys List**. If you are not installing a MAK, select a product key from the **All Product Keys** list. Use the scroll bar if you want to view the **Description** for each key. When you have selected the product key that you want to install, click **Install Key**. Note that only one key can be installed at a time.
6. VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
**Note**  
Product key installation will fail if VAMT finds mismatched key types or editions. VAMT will display the failure status and will continue the installation for the next product in the list. For more information on choosing the correct product key, see [How to Choose the Right Volume License Key for Windows.](http://go.microsoft.com/fwlink/p/?linkid=238382)
## <a href="" id="bkmk-partnine"></a>Step 9: Activate the client products
1. Select the individual products that you want to activate in the list-view pane.
2. On the menu bar, click **Action**, point to **Activate** and point to **Online activate**. You can also right-click the selected computers(s) to display the **Action** menu, point to **Activate** and point to **Online activate**. You can also click **Activate** in the **Selected Items** menu in the right-hand pane to access the **Activate** option.
3. If you are activating product keys using your current credential, click **Current credential** and continue to step 5. If you are activating products that require an administrator credential that is different from the one you are currently using, click the **Alternate credential** option.
4. Enter your alternate user name and password and click **OK**.
5. The **Activate** option contacts the Microsoft product-activation server over the Internet and requests activation for the selected products. VAMT displays the **Activating products** dialog box until the requested actions are completed.
**Note**  
Installing a MAK and overwriting the GVLK on client products must be done with care. If the RTM version of Windows Vista has been installed on the computer for more than 30 days, then its initial grace period has expired. As a result, it will enter Reduced Functionality Mode (RFM) if online activation is not completed successfully before the next logon attempt. However, you can use online activation to recover properly configured computers from RFM, as long as the computers are available on the network.
RFM only applies to the RTM version of Windows Vista or the retail editions of Microsoft Office 2010. Windows Vista with SP1 or later, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and volume editions of Office 2010 will not enter RFM.
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
 

47
windows/deploy/scenario-proxy-activation-vamt.md
View File

@ -2,27 +2,39 @@
title: Scenario 2 Proxy Activation (Windows 10)
description: Scenario 2 Proxy Activation
ms.assetid: ed5a8a56-d9aa-4895-918f-dd1898cb2c1a
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Scenario 2: Proxy Activation
In this scenario, the Volume Activation Management Tool (VAMT) is used to activate products that are installed on workgroup computers in an isolated lab environment. For workgroups which are isolated from the larger network, you can perform proxy activation of Multiple Activation Keys (MAKs), KMS Host keys (CSVLKs), Generic Volume License Keys (GVLKs) (or KMS client keys), or retail keys. Proxy activation is performed by installing a second instance of VAMT on a computer in the isolated workgroup. You can then use removable media to transfer VAMT Computer Information Lists (CILXs) between the instance of VAMT in the isolated workgroup and another VAMT host that has Internet access. The following diagram shows a Multiple Activation Key (MAK) proxy activation scenario:
![VAMT MAK proxy activation scenario](images/dep-win8-l-vamt-makproxyactivationscenario.jpg)
## Step 1: Install VAMT on a Workgroup Computer in the Isolated Lab
1. Install VAMT on a host computer in the isolated lab workgroup. This computer can be running Windows 7, Windows 8, Windows 10, Windows Server 2008 R2, or Windows Server® 2012.
2. Click the VAMT icon in the **Start** menu to open VAMT.
## Step 2: Configure the Windows Management Instrumentation Firewall Exception on Target Computers
- Ensure that the Windows Management Instrumentation (WMI) firewall exception has been enabled for all target computers. For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
**Note**  
To retrieve the license status on the selected computers, VAMT must have administrative permissions on the remote computers and WMI must be accessible through the Windows Firewall. In addition, for workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
## Step 3: Connect to a VAMT Database
1. If the host computer in the isolated lab workgroup is not already connected to the database, the **Database Connection Settings** dialog box appears when you open VAMT. Select the server and database that contains the computers in the workgroup.
2. Click **Connect**.
3. If you are already connected to a database, in the center pane VAMT displays an inventory of the products and product keys, and a license overview of the computers in the database. If you need to connect to a different database, click **Successfully connected to the Server** to open the **Database Connection Settings** dialog box. For more information about how to create VAMT databases and adding VAMT data, see [Manage VAMT Data.](manage-vamt-data.md)
## Step 4: Discover Products
1. In the left-side pane, in the **Products** node, click the product that you want to activate.
2. To open the **Discover Products** dialog box, click **Discover products** in the right-side pane.
3. In the **Discover Products** dialog box, click **Search for computers in the Active Directory** to display the search options, and then click the search options that you want to use. You can search for computers in an Active Directory domain, by individual computer name or IP address, in a workgroup, or by a general LDAP query:
@ -31,10 +43,15 @@ In this scenario, the Volume Activation Management Tool (VAMT) is used to activa
- To search for computers in a workgroup, click **Search for computers in the workgroup**. Then under **Workgroup Filter Criteria**, in the list of workgroup names, click the name of the workgroup that you want to search. You can narrow the search further by typing a name in the **Filter by computer name** field to search for a specific computer in the workgroup. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only those computer names that start with the letter "a".
- To search for computers by using a general LDAP query, click **Search with LDAP query** and enter your query in the text box that appears. VAMT will validate the LDAP query syntax, but will otherwise run the query without additional checks.
4. Click **Search**.
The **Finding Computers** window appears and displays the search progress as the computers are located.
When the search is complete, the products that VAMT discovers appear in the list view in the center pane.
## Step 5: Sort and Filter the List of Computers
You can sort the list of products so that it is easier to find the computers that require product keys to be activated:
1. On the menu bar at the top of the center pane, click **Group by**, and then click **Product**, **Product Key Type**, or **License Status**.
2. To sort the list further, you can click one of the column headings to sort by that column.
3. You can also use the **Filter** function to narrow your search for computers by clicking **Filter** in the right-side pane to open the **Filter Products** dialog box.
@ -42,35 +59,49 @@ You can sort the list of products so that it is easier to find the computers tha
- To filter the list by computer name, enter a name in the **Computer Name** box.
- To filter the list by product name, product key type, or license status, click the list you want to use for the filter and select an option. If necessary, click **clear all filters** to create a new filter.
5. Click **Filter**. VAMT displays the filtered list in the product list view in the center pane.
## Step 6: Collect Status Information from the Computers in the Isolated Lab
To collect the status from select computers in the database, you can select computers in the product list view by using one of the following methods:
- To select a block of consecutively listed computers, click the first computer that you want to select, and then click the last computer while pressing the **Shift** key.
- To select computers which are not listed consecutively, hold down the **Ctrl** ley and select each computer for which you want to collect the status information.
**To collect status information from the selected computers**
1. In the right-side **Actions** pane, click **Update license status** in the **Selected Items** menu and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials that are different from the ones that you used to log on to the computer. Otherwise, click **Current Credentials** and continue to step 2.If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and then click **OK**.
2. VAMT displays the **Collecting product information** dialog box while it collects the license status of all supported products on the selected computers. When the process is finished, the updated license status of each product will appear in the product list view in the center pane.
**Note**  
If a computer has more than one supported product installed, VAMT adds an entry for each product. The entry appears under the appropriate product heading.
## Step 7: Add Product Keys
1. Click the **Product Keys** node in the left-side pane, and then click **Add Product Keys** in the right-side pane to open the **Add Product Keys** dialog box.
2. In the **Add Product Keys** dialog box, you can select from one of the following methods to add product keys:
- To add a single product key, click **Enter product key(s) separated by line breaks**, enter one or more product keys, and then click **Add key(s)**.
- To import a Comma Separated Values File (CSV) that contains a list of product keys, click **Select a product key to import**, browse to the file location, click **Open** to import the file, and then click **Add Key(s)**.
The keys that you have added appear in the **Product Keys** list view in the center pane.
## Step 8: Install the Product Keys on the Isolated Lab Computers
1. In the left-side pane, in the **Products** node click the product that you want to install keys onto.
2. If necessary, sort and filter the list of products so that it is easier to find the computers that must have a product key installed. See [Step 5: Sort and Filter the List of Computers](#step-5-sort-and-filter-the-list-of-computers).
3. In the **Products** list view pane, select the individual products which must have keys installed. You can use the **CTRL** key or the **SHIFT** key to select more than one product.
4. Click **Install product key** in the **Selected Items** menu in the right-side pane to display the **Install Product Key** dialog box.
5. The **Select Product Key** dialog box displays the keys that are available to be installed. Under **Recommended MAKs**, VAMT might display one or more recommended MAKs based on the selected products. If you are installing a MAK you can select a recommended product key or any other MAK from the **All Product Keys List**. If you are not installing a MAK, select a product key from the **All Product Keys** list. Use the scroll bar if you need to view the **Description** for each key. When you have selected the product key that you want to install, click **Install Key**. Note that only one key can be installed at a time.
6. VAMT displays the **Installing product key** dialog box while it attempts to install the product key for the selected products. When the process is finished, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
**Note**  
Product key installation will fail if VAMT finds mismatched key types or editions. VAMT displays the failure status and continues the installation for the next product in the list. For more information on choosing the correct product key, see [How to Choose the Right Volume License Key for Windows.](http://go.microsoft.com/fwlink/p/?linkid=238382)
**Note**  
Installing a MAK and overwriting the GVLK on client products must be done with care. If the RTM version of Windows Vista has been installed on the computer for more than 30 days, then its initial grace period has expired. As a result, it will enter Reduced Functionality Mode (RFM) if online activation is not completed successfully before the next logon attempt. However, you can use online activation to recover properly configured computers from RFM, as long as the computers are available on the network. RFM only applies to the RTM version of Windows Vista or the retail editions of Microsoft Office 2010. Windows Vista with SP1 or later, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, and volume editions of Office 2010 will not enter RFM.
## Step 9: Export VAMT Data to a .cilx File
In this step, you export VAMT from the workgroup’s host computer and save it in a .cilx file. Then you copy the .cilx file to removable media so that you can take it to a VAMT host computer that is connected to the Internet. In MAK proxy activation, it is critical to retain this file, because VAMT uses it to apply the Confirmation IDs (CIDs) to the proper products.
1. Select the individual products that successfully received a product key in Step 8. If needed, sort and filter the list to find the products.
2. In the right-side **Actions** pane, click **Export list** to open the **Export List** dialog box.
3. In the **Export List** dialog box, click **Browse** to navigate to the .cilx file, or enter the name of the .cilx file to which you want to export the data.
@ -81,39 +112,53 @@ In this step, you export VAMT from the workgroup’s host computer and save it i
5. If you have selected products to export, and not the entire set of data from the database, select the **Export selected product rows only** check box.
6. Click **Save**. VAMT displays a progress message while the data is being exported. Click **OK** when a message appears and confirms that the export has completed successfully.
7. If you exported the list to a file on the host computer’s hard drive, copy the file to removable media, such as a disk drive, CD/DVD, or USB storage device.
**Important**  
Choosing the **Export proxy activation data only** option excludes Personally Identifiable Information (PII) from being saved in the .cilx file. Therefore, the .cilx file must be re-imported into the SQL Server database on the isolated lab workgroup’s VAMT host computer, so that the CIDs that are requested from Microsoft (discussed in Step 10) can be correctly assigned to the computers in the isolated lab group.
## Step 10: Acquire Confirmation IDs from Microsoft on the Internet-Connected Host Computer
1. Insert the removable media into the VAMT host that has Internet access.
2. Open VAMT. Make sure you are on the root node, and that the **Volume Activation Management Tool** view is displayed in the center pane.
3. In the right-side **Actions** pane, click **Acquire confirmation IDs for CILX** to open the **Acquire confirmation IDs for file** dialog box.
4. In the **Acquire confirmation IDs for file** dialog box, browse to the location of the .cilx file that you exported from the isolated lab host computer, select the file, and then click **Open**. VAMT displays an **Acquiring Confirmation IDs** message while it contacts Microsoft and collects the CIDs.
5. When the CID collection process is complete, VAMT displays a **Volume Activation Management Tool** message that shows the number of confirmation IDs that were successfully acquired, and the name of the file where the IDs were saved. Click **OK** to close the message.
## Step 11: Import the .cilx File onto the VAMT Host within the Isolated Lab Workgroup
1. Remove the storage device that contains the .cilx file from the Internet-connected VAMT host computer and insert it into the VAMT host computer in the isolated lab.
2. Open VAMT and verify that you are connected to the database that contains the computer with the product keys that you are activating.
3. In the right-side **Actions** pane, click **Import list** to open the **Import List** dialog box.
4. In the **Import list** dialog box, browse to the location of the .cilx file that contains the CIDs, select the file, and then click **Open**.
5. Click **OK** to import the file and to overwrite any conflicting data in the database with data from the file.
6. VAMT displays a progress message while the data is being imported. Click **OK** when a message appears and confirms that the data has been successfully imported.
## Step 12: Apply the CIDs and Activate the Isolated Lab Computers
1. Select the products to which you want to apply CIDs. If needed, sort and filter the list to find the products.
2. In the right-side **Selected Items** menu, click **Activate**, click **Apply Confirmation ID**, and then select the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
VAMT displays the **Applying Confirmation Id** dialog box while it installs the CIDs on the selected products. When VAMT finishes installing the CIDs, the status appears in the **Action Sataus** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
## Step 13: (Optional) Reactivating Reimaged Computers in the Isolated Lab
If you have captured new images of the computers in the isolated lab, but the underlying hardware of those computers has not changed, VAMT can reactivate those computers using the CIDs that are stored in the database.
1. Redeploy products to each computer, using the same computer names as before.
2. Open VAMT.
3. In the right-side **Selected Items** menu, click **Activate**, click **Apply Confirmation ID**, and then select the appropriate credential option. If you click the **Alternate Credentials** option, you will be prompted to enter an alternate user name and password.
VAMT displays the **Applying Confirmation Id** dialog box while it installs the CIDs on the selected products. When VAMT finishes installing the CIDs, the status appears in the **Action Status** column of the dialog box. Click **Close** to close the dialog box. You can also click the **Automatically close when done** check box when the dialog box appears.
The same status appears under the **Status of Last Action** column in the product list view in the center pane.
**Note**  
Installing a MAK and overwriting the GVLK on the client products must be done with care. If the Windows activation initial grace period has expired, Windows will enter Reduced Functionality Mode (RFM) if online activation is not completed successfully before the next logon attempt. However, you can use online activation to recover properly configured computers from RFM, as long as the computers are accessible on the network.
RFM only applies to the RTM version of Windows Vista or the retail editions of Microsoft Office 2010. Windows Vista with SP1 or later, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, and volume editions of Office 2010 will not enter RFM.
**Note**  
Reapplying the same CID conserves the remaining activations on the MAK.
## Related topics
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
 

42
windows/deploy/set-up-mdt-2013-for-bitlocker.md
View File

@ -1,37 +1,50 @@
---
title: Set up MDT for BitLocker (Windows 10)
ms.assetid: 386e6713-5c20-4d2a-a220-a38d94671a38
ms.pagetype: mdt
description:
keywords: ["disk, encryption, TPM, configure, secure, script"]
keywords: disk, encryption, TPM, configure, secure, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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](http://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**.
@ -42,9 +55,13 @@ The BitLocker Drive Encryption Administration Utilities are added as features vi
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.
@ -58,26 +75,35 @@ Following these steps, you enable the backup of BitLocker and TPM recovery infor
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](http://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
@ -95,11 +121,13 @@ 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](http://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.
@ -109,13 +137,19 @@ When configuring a task sequence to run any BitLocker tool, either directly or u
- **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-2013-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-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
 
 

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

@ -2,16 +2,19 @@
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.pagetype: mdt
keywords: ["deploy, script,"]
keywords: deploy, script
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# 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](http://go.microsoft.com/fwlink/p/?LinkId=619361) from the TechNet gallery.
1. On PC0001, log on as **CONTOSO\\Administrator** using the password **P@ssw0rd**.
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**.
@ -25,8 +28,11 @@ For the purposes of this topic, you already will have either downloaded and inst
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
@ -36,15 +42,23 @@ For the purposes of this topic, you already will have either downloaded and inst
**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-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-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-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
 
 

9
windows/deploy/update-product-status-vamt.md
View File

@ -2,23 +2,30 @@
title: Update Product Status (Windows 10)
description: Update Product Status
ms.assetid: 39d4abd4-801a-4e8f-9b8c-425a24a96764
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Update Product Status
After you add computers to the VAMT database, you need to use the **Update license status** function to add the products that are installed on the computers. You can also use the **Update license status** at any time to retrieve the most current license status for any products in the VAMT database.
To retrieve license status, VAMT must have administrative permissions on all selected computers and Windows Management Instrumentation (WMI) must be accessible through the Windows Firewall. In addition, for workgroup computers, a registry key must be created to enable remote administrative actions under User Account Control (UAC). For more information, see [Configure Client Computers](configure-client-computers-vamt.md).
**Note**  
The license-status query requires a valid computer name for each system queried. If the VAMT database contains computers that were added without Personally Identifiable Information, computer names will not be available for those computers, and the status for these computers will not be updated.
## Update the license status of a product
1. Open VAMT.
2. In the **Products** list, select one or more products that need to have their status updated.
3. In the right-side **Actions** pane, click **Update license status** and then click a credential option. Choose **Alternate Credentials** only if you are updating products that require administrator credentials different from the ones you used to log into the computer.
4. If you are supplying alternate credentials, in the **Windows Security** dialog box type the appropriate user name and password and click **OK**.
VAMT displays the **Collecting product information** dialog box while it collects the status of all selected products. When the process is finished, the updated licensing status of each product will appear in the product list view in the center pane.
**Note**  
If a previously discovered Microsoft Office 2010 product has been uninstalled from the remote computer, updating its licensing status will cause the entry to be deleted from the **Office** product list view, and, consequently, the total number of discovered products will be smaller. However, the Windows installation of the same computer will not be deleted and will always be shown in the **Windows** products list view.
 

41
windows/deploy/upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md
View File

@ -2,25 +2,37 @@
title: Upgrade to Windows 10 with the Microsoft Deployment Toolkit (Windows 10)
description: The simplest path to upgrade PCs that are currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade.
ms.assetid: B8993151-3C1E-4F22-93F4-2C5F2771A460
ms.pagetype: mdt
keywords: ["upgrade, update, task sequence, deploy"]
keywords: upgrade, update, task sequence, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Upgrade to Windows 10 with the Microsoft Deployment Toolkit
**Applies to**
- Windows 10
The simplest path to upgrade PCs that are currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade. You can use a Microsoft Deployment Toolkit (MDT) 2013 Update 2 task sequence to completely automate the process.
## Proof-of-concept environment
For the purposes of this topic, we will use four machines: DC01, MDT01, and PC0001. DC01 is a domain controller and MDT01 is a Windows Server 2012 R2 standard machine, fully patched with the latest security updates, and configured as a member server in the fictional contoso.com domain. PC0001 is a machine with Windows 7 SP1, targeted for the Windows 10 upgrade. 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).
![fig 1](images/upgrademdt-fig1-machines.png)
Figure 1. The machines used in this topic.
## Set up the upgrade task sequence
MDT 2013 Update 2 adds support for Windows 10 deployment, including a new in-place upgrade task sequence template that makes the process really simple.
## Create the MDT production deployment share
The steps to create the deployment share for production are the same as when you created the deployment share to create the custom reference image:
1. On MDT01, log on as Administrator in the CONTOSO domain with a password of **P@ssw0rd**.
2. Using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**.
3. On the **Path** page, in the **Deployment share path** text box, type **E:\\MDTProduction**, and then click **Next**.
@ -28,8 +40,11 @@ The steps to create the deployment share for production are the same as when you
5. On the **Descriptive Name** page, in the **Deployment share** description text box, type **MDT Production**, and then click **Next**.
6. On the **Options** page, accept the default settings and click **Next** twice, and then click **Finish**.
7. Using File Explorer, verify that you can access the **\\\\MDT01\\MDTProduction$** share.
## Add Windows 10 Enterprise x64 (full source)
In these steps we assume that you have copied the content of a Windows 10 Enterprise x64 ISO to the E:\\Downloads\\Windows 10 Enterprise x64 folder.
1. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Production**.
2. Right-click the **Operating Systems** node, and create a new folder named **Windows 10**.
3. Expand the **Operating Systems** node, right-click the **Windows 10** folder, and select **Import Operating System**. Use the following settings for the Import Operating System Wizard:
@ -37,9 +52,13 @@ In these steps we assume that you have copied the content of a Windows 10 Enter
- Source directory: E:\\Downloads\\Windows 10 Enterprise x64
- Destination directory name: W10EX64RTM
4. After you add the operating system, in the **Operating Systems / Windows 10** folder, double-click the added operating system name in the **Operating System** node and change the name to the following: **Windows 10 Enterprise x64 RTM Default Image**
![figure 2](images/upgrademdt-fig2-importedos.png)
Figure 2. The imported Windows 10 operating system after you rename it.
## Create a task sequence to upgrade to Windows 10 Enterprise
1. Using the Deployment Workbench, select **Task Sequences** in the **MDT Production** node, and create a folder named **Windows 10**.
2. Right-click the new **Windows 10** folder and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
- Task sequence ID: W10-X64-UPG
@ -51,21 +70,35 @@ Figure 2. The imported Windows 10 operating system after you rename it.
- Organization: Contoso
- Internet Explorer home page: about:blank
- Admin Password: Do not specify an Administrator Password at this time
![figure 3](images/upgrademdt-fig3-tasksequence.png)
Figure 3. The task sequence to upgrade to Windows 10.
## Perform the Windows 10 upgrade
To initiate the in-place upgrade, perform the following steps on PC0003 (currently running Windows 7 SP1).
1. Start the MDT deployment wizard by running the following command: **\\\\MDT01\\MDTProduction$\\Scripts\\LiteTouch.vbs**
2. Select the **Windows 10 Enterprise x64 RTM Upgrade** task sequence, and then click **Next**.![figure 4](images/upgrademdt-fig4-selecttask.png)
2. Select the **Windows 10 Enterprise x64 RTM Upgrade** task sequence, and then click **Next**.
![figure 4](images/upgrademdt-fig4-selecttask.png)
Figure 4. Upgrade task sequence.
3. On the **Credentials** tab, specify the **MDT\_BA** account, **P@ssw0rd** password, and **CONTOSO** for the domain. (Some or all of these values can be specified in Bootstrap.ini so they are automatically populated.)
4. On the **Ready** tab, click **Begin** to start the task sequence.
When the task sequence begins, it automatically initiates the in-place upgrade process by invoking the Windows setup program (Setup.exe) with the necessary command-line parameters to perform an automated upgrade, which preserves all data, settings, apps, and drivers.
![figure 5](images/upgrademdt-fig5-winupgrade.png)
Figure 5. Upgrade from Windows 7 to Windows 10 Enterprise x64 with a task sequence.
After the task sequence completes, the computer will be fully upgraded to Windows 10.
## Related topics
[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
[Microsoft Deployment Toolkit downloads and resources](http://go.microsoft.com/fwlink/p/?LinkId=618117)
 
 

52
windows/deploy/use-orchestrator-runbooks-with-mdt-2013.md
View File

@ -2,20 +2,24 @@
title: Use Orchestrator runbooks with MDT (Windows 10)
description: This topic will show you how to integrate Microsoft System Center 2012 R2 Orchestrator with MDT to replace the existing web services that are used in deployment solutions.
ms.assetid: 68302780-1f6f-4a9c-9407-b14371fdce3f
ms.pagetype: mdt
keywords: ["web services, database"]
keywords: web services, database
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: mdt
author: mtniehaus
---
# Use Orchestrator runbooks with MDT
This topic will show you how to integrate Microsoft System Center 2012 R2 Orchestrator with MDT to replace the existing web services that are used in deployment solutions.
MDT can integrate with System Center 2012 R2 Orchestrator, which is a component that ties the Microsoft System Center products together, as well as other products from both Microsoft and third-party vendors. The difference between using Orchestrator and "normal" web services, is that with Orchestrator you have a rich drag-and-drop style interface when building the solution, and little or no coding is required.
**Note**  
If you are licensed to use Orchestrator, we highly recommend that you start using it. To find out more about licensing options for System Center 2012 R2 and Orchestrator, visit the [System Center 2012 R2](http://go.microsoft.com/fwlink/p/?LinkId=619553) website.
 
## <a href="" id="sec01"></a>Orchestrator terminology
Before diving into the core details, here is a quick course in Orchestrator terminology:
- **Orchestrator Server.** This is a server that executes runbooks.
- **Runbooks.** A runbook is similar to a task sequence; it is a series of instructions based on conditions. Runbooks consist of workflow activities; an activity could be Copy File, Get User from Active Directory, or even Write to Database.
@ -24,21 +28,29 @@ Before diving into the core details, here is a quick course in Orchestrator term
- **Orchestrator Console.** This is the Microsoft Silverlight-based web page you can use interactively to execute runbooks. The console listens to TCP port 81 by default.
- **Orchestrator web services.** These are the web services you use in the Microsoft Deployment Toolkit to execute runbooks during deployment. The web services listen to TCP port 82 by default.
- **Integration packs.** These provide additional workflow activities you can import to integrate with other products or solutions, like the rest of Active Directory, other System Center 2012 R2 products, or Microsoft Exchange Server, to name a few.
**Note**  
To find and download additional integration packs, see [Integration Packs for System Center 2012 - Orchestrator](http://go.microsoft.com/fwlink/p/?LinkId=619554).
 
## <a href="" id="sec02"></a>Create a sample runbook
This section assumes you have Orchestrator 2012 R2 installed on a server named OR01. In this section, you create a sample runbook, which is used to log some of the MDT deployment information into a text file on OR01.
1. On OR01, using File Explorer, create the **E:\\Logfile** folder, and grant Users modify permissions (NTFS).
2. In the **E:\\Logfile** folder, create the DeployLog.txt file.
**Note**  
Make sure File Explorer is configured to show known file extensions so the file is not named DeployLog.txt.txt.
 
![figure 23](images/mdt-09-fig23.png)
Figure 23. The DeployLog.txt file.
3. Using System Center 2012 R2 Orchestrator Runbook Designer, in the **Runbooks** node, create the **1.0 MDT** folder.
![figure 24](images/mdt-09-fig24.png)
Figure 24. Folder created in the Runbooks node.
4. In the **Runbooks** node, right-click the **1.0 MDT** folder, and select **New / Runbook**.
5. On the ribbon bar, click **Check Out**.
6. Right-click the **New Runbook** label, select **Rename**, and assign the name **MDT Sample**.
@ -46,26 +58,41 @@ This section assumes you have Orchestrator 2012 R2 installed on a server named O
1. Runbook Control / Initialize Data
2. Text File Management / Append Line
8. Connect **Initialize Data** to **Append Line**.
![figure 25](images/mdt-09-fig25.png)
Figure 25. Activities added and connected.
9. Right-click the **Initialize Data** activity, and select **Properties**
10. On **the Initialize Data Properties** page, click **Add**, change **Parameter 1** to **OSDComputerName**, and then click **Finish**.
![figure 26](images/mdt-09-fig26.png)
Figure 26. The Initialize Data Properties window.
11. Right-click the **Append Line** activity, and select **Properties**.
12. On the **Append Line Properties** page, in the **File** text box, type **E:\\Logfile\\DeployLog.txt**.
13. In the **File** encoding drop-down list, select **ASCII**.
14. In the **Append** area, right-click inside the **Text** text box and select **Expand**.
![figure 27](images/mdt-09-fig27.png)
Figure 27. Expanding the Text area.
15. In the blank text box, right-click and select **Subscribe / Published Data**.
![figure 28](images/mdt-09-fig28.png)
Figure 28. Subscribing to data.
16. In the **Published Data** window, select the **OSDComputerName** item, and click **OK**.
17. After the **{OSDComputerName from "Initialize Data"}** text, type in **has been deployed at** and, once again, right-click and select **Subscribe / Published Data**.
18. In the **Published Data** window, select the **Show common Published Data** check box, select the **Activity end time** item, and click **OK**.
![figure 29](images/mdt-09-fig29.png)
Figure 29. The expanded text box after all subscriptions have been added.
19. On the **Append Line Properties** page, click **Finish**.
## <a href="" id="sec03"></a>Test the demo MDT runbook
After the runbook is created, you are ready to test it.
@ -75,9 +102,13 @@ After the runbook is created, you are ready to test it.
3. Verify that all activities are green (for additional information, see each target).
4. Close the **Runbook Tester**.
5. On the ribbon bar, click **Check In**.
![figure 30](images/mdt-09-fig30.png)
Figure 30. All tests completed.
## Use the MDT demo runbook from MDT
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the **Task Sequences** node, and create a folder named **Orchestrator**.
2. Right-click the **Orchestrator** node, and select **New Task Sequence**. Use the following settings for the New Task Sequence Wizard:
1. Task sequence ID: OR001
@ -95,9 +126,13 @@ Figure 30. All tests completed.
1. Orchestrator Server: OR01.contoso.com
2. Use Browse to select **1.0 MDT / MDT Sample**.
8. Click **OK**.
![figure 31](images/mdt-09-fig31.png)
Figure 31. The ready-made task sequence.
## Run the orchestrator sample task sequence
Since this task sequence just starts a runbook, you can test this on the PC0001 client that you used for the MDT simulation environment.
**Note**  
Make sure the account you are using has permissions to run runbooks on the Orchestrator server. For more information about runbook permissions, see [Runbook Permissions](http://go.microsoft.com/fwlink/p/?LinkId=619555).
@ -114,15 +149,24 @@ Make sure the account you are using has permissions to run runbooks on the Orche
2. Password: P@ssw0rd
3. Domain: CONTOSO
4. Wait until the task sequence is completed and then verify that the DeployLog.txt file in the E:\\Logfile folder on OR01 was updated.
![figure 32](images/mdt-09-fig32.png)
Figure 32. The ready-made task sequence.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
[Simulate a Windows10 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-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
 
 

32
windows/deploy/use-the-mdt-database-to-stage-windows-10-deployment-information.md
View File

@ -3,21 +3,28 @@ title: Use the MDT database to stage Windows 10 deployment information (Windows
description: This topic is designed to teach you how to use the MDT database to pre-stage information on your Windows 10 deployment in a Microsoft SQL Server 2012 SP1 Express database, rather than include the information in a text file (CustomSettings.ini).
ms.assetid: 8956ab54-90ba-45d3-a384-4fdec72c4d46
ms.pagetype: mdt
keywords: ["database, permissions, settings, configure, deploy"]
keywords: database, permissions, settings, configure, deploy
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
author: mtniehaus
---
# Use the MDT database to stage Windows 10 deployment information
This topic is designed to teach you how to use the MDT database to pre-stage information on your Windows 10 deployment in a Microsoft SQL Server 2012 SP1 Express database, rather than include the information in a text file (CustomSettings.ini). You can use this process, for example, to add the client machines you want to deploy, specify their computer names and IP addresses, indicate applications to be deployed, and determine many additional settings for the machines.
## <a href="" id="sec01"></a>Database prerequisites
MDT can use either SQL Server Express or full SQL Server, but since the deployment database isn't big, even in large enterprise environments, we recommend using the free SQL Server 2012 SP1 Express database in your environment.
**Note**  
Be sure to enable Named Pipes when configuring the SQL Server 2012 SP1 Express database. Although it is a legacy protocol, Named Pipes has proven to work well when connecting from Windows Preinstallation Environment (Windows PE) to the SQL Server database.
 
## <a href="" id="sec02"></a>Create the deployment database
The MDT database is by default created and managed from the Deployment Workbench. In these steps, we assume you have installed SQL Server 2012 SP1 Express on MDT01.
**Note**  
Since SQL Server 2012 SP1 Express runs by default on a separate instance (SQLEXPRESS), the SQL Server Browser service must be running, and the firewall configured to allow traffic to it. Port 1433 TCP and port 1434 UDP need to be opened for inbound traffic on MDT01.
 
@ -29,37 +36,56 @@ Since SQL Server 2012 SP1 Express runs by default on a separate instance (SQLEXP
4. Network Library: Named Pipes
3. On the **Database** page, select **Create a new database**; in the **Database** field, type **MDT** and click **Next**.
4. On the **SQL Share** page, in the **SQL Share** field, type **Logs$** and click **Next**. Click **Next** again and then click **Finish**.
![figure 8](images/mdt-09-fig08.png)
Figure 8. The MDT database added to MDT01.
## <a href="" id="sec03"></a>Configure database permissions
After creating the database, you need to assign permissions to it. In MDT, the account you used to run the deployment is used to access the database. In this environment, the network access account is MDT\_BA.
1. On MDT01, start SQL Server Management Studio.
2. In the **Connect to Server** dialog box, in the **Server name** list, select **MDT01\\SQLEXPRESS** and click **Connect**.
3. In the **Object Explorer** pane, expand the top-level **Security** node, right-click **Logins**, and select **New Login**.
![figure 9](images/mdt-09-fig09.png)
Figure 9. The top-level Security node.
4. On the **Login - New** page, next to the **Login** name field, click **Search**, and search for **CONTOSO\\MDT\_BA**. Then in the left pane, select **User Mapping**. Select the **MDT** database, and assign the following roles:
1. db\_datareader
2. public (default)
5. Click **OK**, and close SQL Server Management Studio.
![figure 10](images/mdt-09-fig10.png)
Figure 10. Creating the login and settings permissions to the MDT database.
## <a href="" id="sec04"></a>Create an entry in the database
To start using the database, you add a computer entry and assign a description and computer name. Use the computer's MAC Address as the identifier.
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, expand **Advanced Configuration**, and expand **Database**.
2. Right-click **Computers**, select **New**, and add a computer entry with the following settings:
1. Description: New York Site - PC00075
2. MacAddress: &lt;PC00075 MAC Address in the 00:00:00:00:00:00 format&gt;
3. Details Tab / OSDComputerName: PC00075
![figure 11](images/mdt-09-fig11.png)
Figure 11. Adding the PC00075 computer to the database.
## Related topics
[Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
[Use web services in MDT](use-web-services-in-mdt-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
 
 

28
windows/deploy/use-the-volume-activation-management-tool-client.md
View File

@ -2,14 +2,16 @@
title: Use the Volume Activation Management Tool (Windows 10)
description: The Volume Activation Management Tool (VAMT) provides several useful features, including the ability to perform VAMT proxy activation and to track and monitor several types of product keys.
ms.assetid: b11f0aee-7b60-44d1-be40-c960fc6c4c47
ms.pagetype: activation
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Use the Volume Activation Management Tool
**Applies to**
- Windows 10
- Windows 8.1
@ -18,33 +20,53 @@ author: jdeckerMS
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
The Volume Activation Management Tool (VAMT) provides several useful features, including the ability to perform VAMT proxy activation and to track and monitor several types of product keys.
By using the VAMT, you can automate and centrally manage the volume, retail, and MAK activation process for Windows, Office, and select other Microsoft products. The VAMT can manage volume activation by using MAKs or KMS. It is a standard Microsoft Management Console snap-in, and it can be installed on any computer running Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.
By using the VAMT, you can automate and centrally manage the volume, retail, and MAK activation process for Windows, Office, and select other Microsoft products. The VAMT can manage volume activation by using MAKs or KMS. It is a standard Microsoft Management Console snap-in, and it can be
installed on any computer running Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.
The VAMT is distributed as part of the Windows Assessment and Deployment Kit (Windows ADK), which is a free download available from Microsoft Download Center. For more information, see [Windows Assessment and Deployment Kit (Windows ADK) for Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=526740).
In Windows Server 2012 R2, you can install the VAMT directly from Server Manager without downloading the Windows ADK by selecting the Volume Activation Services role or the Remote Server Administration Tools/Role Administration Tools/Volume Activation Tools feature.
## Activating with the Volume Activation Management Tool
You can use the VAMT to complete the activation process in products by using MAK and retail keys, and you can work with computers individually or in groups. The VAMT enables two activation scenarios:
- **Online activation**. Online activation enables you to activate over the Internet any products that are installed with MAK, KMS host, or retail product keys. You can activate one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
- **Proxy activation**. This activation method enables you to perform volume activation for products that are installed on client computers that do not have Internet access. The VAMT host computer distributes a MAK, KMS host key, or retail product key to one or more client products and collects the installation ID from each client product. The VAMT host sends the installation IDs to Microsoft on behalf of the client products and obtains the corresponding confirmation IDs. The VAMT host then installs the confirmation IDs on the client products to complete their activation.
By using this method, only the VAMT host computer requires Internet access. Proxy activation by using the VAMT is beneficial for isolated network segments and for cases where your organization has a mix of retail, MAK, and KMS-based activations.
## Tracking products and computers with the Volume Activation Management Tool
The VAMT provides an overview of the activation and licensing status of computers across your network, as shown in Figure 18. Several prebuilt reports are also available to help you proactively manage licensing.
![VAMT showing the licensing status of multiple computers](images/volumeactivationforwindows81-18.jpg)
**Figure 18**. The VAMT showing the licensing status of multiple computers
## Tracking key usage with the Volume Activation Management Tool
The VAMT makes it easier to track the various keys that are issued to your organization. You can enter each key into VAMT, and then the VAMT can use those keys for online or proxy activation of clients. The tool can also describe what type of key it is and to which product group it belongs. The VAMT is the most convenient way to quickly determine how many activations remain on a MAK. Figure 19 shows an example of key types and usage.
![VAMT showing key types and usage](images/volumeactivationforwindows81-19.jpg)
**Figure 19**. The VAMT showing key types and usage
## Other Volume Activation Management Tool features
The VAMT stores information in a Microsoft SQL Server database for performance and flexibility, and it provides a single graphical user interface for managing activations and performing other activation-related tasks, such as:
- **Adding and removing computers**. You can use the VAMT to discover computers in the local environment. The VAMT can discover computers by querying AD DS, workgroups, or individual computer names or IP addresses, or through a general LDAP query.
- **Discovering products**. You can use the VAMT to discover Windows, Windows Server, Office, and select other products that are installed on the client computers.
- **Managing activation data**. The VAMT stores activation data in a SQL Server database. The tool can export this data in XML format to other VAMT hosts or to an archive.
For more information, see:
- [Volume Activation Management Tool (VAMT) Overview](http://go.microsoft.com/fwlink/p/?LinkId=618266)
- [VAMT Step-by-Step Scenarios](http://go.microsoft.com/fwlink/p/?LinkId=618267)
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
 

11
windows/deploy/use-vamt-in-windows-powershell.md
View File

@ -2,13 +2,15 @@
title: Use VAMT in Windows PowerShell (Windows 10)
description: Use VAMT in Windows PowerShell
ms.assetid: 13e0ceec-d827-4681-a5c3-8704349e3ba9
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Use VAMT in Windows PowerShell
The Volume Activation Management Tool (VAMT) PowerShell cmdlets can be used to perform the same functions as the Vamt.exe command-line tool.
**To install PowerShell 3.0**
- VAMT PowerShell cmdlets require Windows PowerShell, which is included in Windows 10, Windows 8 and Windows Server® 2012. You can download PowerShell for Windows 7 or other operating systems from the [Microsoft Download Center](http://go.microsoft.com/fwlink/p/?LinkId=218356).
@ -16,11 +18,13 @@ The Volume Activation Management Tool (VAMT) PowerShell cmdlets can be used to p
- In addition to PowerShell, you must import the VAMT PowerShell module. The module is included in the VAMT 3.0 folder after you install the Windows Assessment and Deployment Kit (Windows ADK).
**To prepare the VAMT PowerShell environment**
1. To open PowerShell with administrative credentials, click **Start** and type “PowerShell” to locate the program. Right-click **Windows PowerShell**, and then click **Run as administrator**. To open PowerShell in Windows 7, click **Start**, click **All Programs**, click **Accessories**, click **Windows PowerShell**, right-click **Windows PowerShell**, and then click **Run as administrator**.
**Important**  
If you are using a computer that has an 64-bit processor, select **Windows PowerShell (x86)**. VAMT PowerShell cmdlets are supported for the x86 architecture only. You must use an x86 version of Windows PowerShell to import the VAMT module, which are available in these directories:
- The x86 version of PowerShell is available in C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe
- The x86 version of the PowerShell ISE is available in C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell\_ise.exe
2. For all supported operating systems you can use the VAMT PowerShell module included with the Windows ADK. By default, the module is installed with the Windows ADK in the VAMT folder. Change directories to the directory where VAMT is located.
For example, if the Windows ADK is installed in the default location of `C:\Program Files(x86)\Windows Kits\10`, type:
``` ps1
@ -31,7 +35,9 @@ The Volume Activation Management Tool (VAMT) PowerShell cmdlets can be used to p
Import-Module .\VAMT.psd1
```
Where **Import-Module** imports a module only into the current session. To import the module into all sessions, add an **Import-Module** command to a Windows PowerShell profile. For more information about profiles, type `get-help about_profiles`.
## To Get Help for VAMT PowerShell cmdlets
You can view all of the help sections for a VAMT PowerShell cmdlet, or you can view only the section that you are interested in. To view all of the Help content for a VAMT cmdlet, type:
``` ps1
get-help <cmdlet name> -all
@ -40,9 +46,12 @@ For example, type:
``` ps1
get-help get-VamtProduct -all
```
**Warning**
The update-help cmdlet is not supported for VAMT PowerShell cmdlets. To view online help for VAMT cmdlets, you can use the -online option with the get-help cmdlet. For more information, see [Volume Activation Management Tool (VAMT) Cmdlets in Windows PowerShell](http://go.microsoft.com/fwlink/p/?LinkId=242278).
**To view VAMT PowerShell Help sections**
1. To get the syntax to use with a cmdlet, type the following at a command prompt:
``` ps1
get-help <cmdlet name>

43
windows/deploy/use-web-services-in-mdt-2013.md
View File

@ -2,17 +2,21 @@
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.pagetype: mdt
keywords: ["deploy, web apps"]
keywords: deploy, web apps
ms.prod: W10
ms.mktglfcycl: deploy
ms.pagetype: mdt
ms.sitesec: library
author: mtniehaus
---
# 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](http://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.
@ -22,9 +26,13 @@ In these steps we assume you have installed Microsoft Visual Studio Express 2013
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**.
@ -34,32 +42,50 @@ This section assumes that you have enabled the Web Server (IIS) role on MDT01.
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]
@ -72,7 +98,9 @@ After verifying the web service using Internet Explorer, you are ready to do the
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
@ -80,15 +108,24 @@ After verifying the web service using Internet Explorer, you are ready to do the
.\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-2013-for-bitlocker.md)
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
[Configure MDT for UserExit scripts](configure-mdt-2013-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-2013.md)
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
 
 

4
windows/deploy/vamt-known-issues.md
View File

@ -2,13 +2,15 @@
title: VAMT Known Issues (Windows 10)
description: VAMT Known Issues
ms.assetid: 8992f1f3-830a-4ce7-a248-f3a6377ab77f
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# VAMT Known Issues
The following list contains the current known issues with the Volume Activation Management Tool (VAMT) 3.0.
- The VAMT Windows Management Infrastructure (WMI) remote operations may take longer to execute if the target computer is in a sleep or standby state.
- Recovery of Non-Genuine computers is a two-step process. VAMT can be used to install a new product key and activate the computer. However, the computer itself must visit the [Windows Genuine Advantage](http://go.microsoft.com/fwlink/p/?linkid=182914) Web site to revalidate the computer's Genuine status. Upon successfully completing this step, the computer will be restored to full functionality. For more information on recovering Non-Genuine Windows computers, go to [Windows Volume Activation](http://go.microsoft.com/fwlink/p/?linkid=184668).

14
windows/deploy/vamt-requirements.md
View File

@ -2,22 +2,30 @@
title: VAMT Requirements (Windows 10)
description: VAMT Requirements
ms.assetid: d14d152b-ab8a-43cb-a8fd-2279364007b9
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# VAMT Requirements
This topic includes info about the product key and system requirements for VAMT.
## Product Key Requirements
The Volume Activation Management Tool (VAMT) can be used to perform activations using any of the following types of product keys.
|Product key type |Where to obtain |
|-----------------|----------------|
|<ul><li>Multiple Activation Key (MAK)</li><li>Key Management Service (KMS) host key (CSVLK)</li><li>KMS client setup keys (GVLK)</li></ul> |Volume licensing keys can only be obtained with a signed contract from Microsoft. For more info, see the [Microsoft Volume Licensing portal](http://go.microsoft.com/fwlink/p/?LinkId=227282). |
|Retail product keys |Obtained at time of product purchase. |
## System Requirements
The following table lists the system requirements for the VAMT host computer.
|Item |Minimum system requirement |
|-----|---------------------------|
|Computer and Processor |1 GHz x86 or x64 processor |
@ -27,6 +35,8 @@ The following table lists the system requirements for the VAMT host computer.
|Display |1024x768 or higher resolution monitor |
|Network |Connectivity to remote computers via Windows® Management Instrumentation (TCP/IP) and Microsoft® Activation Web Service on the Internet via HTTPS |
|Operating System |Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 R2, or Windows Server 2012. |
|Additional Requirements |<ul><li>Connection to a SQL Server database. For more info, see [Install VAMT](install-vamt.md).</li><li>PowerShell 3.0: For Windows 8, Windows 8.1, Windows 10, and Windows Server® 2012, PowerShell is included in the installation. For previous versions of Windows and Windows Server, you must download PowerShell 3.0. To download PowerShell, go to [Download Windows PowerShell 3.0](http://go.microsoft.com/fwlink/p/?LinkId=218356).</li><li>If installing on Windows Server 2008 R2, you must also install .NET Framework 3.51.</li></ul> |
|Additional Requirements |<ul><li>Connection to a SQL Server database. For more info, see [Install VAMT](install-vamt.md).</li><li>PowerShell 3.0: For Windows 8, Windows 8.1, Windows 10, and Windows Server® 2012, PowerShell is included in the installation. For previous versions of Windows and
Windows Server, you must download PowerShell 3.0. To download PowerShell, go to [Download Windows PowerShell 3.0](http://go.microsoft.com/fwlink/p/?LinkId=218356).</li><li>If installing on Windows Server 2008 R2, you must also install .NET Framework 3.51.</li></ul> |
## Related topics
- [Install and Configure VAMT](install-configure-vamt.md)

7
windows/deploy/vamt-step-by-step.md
View File

@ -2,20 +2,25 @@
title: VAMT Step-by-Step Scenarios (Windows 10)
description: VAMT Step-by-Step Scenarios
ms.assetid: 455c542c-4860-4b57-a1f0-7e2d28e11a10
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# VAMT Step-by-Step Scenarios
This section provides step-by-step instructions on implementing the Volume Activation Management Tool (VAMT) in typical environments. VAMT supports many common scenarios; the scenarios in this section describe some of the most common to get you started.
## In this Section
|Topic |Description |
|------|------------|
|[Scenario 1: Online Activation](scenario-online-activation-vamt.md) |Describes how to distribute Multiple Activation Keys (MAKs) to products installed on one or more connected computers within a network, and how to instruct these products to contact Microsoft over the Internet for activation. |
|[Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md) |Describes how to use two VAMT host computers — the first one with Internet access and a second computer within an isolated workgroup — as proxies to perform MAK volume activation for workgroup computers that do not have Internet access. |
|[Scenario 3: KMS Client Activation](scenario-kms-activation-vamt.md) |Describes how to use VAMT to configure client products for Key Management Service (KMS) activation. By default, volume license editions of Windows 10, Windows Vista, Windows® 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, or Windows Server® 2012, and Microsoft® Office 2010 use KMS for activation. |
## Related topics
- [Introduction to VAMT](introduction-vamt.md)
 

13
windows/deploy/volume-activation-management-tool.md
View File

@ -2,13 +2,15 @@
title: Volume Activation Management Tool (VAMT) Technical Reference (Windows 10)
description: The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office, and select other Microsoft products volume and retail-activation process.
ms.assetid: 1df0f795-f41c-473b-850c-e98af1ad2f2a
ms.pagetype: activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Volume Activation Management Tool (VAMT) Technical Reference
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office, and select other Microsoft products volume and retail-activation process.
VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in that requires the Microsoft Management Console (MMC) 3.0. VAMT can be installed on any computer that has one of the following Windows operating systems:
- Windows® 7
@ -18,10 +20,15 @@ VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the W
- Windows Server 2008 R2
- Windows Server® 2012
- Windows Server 2012 R2
**Important**  
VAMT is designed to manage volume activation for: Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Microsoft Office 2010, and Microsoft Office 2013. Computers installed with volume editions of **Windows XP** or **Windows Server 2003** cannot be managed using VAMT. However, Office 2010 and Office 2013 products installed on these two operating systems can still be managed.
VAMT is designed to manage volume activation for: Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Microsoft Office 2010, and Microsoft Office 2013. Computers installed with volume editions of
**Windows XP** or **Windows Server 2003** cannot be managed using VAMT. However, Office 2010 and Office 2013 products installed on these two operating systems can still be managed.
VAMT is only available in an EN-US (x86) package.
## In this Section
|Topic |Description |
|------|------------|
|[Introduction to VAMT](introduction-vamt.md) |Provides a description of VAMT and common usages. |
@ -34,5 +41,3 @@ VAMT is only available in an EN-US (x86) package.
|[VAMT Step-by-Step Scenarios](vamt-step-by-step.md) |Provides step-by-step instructions for using VAMT in typical environments. |
|[VAMT Known Issues](vamt-known-issues.md) |Lists known issues in VAMT. |
 
 
 

21
windows/deploy/volume-activation-windows-10.md
View File

@ -2,14 +2,16 @@
title: Volume Activation for Windows 10 (Windows 10)
description: This guide is designed to help organizations that are planning to use volume activation to deploy and activate Windows 10, including organizations that have used volume activation for earlier versions of Windows.
ms.assetid: 6e8cffae-7322-4fd3-882a-cde68187aef2
ms.pagetype: activation
keywords: ["vamt", "volume activation", "activation", "windows activation"]
keywords: vamt, volume activation, activation, windows activation
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
author: jdeckerMS
---
# Volume Activation for Windows 10
**Applies to**
- Windows 10
- Windows 8.1
@ -18,17 +20,27 @@ author: jdeckerMS
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
**Looking for volume licensing information?**
- [Download the Volume Licensing Reference Guide for Windows 10 Desktop Operating System](http://go.microsoft.com/fwlink/p/?LinkId=620104)
**Looking for retail activation?**
- [Get Help Activating Microsoft Windows](http://go.microsoft.com/fwlink/p/?LinkId=618644)
This guide is designed to help organizations that are planning to use volume activation to deploy and activate Windows 10, including organizations that have used volume activation for earlier versions of Windows.
*Volume activation* is the process that Microsoft volume licensing customers use to automate and manage the activation of Windows operating systems, Microsoft Office, and other Microsoft products across large organizations. Volume licensing is available to customers who purchase software under various volume programs (such as Open and Select) and to participants in programs such as the Microsoft Partner Program and MSDN Subscriptions.
Volume activation is a configurable solution that helps automate and manage the product activation process on computers running Windows operating systems that have been licensed under a volume licensing program. Volume activation is also used with other software from Microsoft (most notably the Office suites) that are sold under volume licensing agreements and that support volume activation.
This guide provides information and step-by-step guidance to help you choose a volume activation method that suits your environment, and then to configure that solution successfully. This guide describes the volume activation features that are available in Windows 10 and Windows Server 2012 R2 and the tools that are provided in these versions of Windows and Windows Server to manage volume activation.
Because most organizations will not immediately switch all computers to Windows 10, practical volume activation strategies must also take in to account how to work with the Windows 8, Windows 7, Windows Server 2012, and Windows Server 2008 R2Windows Server 2008 R2 operating systems. This guide discusses how the new volume activation tools can support earlier operating systems, but it does not discuss the tools that are provided with earlier operating system versions.
Because most organizations will not immediately switch all computers to Windows 10, practical volume activation strategies must also take in to account how to work with the Windows 8, Windows 7, Windows Server 2012, and Windows Server 2008 R2Windows Server 2008 R2 operating systems. This guide
discusses how the new volume activation tools can support earlier operating systems, but it does not discuss the tools that are provided with earlier operating system versions.
Volume activation—and the need for activation itself—is not new, and this guide does not review all of its concepts and history. You can find additional background in the appendices of this guide. For more information, see [Volume Activation Overview](http://go.microsoft.com/fwlink/p/?LinkId=618209) in the TechNet Library.
If you would like additional information about planning a volume activation deployment specifically for Windows 7 and Windows Server 2008 R2, please see the [Volume Activation Planning Guide for Windows 7](http://go.microsoft.com/fwlink/p/?LinkId=618210).
To successfully plan and implement a volume activation strategy, you must:
- Learn about and understand product activation.
- Review and evaluate the available activation types or models.
@ -37,7 +49,9 @@ To successfully plan and implement a volume activation strategy, you must:
- Determine the types and number of product keys you will need.
- Determine the monitoring and reporting needs in your organization.
- Install and configure the tools required to support the methods selected.
Keep in mind that the method of activation does not change an organization’s responsibility to the licensing requirements. You must ensure that all software used in your organization is properly licensed and activated in accordance with the terms of the licensing agreements in place.
**In this guide:**
- [Plan for volume activation](plan-for-volume-activation-client.md)
- [Activate using Key Management Service](activate-using-key-management-service-vamt.md)
@ -47,4 +61,3 @@ Keep in mind that the method of activation does not change an organization’s r
- [Use the Volume Activation Management Tool](use-the-volume-activation-management-tool-client.md)
- [Appendix: Information sent to Microsoft during activation](appendix-information-sent-to-microsoft-during-activation-client.md)
 
 

79
windows/keep-secure/access-credential-manager-as-a-trusted-caller.md
View File

@ -2,87 +2,84 @@
title: Access Credential Manager as a trusted caller (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Access Credential Manager as a trusted caller security policy setting.
ms.assetid: a51820d2-ca5b-47dd-8e9b-d7008603db88
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Access Credential Manager as a trusted caller
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Access Credential Manager as a trusted caller** security policy setting.
## Reference
The **Access Credential Manager as a trusted caller** policy setting is used by Credential Manager during backup and restore. No accounts should have this privilege because it is assigned only to the Winlogon service. Saved credentials of users may be compromised if this privilege is given to other entities.
Constant: SeTrustedCredManAccessPrivilege
### Possible values
- User-defined list of accounts
- Not defined
### Best practices
- Do not modify this policy setting from the default.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client computer effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default domain policy | Not defined |
| Default domain controller policy | Not defined |
| Stand-alone server default settings | Not defined |
| Domain controller effective default settings | Not defined |
| Member server effective default settings | Not defined |
| Client computer effective default settings | Not defined |
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
If an account is given this user right, the user of the account may create an application that calls into Credential Manager and is returned the credentials for another user.
### Countermeasure
Do not define the **Access Credential Manager as a trusted caller** policy setting for any accounts besides Credential Manager.
### Potential impact
None. Not defined is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 

87
windows/keep-secure/access-this-computer-from-the-network.md
View File

@ -2,96 +2,99 @@
title: Access this computer from the network (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Access this computer from the network security policy setting.
ms.assetid: f6767bc2-83d1-45f1-847c-54f5362db022
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Access this computer from the network
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Access this computer from the network** security policy setting.
## Reference
The **Access this computer from the network** policy setting determines which users can connect to the device from the network. This capability is required by a number of network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).
Users, devices, and service accounts gain or lose the **Access this computer from network** user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers.
By default, user accounts and machine accounts are granted the **Access this computer from network** user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).
Constant: SeNetworkLogonRight
### Possible values
- User-defined list of accounts
- Not defined
### Best practices
- On desktop devices or member servers, grant this right only to users and administrators.
- On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators.
- This setting includes the **Everyone** group to ensure backward compatibility. Upon Windows upgrade, after you have verified that all users and groups are correctly migrated, you should remove the **Everyone** group and use the **Authenticated Users** group instead.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Everyone, Administrators, Users, Backup Operators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Everyone, Administrators, Users, Backup Operators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client computer effective default settings</p></td>
<td align="left"><p>Everyone, Administrators, Users, Backup Operators</p></td>
</tr>
</tbody>
</table>
|Server type of GPO | Default value |
| - | - |
| Default domain policy | Not defined |
| Default domain controller policy | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access |
| Stand-alone server default settings |Everyone, Administrators, Users, Backup Operators |
| Domain controller effective default settings | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access |
| Member server effective default settings | Everyone, Administrators, Users, Backup Operators |
| Client computer effective default settings |Everyone, Administrators, Users, Backup Operators |
 
## Policy management
When modifying this user right, the following actions might cause users and services to experience network access issues:
- Removing the Enterprise Domain Controllers security group
- Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network
- Removing all user and machine accounts
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the **Access this computer from the network** user right is required for users to connect to shared printers and folders. If this user right is assigned to the **Everyone** group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 do not include the **Everyone** group. However, if a device is upgraded and the original device includes the **Everyone** group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device.
### Countermeasure
Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared from servers in the domain if members of the **Domain Users** group are included in the local **Users** group.
**Note**  
If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement.
Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared
from servers in the domain if members of the **Domain Users** group are included in the local **Users** group.
> **Note** If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement.
 
### Potential impact
If you remove the **Access this computer from the network** user right on domain controllers for all users, no one can log on to the domain or use network resources. If you remove this user right on member servers, users cannot connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to additional accounts that are required by those components. It is important to verify that authorized users are assigned this user right for the devices that they need to access the network.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 

71
windows/keep-secure/account-lockout-duration.md
View File

@ -2,76 +2,69 @@
title: Account lockout duration (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Account lockout duration security policy setting.
ms.assetid: a4167bf4-27c3-4a9b-8ef0-04e3c6ec3aa4
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Account lockout duration
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting.
## Reference
The **Account lockout duration** policy setting determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md).
This policy setting is dependent on the **Account lockout threshold** policy setting that is defined, and it must be greater than or equal to the value specified for the [Reset account lockout counter after](reset-account-lockout-counter-after.md) policy setting.
### Possible values
- A user-defined number of minutes from 0 through 99,999
- Not defined
If [Account lockout threshold](account-lockout-threshold.md) is configured, after the specified number of failed attempts, the account will be locked out. If th **Account lockout duration** is set to 0, the account will remain locked until an administrator unlocks it manually.
It is advisable to set **Account lockout duration** to approximately 30 minutes. To specify that the account will never be locked out, set the value to 0. To configure the value for this policy setting so that it never automatically unlocks the account might seem like a good idea; however, doing so can increase the number of requests that your organization’s Help Desk receives to unlock accounts that were locked by mistake.
### Location
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
### Default values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client computer effective default settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy | Not defined |
| Default domain controller policy | Not defined |
| Stand-alone server default settings | Not applicable |
| Domain controller effective default settings | Not defined |
| Member server effective default settings | Not defined |
| Client computer effective default settings | Not applicable |
 
## Security considerations
More than a few unsuccessful password submissions during an attempt to log on to a computer might represent an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server operating systems can track logon attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached.
### Vulnerability
A denial-of-service (DoS) condition can be created if an attacker abuses the [Account lockout threshold](account-lockout-threshold.md) policy setting and repeatedly attempts to log on with a specific account. After you configure the Account lockout threshold policy setting, the account will be locked out after the specified number of failed attempts. If you configure the **Account lockout duration** policy setting to 0, the account remains locked until you unlock it manually.
### Countermeasure
Configure the **Account lockout duration** policy setting to an appropriate value for your environment. To specify that the account will remain locked until you manually unlock it, configure the value to 0. When the **Account lockout duration** policy setting is configured to a nonzero value, automated attempts to guess account passwords are delayed for this interval before resuming attempts against a specific account. Using this setting in combination with the [Account lockout threshold](account-lockout-threshold.md) policy setting makes automated password guessing attempts more difficult.
### Potential impact
Configuring the **Account lockout duration** policy setting to 0 so that accounts cannot be automatically unlocked can increase the number of requests that your organization's Help Desk receives to unlock accounts that were locked by mistake.
## Related topics
[Account Lockout Policy](account-lockout-policy.md)
 
 

41
windows/keep-secure/account-lockout-policy.md
View File

@ -2,47 +2,34 @@
title: Account Lockout Policy (Windows 10)
description: Describes the Account Lockout Policy settings and links to information about each policy setting.
ms.assetid: eb968c28-17c5-405f-b413-50728cb7b724
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Account Lockout Policy
**Applies to**
- Windows 10
Describes the Account Lockout Policy settings and links to information about each policy setting.
Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your system might be a malicious user who is attempting to determine an account password by trial and error. Windows domain controllers keep track of logon attempts, and domain controllers can be configured to respond to this type of potential attack by disabling the account for a preset period of time. Account Lockout Policy settings control the threshold for this response and the actions to be taken after the threshold is reached. The Account Lockout Policy settings can be configured in the following location in the Group Policy Management Console: **Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**.
The following topics provide a discussion of each policy setting's implementation and best practices considerations, policy location, default values for the server type or Group Policy Object (GPO), relevant differences in operating system versions, and security considerations (including the possible vulnerabilities of each policy setting), countermeasures that you can implement, and the potential impact of implementing the countermeasures.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Account lockout duration](account-lockout-duration.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Account lockout duration</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Account lockout threshold](account-lockout-threshold.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Account lockout threshold</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Reset account lockout counter after](reset-account-lockout-counter-after.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Reset account lockout counter after</strong> security policy setting.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Account lockout duration](account-lockout-duration.md) | Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting. |
| [Account lockout threshold](account-lockout-threshold.md) | Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting. |
| [Reset account lockout counter after](reset-account-lockout-counter-after.md) | Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting. |
 
## Related topics
[Configure security policy settings](how-to-configure-security-policy-settings.md)
 
 

88
windows/keep-secure/account-lockout-threshold.md
View File

@ -2,104 +2,104 @@
title: Account lockout threshold (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Account lockout threshold security policy setting.
ms.assetid: 4904bb40-a2bd-4fef-a102-260ba8d74e30
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Account lockout threshold
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting.
## Reference
The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account cannot be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md).
Failed password attempts on workstations or member servers that have been locked by using CTRL+ALT+DELETE or password-protected screen savers do not count as failed sign-in attempts unless [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) is set to **Enabled**. If Interactive logon: Require Domain Controller authentication to unlock workstation is enabled, repeated failed password attempts to unlock the workstation will count against the account lockout threshold.
Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the effectiveness of such attacks.
However, it is important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account.
### Possible values
It is possible to configure the following values for the **Account lockout threshold** policy setting:
- A user-defined number from 0 through 999
- Not defined
Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their identified threats and the risks that they are trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this topic
### Best practices
The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, a setting above 4 and below 10 could be an acceptable starting point for your organization.
**Important**  
Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic.
> **Important:**  Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic.
 
### Location
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**
### Default values
The following table lists the actual and effective default policy values. Default values are also listed on the property page for the policy setting.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or Group Policy Object (GPO)</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>0 invalid sign-in attempts</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>0 invalid sign-in attempts</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>0 invalid sign-in attempts</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>0 invalid sign-in attempts</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>0 invalid sign-in attempts</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy | 0 invalid sign-in attempts |
| Default domain controller policy | Not defined |
| Stand-alone server default settings | 0 invalid sign-in attempts |
| Domain controller effective default settings | 0 invalid sign-in attempts |
| Member server effective default settings |0 invalid sign-in attempts |
| Effective GPO default settings on client computers |0 invalid sign-in attempts |
 
### Policy management
This section describes features and tools that are available to help you manage this policy setting.
### Restart requirements
None. Changes to this policy setting become effective without a computer restart when they are saved locally or distributed through Group Policy.
### <a href="" id="bkmk-impleconsiderations"></a>Implementation considerations
Implementation of this policy setting is dependent on your operational environment. You should consider threat vectors, deployed operating systems, and deployed apps, for example:
- The likelihood of an account theft or a DoS attack is based on the security design for your systems and environment. You should set the account lockout threshold in consideration of the known and perceived risk of those threats.
- When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases.
- Not all apps that are used in your environment effectively manage how many times a user can attempt to sign-in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Brute force password attacks can use automated methods to try millions of password combinations for any user account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed sign-in attempts that can be performed.
However, a DoS attack could be performed on a domain that has an account lockout threshold configured. An attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker might be able to lock every account without needing any special privileges or being authenticated in the network.
**Note**  
Offline password attacks are not countered by this policy setting.
> **Note:** Offline password attacks are not countered by this policy setting.
 
### <a href="" id="bkmk-countermeasure"></a>Countermeasure
Because vulnerabilities can exist when this value is configured and when it is not configured, two distinct countermeasures are defined. Organizations should weigh the choice between the two, based on their identified threats and the risks that they want to mitigate. The two countermeasure options are:
- Configure the **Account lockout threshold** setting to 0. This configuration ensures that accounts will not be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because it does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:
- The password policy setting requires all users to have complex passwords of 8 or more characters.
- A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment.
- Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account.
A good recommendation for such a configuration is 50 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed sign-in attempts.
Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems.
### Potential impact
If this policy setting is enabled, a locked account is not usable until it is reset by an administrator or until the account lockout duration expires. Enabling this setting will likely generate a number of additional Help Desk calls.
If you configure the **Account lockout threshold** policy setting to 0, there is a possibility that an malicious user's attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place.
If you configure this policy setting to a number greater than 0, an attacker can easily lock any accounts for which the account name is known. This is especially dangerous considering that no credentials other than access to the network are necessary to lock the accounts.
## Related topics
[Account Lockout Policy](account-lockout-policy.md)
 
 

45
windows/keep-secure/account-policies.md
View File

@ -2,50 +2,33 @@
title: Account Policies (Windows 10)
description: An overview of account policies in Windows and provides links to policy descriptions.
ms.assetid: 711b3797-b87a-4cd9-a2e3-1f8ef18688fb
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Account Policies
**Applies to**
- Windows 10
An overview of account policies in Windows and provides links to policy descriptions.
All account policies settings applied by using Group Policy are applied at the domain level. Default values are present in the built-in default domain controller policy for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. The domain account policy becomes the default local account policy of any device that is a member of the domain. If these policies are set at any level below the domain level in Active Directory Domain Services (AD DS), they affect only local accounts on member servers.
**Note**  
Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).
> **Note:**  Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).
 
The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users log on to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where neither an OU account policy nor a domain policy applies.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Password Policy](password-policy.md)</p></td>
<td align="left"><p>An overview of password policies for Windows and links to information for each policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Account Lockout Policy](account-lockout-policy.md)</p></td>
<td align="left"><p>Describes the Account Lockout Policy settings and links to information about each policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Kerberos Policy](kerberos-policy.md)</p></td>
<td align="left"><p>Describes the Kerberos Policy settings and provides links to policy setting descriptions.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Password Policy](password-policy.md) | An overview of password policies for Windows and links to information for each policy setting. |
| [Account Lockout Policy](account-lockout-policy.md) | Describes the Account Lockout Policy settings and links to information about each policy setting. |
| [Kerberos Policy](kerberos-policy.md) | Describes the Kerberos Policy settings and provides links to policy setting descriptions. |
 
## Related topics
[Configure security policy settings](how-to-configure-security-policy-settings.md)
 
 

87
windows/keep-secure/accounts-administrator-account-status.md
View File

@ -2,102 +2,105 @@
title: Accounts Administrator account status (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Accounts Administrator account status security policy setting.
ms.assetid: 71a3bd48-1014-49e0-a936-bfe9433af23e
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Accounts: Administrator account status
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting.
## Reference
This security setting determines whether the local administrator account is enabled or disabled.
If you try to enable the administrator account after it has been disabled, and if the current administrator password does not meet the password requirements, you cannot enable the account. In this case, an alternative member of the Administrators group must reset the password on the administrator account.
If you disable this policy setting, and one of the following conditions exists on the computer, the administrator account is not disabled.
1. No other local administrator account exists
2. The administrator account is currently in use
3. All other local administrator accounts are:
1. Disabled
2. Listed in the [Deny log on locally](deny-log-on-locally.md) User Rights Assignment
If the current administrator password does not meet the password requirements, you will not be able to enable the administrator account again after it has been disabled. In this case, another member of the Administrators group must set the password on the administrator account.
### Possible values
- Enabled
- Disabled
- Not defined
By default, this setting is **Not defined** on domain controllers and **Enabled** on stand-alone servers.
### Best practices
- Disabling the administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there is no other local administrator account, you must restart the computer in safe mode to fix the problem that broke your connection status.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| Default Domain Policy | Not defined |
| Default Domain Controller Policy |Not defined |
| Stand-Alone Server Default Settings | Enabled |
| DC Effective Default Settings | Enabled |
| Member Server Effective Default Settings | Enabled |
| Client Computer Effective Default Settings | Disabled |
 
## Policy management
Disabling the administrator account can become a maintenance issue under certain circumstances. Reasons that an organization might consider disabling the built-in administrator account include:
- For some organizations, periodically changing the passwords for local accounts can be a daunting management challenge.
- By default, the administrator account cannot be locked—no matter how many failed attempts to sign in a user accrues. This makes it a prime target for brute-force, password-guessing attacks.
- This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This means that even if you rename the administrator account, a malicious user could start a brute-force attack by using the SID.
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
### Safe mode considerations
When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-domain joined and there are no other active local administrator accounts. If the computer is joined to a domain, the disabled administrator account is not enabled.
If the administrator account is disabled, you can still access the computer by using safe mode with the current administrative credentials. For example, if a failure occurs using a secure channel with a domain-joined computer, and there is no other local administrator account, you must restart the device in safe mode to fix the failure.
### How to access a disabled Administrator account
You can use the following methods to access a disabled Administrator account:
- When there is only one local administrator account that is disabled, start the device in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that computer.
- When there are local administrator accounts in addition to the built-in account, start the computer in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that device. An alternate method is to sign in to Windows by using another local Administrator account that was created.
- When there are local administrator accounts in addition to the built-in account, start the computer in safe mode (locally or over a network), and sign in by using the credentials for the administrator account on that device. An alternate method is to sign in to Windows by using another local
Administrator account that was created.
- When multiple domain-joined servers have a disabled local Administrator account that can be accessed in safe mode, you can remotely run psexec by using the following command: **net user administrator /active: no**.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
The built-in administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum.
### Countermeasure
Disable the **Accounts: Administrator account status** setting so that the built-in Administrator account cannot be used in a normal system startup.
If it is very difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in administrator account instead of relying on regular password changes to protect it from attack.
### Potential impact
Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there is no other local administrator account, you must restart in safe mode to fix the problem that caused the secure channel to fail.
If the current administrator password does not meet the password requirements, you cannot enable the administrator account after it is disabled. If this situation occurs, another member of the administrators group must set the password on the administrator account.
## Related topics
[Security Options](security-options.md)
 
 

80
windows/keep-secure/accounts-block-microsoft-accounts.md
View File

@ -2,85 +2,85 @@
title: Accounts Block Microsoft accounts (Windows 10)
description: Describes the best practices, location, values, management, and security considerations for the Accounts Block Microsoft accounts security policy setting.
ms.assetid: 94c76f45-057c-4d80-8d01-033cf28ef2f7
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Accounts: Block Microsoft accounts
**Applies to**
- Windows 10
Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting.
## Reference
This policy setting prevents users from adding new Microsoft accounts on a device
This policy setting prevents users from adding new Microsoft accounts on a device.
If you click the **Users can’t add Microsoft accounts** setting option, users will not be able to switch a local account to a Microsoft account, or connect a domain account to a Microsoft account to drive sync, roaming, or other background services. This is the preferred option if you need to limit the use of Microsoft accounts in your enterprise. Users will still be able to add app-specific Microsoft accounts for use with consumer apps. To block this use, turn off the ability to install consumer apps or the Store.
If you click the **Users can’t add or log on with Microsoft accounts** setting option, existing Microsoft account users will not be able to log on to Windows. Selecting this option might make it impossible for an existing administrator to log on to a computer and manage the system.
If you disable or do not configure this policy (recommended), users will be able to use Microsoft accounts with Windows.
### Possible values
- This policy is disabled
- Users can’t add Microsoft accounts
- Users can’t add or log on with Microsoft accounts
By default, this setting is not defined on domain controllers and disabled on stand-alone servers.
### Best practices
- By disabling or not configuring this policy setting on the client computer, users will be able to use their Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the user to connect a local or domain account to a Microsoft account. This provides a convenient option for your users.
- If you need to limit the use of Microsoft accounts in your organization, click the **Users can’t add Microsoft accounts** setting option so that users will not be able to create new Microsoft accounts on a computer, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined |
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings | Disabled |
| DC Effective Default Settings | Disabled |
| Member Server Effective Default Settings | Disabled |
| Client Computer Effective Default Settings | Disabled |
 
## Policy management
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of the countermeasure implementation.
### Vulnerability
Although Microsoft accounts are password-protected, they also have the potential of greater exposure outside of the enterprise. Additionally, if the owner of a Microsoft account is not easily distinguishable, auditing and forensics become more difficult.
### Countermeasure
Require only domain accounts in your enterprise by limiting the use of Microsoft accounts. Click the **Users can’t add Microsoft accounts** setting option so that users will not be able to create new Microsoft accounts on a device, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account.
### Potential impact
Establishing greater control over accounts in your organization can give you more secure management capabilities, including procedures around password resets.
## Related topics
[Security Options](security-options.md)
 
 

71
windows/keep-secure/accounts-guest-account-status.md
View File

@ -2,77 +2,70 @@
title: Accounts Guest account status (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Accounts Guest account status security policy setting.
ms.assetid: 07e53fc5-b495-4d02-ab42-5b245d10d0ce
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Accounts: Guest account status
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting.
## Reference
The **Accounts: Guest account status** policy setting determines whether the Guest account is enabled or disabled.
This account allows unauthenticated network users to gain access to the system by logging on as a Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This means that any network shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This can lead to the exposure or corruption of data.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
Set **Accounts: Guest account status** to Disabled so that the built-in Guest account is no longer usable. All network users will have to authenticate before they can access shared resources on the system. If the Guest account is disabled and [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md) is set to **Guest only**, network logons—such as those performed by the SMB Service—will fail.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined |
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings | Disabled |
| DC Effective Default Settings | Disabled |
| Member Server Effective Default Settings | Disabled |
| Client Computer Effective Default Settings | Disabled |
 
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
The default Guest account allows unauthenticated network users to log on as a Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data.
### Countermeasure
Disable the **Accounts: Guest account status** setting so that the built-in Guest account cannot be used.
### Potential impact
All network users must be authenticated before they can access shared resources. If you disable the Guest account and the **Network Access: Sharing and Security Model** option is set to **Guest Only**, network logons, such as those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact on most organizations because it is the default setting starting with Windows Vista and Windows Server 2003.
## Related topics
[Security Options](security-options.md)
 
 

83
windows/keep-secure/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
View File

@ -2,88 +2,89 @@
title: Accounts Limit local account use of blank passwords to console logon only (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Accounts Limit local account use of blank passwords to console logon only security policy setting.
ms.assetid: a1bfb58b-1ae8-4de9-832b-aa889a6e64bd
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Accounts: Limit local account use of blank passwords to console logon only
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting.
## Reference
The **Accounts: Limit local account use of blank passwords to console logon only** policy setting determines whether remote interactive logons by network services such as Remote Desktop Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client.
This policy setting does not affect interactive logons that are performed physically at the console or logons that use domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting.
Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to log on to systems.
Devices that are not in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the device can log on by using a user account that does not have a password. This is especially important for portable devices.
If you apply this security policy to the Everyone group, no one will be able to log on through Remote Desktop Services.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
- It is advisable to set **Accounts: Limit local account use of blank passwords to console logon only** to Enabled.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined |
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings | Enabled |
| DC Effective Default Settings | Enabled |
| Member Server Effective Default Settings | Enabled |
| Client Computer Effective Default Settings | Enabled |
 
## Policy management
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
### Policy conflict considerations
The policy as distributed through the GPO takes precedence over the locally configured policy setting on a computer joined to a domain. On the domain controller, use ADSI Edit or the dsquery command to determine effective minimum password length.
### Group Policy
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Blank passwords are a serious threat to computer security, and they should be forbidden through organizational policy and suitable technical measures. Starting with Windows Server 2003, the default settings for Active Directory domains require complex passwords of at least seven characters, and eight characters starting with Windows Server 2008. However, if users with the ability to create new accounts bypass your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to log on.
### Countermeasure
Enable the **Accounts: Limit local account use of blank passwords to console logon only** setting.
### Potential impact
None. This is the default configuration.
## Related topics
[Security Options](security-options.md)
 
 

79
windows/keep-secure/accounts-rename-administrator-account.md
View File

@ -2,86 +2,87 @@
title: Accounts Rename administrator account (Windows 10)
description: This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting.
ms.assetid: d21308eb-7c60-4e48-8747-62b8109844f9
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Accounts: Rename administrator account
**Applies to**
- Windows 10
This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting.
## Reference
The **Accounts: Rename administrator account** policy setting determines whether a different account name is associated with the security identifier (SID) for the administrator account.
Because the administrator account exists on all Windows 10 for desktop editions (Home, Pro, Enterprise, and Education), renaming the account makes it slightly more difficult for attackers to guess this user name and password combination.
Rename the Administrator account by specifying a value for the **Accounts: Rename administrator account** policy setting.
### Possible values
- User-defined text
- Not defined
### Best practices
- Be sure to inform users who are authorized to use this account of the new account name.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrator</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Administrator</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrator</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrator</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined |
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings | Administrator |
| DC Effective Default Settings | Administrator |
| Member Server Effective Default Settings | Administrator |
| Client Computer Effective Default Settings | Administrator |
 
## Policy management
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
### Policy conflict considerations
None.
### Group Policy
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
The Administrator account exists on all versions Windows 10 for desktop editions. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination. Beginning with Windows Vista, the person who installs the operating system specifies an account that is the first member of the Administrator group and has full rights to configure the computer so this countermeasure is applied by default on new installations. If a device is upgraded from a previous version of Windows, the account with the name administrator is retained with all the rights and privileges that were defined for the account in the previous installation.
The built-in administrator account cannot be locked out, regardless of how many times an attacker might use a bad password. This capability makes the administrator account a popular target for brute-force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on.
### Countermeasure
Specify a new name in the **Accounts: Rename administrator account** setting to rename the Administrator account.
### Potential impact
You must provide users who are authorized to use this account with the new account name. (The guidance for this setting assumes that the Administrator account was not disabled.)
## Related topics
[Security Options](security-options.md)
 
 

82
windows/keep-secure/accounts-rename-guest-account.md
View File

@ -2,84 +2,86 @@
title: Accounts Rename guest account (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Accounts Rename guest account security policy setting.
ms.assetid: 9b8052b4-bbb9-4cc1-bfee-ce25390db707
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Accounts: Rename guest account
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting.
## Reference
The **Accounts: Rename guest account** policy setting determines whether a different account name is associated with the security identifier (SID) for the Guest account.
### Possible values
- *User-defined text*
- Guest
### Best practices
1. For devices in unsecured locations, renaming the account makes it more difficult for unauthorized users to guess it.
2. For computers in secured or trusted locations, keeping the name of the account as Guest provides consistency among devices
### Location
Computer Configuration\\Windows Settings\\Security Settings
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Guest</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Guest</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Guest</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Guest</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Guest</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p><em>User-defined text</em></p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Guest |
| Default Domain Controller Policy | Guest |
| Stand-Alone Server Default Settings | Guest |
| DC Effective Default Settings | Guest |
| Member Server Effective Default Settings | Guest |
| Client Computer Effective Default Settings | *User-defined text* |
 
## Policy management
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
### Policy conflict considerations
None.
### Group Policy
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges or install software that could be used for a later attack on your system.
The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges
or install software that could be used for a later attack on your system.
### Countermeasure
Specify a new name in the **Accounts: Rename guest account** setting to rename the Guest account. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination.
### Potential impact
There should be little impact because the Guest account is disabled by default in Windows 2000 Server, Windows Server 2003, and Windows XP. For later operating systems, the policy is enabled with **Guest** as the default.
## Related topics
[Security Options](security-options.md)
 
 

75
windows/keep-secure/act-as-part-of-the-operating-system.md
View File

@ -2,87 +2,82 @@
title: Act as part of the operating system (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Act as part of the operating system security policy setting.
ms.assetid: c1b7e084-a9f7-4377-b678-07cc913c8b0c
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Act as part of the operating system
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Act as part of the operating system** security policy setting.
## Reference
The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs.
Constant: SeTcbPrivilege
### Possible values
- User-defined list of accounts
- Not defined
### Best practices
- Do not assign this right to any user accounts. Only assign this user right to trusted users.
- If a service requires this user right, configure the service to log on by using the local System account, which inherently includes this user right. Do not create a separate account and assign this user right to it.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client computer effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default domain policy | Not defined |
| Default domain controller policy| Not defined |
| Stand-alone server default settings | Not defined |
| Domain controller effective default settings | Not defined |
| Member server effective default settings | Not defined |
| Client computer effective default settings | Not defined |
 
## Policy management
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
The **Act as part of the operating system** user right is extremely powerful. Users with this user right can take complete control of the device and erase evidence of their activities.
### Countermeasure
Restrict the **Act as part of the operating system** user right to as few accounts as possible—it should not even be assigned to the Administrators group under typical circumstances. When a service requires this user right, configure the service to log on with the Local System account, which inherently includes this privilege. Do not create a separate account and assign this user right to it.
### Potential impact
There should be little or no impact because the **Act as part of the operating system** user right is rarely needed by any accounts other than the Local System account.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 

11
windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
View File

@ -2,21 +2,26 @@
title: Create a Device Guard code integrity policy based on a reference device (Windows 10)
description: To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device.
ms.assetid: 6C94B14E-E2CE-4F6C-8939-4B375406E825
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Create a Device Guard code integrity policy based on a reference device
**Applies to**
- Windows 10
To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device.
## <a href="" id="create-a-device-guard-code-integrity-policy-based-on--a-reference-device"></a>Create a Device Guard code integrity policy based on a reference device
To create a code integrity policy, you'll first need to create a reference image that includes the signed applications you want to run on your protected devices. For information on how to sign applications, see [Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md).
**Note**  Before creating a code integrity policy, make sure your reference device is clean of viruses and malware.
> **Note:**  Before creating a code integrity policy, make sure your reference device is clean of viruses and malware.
 
**To create a code integrity policy based on a reference device**
1. On your reference device, start PowerShell as an administrator.
2. In PowerShell, initialize variables by typing:
``` syntax
@ -99,7 +104,7 @@ To create a code integrity policy, you'll first need to create a reference image
ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
```
Once you have completed these steps, the Device Guard policy binary file (DeviceGuardPolicy.bin) and original xml file (InitialScan.xml) will be available on your desktop.
**Note**  We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options.
>**Note:**  We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options.
 
## Related topics
[Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md)

128
windows/keep-secure/credential-guard.md
View File

@ -2,32 +2,46 @@
title: Protect derived domain credentials with Credential Guard (Windows 10)
description: Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them.
ms.assetid: 4F1FE390-A166-4A24-8530-EA3369FEB4B1
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: explore
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Protect derived domain credentials with Credential Guard
**Applies to**
- Windows 10
- Windows Server 2016 Technical Preview
Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets.
Credential Guard offers the following features and solutions:
- **Hardware security** Credential Guard increases the security of derived domain credentials by taking advantage of platform security features including, Secure Boot and virtualization.
- **Virtualization-based security** Windows services that manage derived domain credentials and other secrets run in a protected environment that is isolated from the running operating system.
- **Better protection against advanced persistent threats** Securing derived domain credentials using the virtualization-based security blocks the credential theft attack techniques and tools used in many targeted attacks. Malware running in the operating system with administrative privileges cannot extract secrets that are protected by virtualization-based security. While Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques and you should also incorporate Device Guard and other security strategies and architectures.
- **Manageability** You can manage Credential Guard by using Group Policy, WMI, from a command prompt, and Windows PowerShell.
## How it works
Credential Guard isolates secrets that previous versions of Windows stored in the Local Security Authority (LSA) by using virtualization-based security. Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Credential Guard, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process
Credential Guard isolates secrets that previous versions of Windows stored in the Local Security Authority (LSA) by using virtualization-based security. Prior to Windows 10, the LSA stored secrets used by the operating system in its process memory. With Credential Guard, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process.
For security reasons, the isolated LSA process doesn't host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.
Credential Guard also does not allow older variants of NTLM, unconstrained Kerberos delegation, and Kerberos authentication protocols and cipher suites when using default derived credentials, including NTLMv1, MS-CHAPv2, and weaker Kerberos encryption types, such as DES.
Here's a high-level overview on how the LSA is isolated by using virtualization-based security:
![Credential Guard oveview](images/credguard.png)
![Credential Guard overview](images/credguard.png)
## New and changed functionality
To see what was added or changed in Credential Guard, see [What's new in Credential Guard?](../whats-new/credential-guard.md).
## Hardware and software requirements
The PC must meet the following hardware and software requirements to use Credential Guard:
<table>
<colgroup>
<col width="50%" />
@ -100,21 +114,31 @@ The PC must meet the following hardware and software requirements to use Credent
</table>
 
¹ If you choose the **Secure Boot and DMA protection** option in the Group Policy setting, an IOMMU is required. The **Secure Boot** Group Policy option enables Credential Guard on devices without an IOMMU.
## Manage Credential Guard
Credential Guard uses virtualization-based security features that must be enabled on each PC before you can use it.
### Turn on Credential Guard by using Group Policy
You can use Group Policy to enable Credential Guard because it will add the virtualization-based security features for you.
1. From the Group Policy Management Console, go to **Computer Configuration** -&gt; **Administrative Templates** -&gt; **System** -&gt; **Device Guard**.
2. Double-click **Turn On Virtualization Based Security**, and then click the **Enabled** option.
3. **Select Platform Security Level** box, choose **Secure Boot** or **Secure Boot and DMA Protection**.
4. In the **Credential Guard Configuration** box, click **Enabled with UEFI lock**, and then click **OK**. If you want to be able to turn off Credential Guard remotely, choose **Enabled without lock**.
![](images/credguard-gp.png)
![Credential Guard Group Policy setting](images/credguard-gp.png)
5. Close the Group Policy Management Console.
### Add Credential Guard to an image
If you would like to add Credential Guard to an image, you can do this by adding the virtualization-based security features and then turning on Credential Guard.
### Add the virtualization-based security features
First, you must add the virtualization-based security features. You can do this by using either the Control Panel or the Deployment Image Servicing and Management tool (DISM).
**Note**  If you enable Credential Guard by using Group Policy, these steps are not required. Group Policy will install the features for you.
> **Note:**  If you enable Credential Guard by using Group Policy, these steps are not required. Group Policy will install the features for you.
 
**Add the virtualization-based security features by using Programs and Features**
1. Open the Programs and Features control panel.
@ -122,6 +146,7 @@ First, you must add the virtualization-based security features. You can do this
3. Select the **Isolated User Mode** check box.
4. Go to **Hyper-V** -&gt; **Hyper-V Platform**, and then select the **Hyper-V Hypervisor** check box.
5. Click **OK**.
**Add the virtualization-based security features to an offline image by using DISM**
1. Open an elevated command prompt.
2. Add the Hyper-V Hypervisor by running the following command:
@ -132,12 +157,14 @@ First, you must add the virtualization-based security features. You can do this
``` syntax
dism /image:<WIM file name> /Enable-Feature /FeatureName:IsolatedUserMode
```
**Note**  
You can also add these features to an online image by using either DISM or Configuration Manager.
> **Note:**  You can also add these features to an online image by using either DISM or Configuration Manager.
 
### Turn on Credential Guard
If you don't use Group Policy, you can enable Credential Guard by using the registry.
**Turn on Credential Guard by using the registry**
1. Open Registry Editor.
2. Enable virtualization-based security:
- Go to HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Control\\DeviceGuard.
@ -147,15 +174,19 @@ If you don't use Group Policy, you can enable Credential Guard by using the regi
- Go to HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Control\\LSA.
- Add a new DWORD value named **LsaCfgFlags**. Set the value of this registry setting to 1 to enable Credential Guard with UEFI lock, set it to 2 to enable Credential Guard without lock, and set it to 0 to disable it.
4. Close Registry Editor.
**Note**  
You can also turn on Credential Guard by setting the registry entries in the [FirstLogonCommands](http://msdn.microsoft.com/library/windows/hardware/dn922797.aspx) unattend setting.
> **Note:**  You can also turn on Credential Guard by setting the registry entries in the [FirstLogonCommands](http://msdn.microsoft.com/library/windows/hardware/dn922797.aspx) unattend setting.
 
### Remove Credential Guard
If you have to remove Credential Guard on a PC, you need to do the following:
1. If you used Group Policy, disable the Group Policy setting that you used to enable Credential Guard (**Computer Configuration** -&gt; **Administrative Templates** -&gt; **System** -&gt; **Device Guard** -&gt; **Turn on Virtualization Based Security**).
2. Delete the following registry setting: HKEY\_LOCAL\_MACHINE\\Software\\Policies\\Microsoft\\Windows\\DeviceGuard\\LsaCfgFlags
3. Delete the Credential Guard EFI variables by using bcdedit.
**Delete the Credential Guard EFI variables**
1. From an elevated command prompt, type the following commands:
``` syntax
mountvol X: /s
@ -170,20 +201,25 @@ If you have to remove Credential Guard on a PC, you need to do the following:
2. Restart the PC.
3. Accept the prompt to disable Credential Guard.
4. Alternatively, you can disable the virtualization-based security features to turn off Credential Guard.
**Note**  
The PC must have one-time access to a domain controller to decrypt content, such as files that were encrypted with EFS.
If you want to turn off both Credential Guard and virtualization-based security, run the following bcdedit command after turning off all virtualization-based security Group Policy and registry settings:
**bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS**
> **Note: ** The PC must have one-time access to a domain controller to decrypt content, such as files that were encrypted with EFS. If you want to turn off both Credential Guard and virtualization-based security, run the following bcdedit command after turning off all virtualization-based security Group Policy and registry settings: **bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS**
For more info on virtualization-based security and Device Guard, see [Device Guard deployment guide](device-guard-deployment-guide.md).
 
### Check that Credential Guard is running
You can use System Information to ensure that Credential Guard is running on a PC.
1. Click **Start**, type **msinfo32.exe**, and then click **System Information**.
2. Click **System Summary**.
3. Confirm that **Credential Guard** is shown next to **Device Guard Security Services Running**.
Here's an example:
![](images/credguard-msinfo32.png)
![System Information](images/credguard-msinfo32.png)
## Considerations when using Credential Guard
- If Credential Guard is enabled on a device after it's joined to a domain, the user and device secrets may already be compromised. We recommend that Credential Guard is enabled before the PC is joined to a domain.
- You should perform regular reviews of the PCs that have Credential Guard enabled. This can be done with security audit policies or WMI queries. Here's a list of WinInit event IDs to look for:
- **Event ID 13** Credential Guard (LsaIso.exe) was started and will protect LSA credentials.
@ -203,34 +239,51 @@ You can use System Information to ensure that Credential Guard is running on a P
- Credentials saved by Remote Desktop Services cannot be used to remotely connect to another machine without supplying the password.
- Applications that extract derived domain credentials from Credential Manager will no longer be able to use those credentials.
- You cannot restore credentials using the Credential Manager control panel if the credentials were backed up from a PC that has Credential Guard turned on. If you need to back up your credentials, you must do this before you enable Credential Guard. Otherwise, you won't be able to restore those credentials.
## Scenarios not protected by Credential Guard
Some ways to store credentials are not protected by Credential Guard, including:
- Software that manages credentials outside of Windows feature protection
- Local accounts and Microsoft Accounts
- Credential Guard does not protect the Active Directory database running on Windows Server 2016 Technical Preview domain controllers. It also does not protect credential input pipelines, such as Windows Server 2016 Technical Preview servers running Remote Desktop Gateway. If you're using a Windows Server 2016 Technical Preview server as a client PC, it will get the same protection as it would be running Windows 10 Enterprise.
- Key loggers
- Physical attacks
- Does not prevent an attacker with malware on the PC from using the privileges associated with any credential. We recommend using dedicated PCs for high value accounts, such as IT Pros and users with access high value assets in your organization.
## Additional mitigations
Credential Guard can provide mitigations against attacks on derived credentials and prevent the use of stolen credentials elsewhere. However, PCs can still be vulnerable to certain attacks, even if the derived credentials are protected by Credential Guard. These attacks can include abusing privileges and use of derived credentials directly from a compromised device, reusing previously stolen credentials prior to Device Guard, and abuse of management tools and weak application configurations. Because of this, additional mitigations also need to be deployed to make the domain environment more robust.
Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. By deploying authentication policies with compound authentication in Windows Server 2012 R2 or later domains, users can be restricted to only sign on from specific domain-joined devices. However, since devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Credential Guard, authentication policies can require that the device authenticates with its private key. This prevents shared secrets on stolen devices to be used with stolen user passwords or Kerberos secret keys to sign on as the user.
Device certificate authentication has the following requirements:
- Device domains are Windows Server 2012 or higher and all domain controllers have certificates, which satisfy strict KDC validation (KDC EKU present and the DNS domain name matches the DNSName field of the SubjectAltName (SAN) extension).
- Windows 10 devices have the CA issuing the domain controller certificates in the enterprise store.
- A process is established to ensure the identity and trustworthiness of the device in a similar manner as you would establish the identity and trustworthiness of a user before issuing them a smartcard.
### Additional Group Policy settings
There are a few Group Policy settings that you can enable that provide more protection against credential attacks:
- On the domain controllers, configure the KDC support for claims, compound authentication, and Kerberos armoring system by using Group Policy. Set the **KDC support for claims, compound authentication, and Kerberos armoring** Group Policy setting to either **Supported** or **Always provide claims**.
- On devices running Windows 10, you can turn it on by using Group Policy as well. To do this, enable the **Kerberos client support for claims, compound authentication and Kerberos armoring** & **Always send compound authentication first system** Group Policy settings under **Computer Configuration** -&gt; **Administrative Templates** -&gt; **System** -&gt; **Kerberos**.
### Compound authentication
Compound authentication adds the device identity to the user’s during authentication to the domain and resources. Without compound authentication, only the user’s secrets are validated. With compound authentication, the Kerberos client has to have both the user’s and device’s secrets.
Enabling compound authentication also enables Kerberos armoring, which provides two additional benefits:
- User authentication on domain-joined devices will be armored. This means that network captures will contain encrypted Kerberos initial authentication. Without the appropriate device key, Kerberos AS-REQs are protected against offline dictionary attacks.
- KDC errors are signed, which provides protection against error spoofing attacks.
### Deploying machine certificates
If the domain controllers in your organization are running Windows Server 2016 Technical Preview, devices running Windows 10 will automatically enroll a machine certificate when Credential Guard is enabled and the PC is joined to the domain.
If the domain controllers are running Windows Server 2012 R2, the machine certificates must be provisioned manually on each device. You can do this by creating a certificate template on the domain controller or certificate authority and deploying the machine certificates to each device.
The same security procedures used for issuing smart cards to users should be applied to machine certificates.
1. From the Certificate Manager console, right-click **Certificate Templates**, and then click **Manage.**
2. Right-click **Workstation Authentication**, and then click **Duplicate Template**.
3. Right-click the new template, and then click **Properties**.
@ -242,14 +295,15 @@ The same security procedures used for issuing smart cards to users should be app
7. On the **Extensions** tab, click **Issuance Policies**, and then click **Edit**.
8. Under **Issuance Policies**, click**High Assurance**.
9. On the **Subject name** tab, clear the **DNS name** check box, and then select the **User Principal Name (UPN)** check box.
On devices that are running Credential Guard, enroll the devices using the machine authentication certificate by running the following command:
``` syntax
CertReq -EnrollCredGuardCert MachineAuthentication
```
**Note**  
You must restart the device after enrolling the machine authentication certificate.
> **Note:**  You must restart the device after enrolling the machine authentication certificate.
 
### Link the issuance policies to a group
By using an authentication policy, you can ensure that users only sign into devices that are running Credential Guard. Before you deploy the authentication policy though, you must first run a couple of scripts that set up your environment.
- The [get-IssuancePolicy.ps1](#bkmk-getscript) shows all of the issuance policies that are available on the certificate authority.
From a Windows PowerShell command prompt, run the following command:
@ -262,9 +316,13 @@ By using an authentication policy, you can ensure that users only sign into devi
.\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName:”<name of issuance policy>” –groupOU:”<Name of OU to create>” –groupName:”<name of Universal security group to create>”
```
### Deploy the authentication policy
Before setting up the authentication policy, you should log any failed attempt to apply an authentication policy on the KDC. To do this in Event Viewer, navigate to **Applications and Services Logs\\Microsoft\\Windows\\Authentication, right-click AuthenticationPolicyFailures-DomainController**, and then click **Enable Log**.
Now you can set up an authentication policy to use Credential Guard.
**To add an authentication policy for Credential Guard**
1. Ensure that your domain controllers are running at least the Windows Server 2012 R2 domain functional level.
2. Create a security group that will be used to identify the PCs that will have this authentication policy applied to them.
3. Add the computer account to this security group.
@ -280,13 +338,17 @@ Now you can set up an authentication policy to use Credential Guard.
13. Click **OK** to close the **Edit Access Control Conditions** box.
14. Click **OK** to create the authentication policy.
15. Close Active Directory Administrative Center.
**Note**  
When authentication policies in enforcement mode are deployed with Credential Guard, users will not be able to sign in using devices that do not have the machine authentication certificate provisioned. This applies to both local and remote sign in scenarios.
> **Note:**  When authentication policies in enforcement mode are deployed with Credential Guard, users will not be able to sign in using devices that do not have the machine authentication certificate provisioned. This applies to both local and remote sign in scenarios.
 
### Appendix: Scripts
Here is a list of scripts that are mentioned in this topic.
### <a href="" id="bkmk-getscript"></a>Get the available issuance policies on the certificate authority
#### <a href="" id="bkmk-getscript"></a>Get the available issuance policies on the certificate authority
Save this script file as get-IssuancePolicy.ps1.
``` syntax
#######################################
## Parameters to be defined ##
@ -471,11 +533,12 @@ write-host "There are no issuance policies which are not mapped to groups"
}
}
```
**Note**  
If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
> **Note:**  If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
 
### <a href="" id="bkmk-setscript"></a>Link an issuance policy to a group
#### <a href="" id="bkmk-setscript"></a>Link an issuance policy to a group
Save the script file as set-IssuancePolicyToGroupLink.ps1.
``` syntax
#######################################
## Parameters to be defined ##
@ -750,17 +813,18 @@ write-host $tmp -Foreground Red
}
}
```
**Note**  
If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
> **Note:**  If you're having trouble running this script, try replacing the single quote after the ConvertFrom-StringData parameter.
 
## Related topics
[Isolated User Mode in Windows 10 with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert)
[Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel (Channel 9)](http://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel)
[More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/More-on-Processes-and-Features-in-Windows-10-Isolated-User-Mode-with-Dave-Probert)
[Mitigating Credential Theft using the Windows 10 Isolated User Mode (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Mitigating-Credential-Theft-using-the-Windows-10-Isolated-User-Mode)
[Enabling Strict KDC Validation in Windows Kerberos](http://www.microsoft.com/download/details.aspx?id=6382)
[What's New in Kerberos Authentication for Windows Server 2012](http://technet.microsoft.com/library/hh831747.aspx)
[Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide](http://technet.microsoft.com/library/dd378897.aspx)
[Trusted Platform Module](trusted-platform-module-overview.md)
- [Isolated User Mode in Windows 10 with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert)
- [Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel (Channel 9)](http://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel)
- [More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/More-on-Processes-and-Features-in-Windows-10-Isolated-User-Mode-with-Dave-Probert)
- [Mitigating Credential Theft using the Windows 10 Isolated User Mode (Channel 9)](https://channel9.msdn.com/Blogs/Seth-Juarez/Mitigating-Credential-Theft-using-the-Windows-10-Isolated-User-Mode)
- [Enabling Strict KDC Validation in Windows Kerberos](http://www.microsoft.com/download/details.aspx?id=6382)
- [What's New in Kerberos Authentication for Windows Server 2012](http://technet.microsoft.com/library/hh831747.aspx)
- [Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide](http://technet.microsoft.com/library/dd378897.aspx)
- [Trusted Platform Module](trusted-platform-module-overview.md)
 
 

86
windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
View File

@ -2,53 +2,69 @@
title: Update and manage Windows Defender in Windows 10 (Windows 10)
description: IT professionals can manage Windows Defender on Windows 10 endpoints in their organization using Microsoft Active Directory or Windows Server Update Services (WSUS), apply updates to endpoints, and manage scans using Group Policy SettingsWindows Management Instrumentation (WMI)PowerShell.
ms.assetid: 045F5BF2-87D7-4522-97E1-C1D508E063A7
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
ms.pagetype: security
author: jasesso
---
# Update and manage Windows Defender in Windows 10
**Applies to**
- Windows 10
IT professionals can manage Windows Defender on Windows 10 endpoints in their organization using Microsoft Active Directory or Windows Server Update Services (WSUS), apply updates to endpoints, and manage scans using:
- Group Policy Settings
- Windows Management Instrumentation (WMI)
- PowerShell
## Manage Windows Defender endpoints through Active Directory and WSUS
All Windows 10 endpoints are installed with Windows Defender and include support for management through:
- Active Directory
- WSUS
You can use the Active Directory to configure the settings; Group policies can be used for centralized configuration and enforcement of many Windows Defender settings including client user interface, scan settings, and exclusions.
WSUS can be used to view basic update compliance and deploy updates manually or through automatic rules.
Note that System Center 2012 R2 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, and Microsoft Intune can provide centralized management of Windows Defender, including:
- Settings management
- Definition update management
- Alerts and alert management
- Reports and reporting
When you enable *Endpoint Protection* on your clients, it will install an additional management layer on Windows Defender to manage the in-box Windows Defender agent. While the client user interface will still appear as Windows Defender, the management layer for System Center Endpoint Protection or Intune will be listed in the **Add/Remove Programs** control panel, though it will appear as if the full product is installed. Learn more about managing *Endpoint Protection*:
- [Help secure Windows PCs with Endpoint Protection for Microsoft Intune](https://technet.microsoft.com/library/dn646970.aspx)
- [Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/hh508760.aspx)
Read more about System Center Configuration Manager in [Introduction to Endpoint Protection in Configuration Manager](https://technet.microsoft.com/library/hh508781.aspx).
**Important**  You must be licensed to use *Endpoint Protection* to manage clients in your Configuration Manager hierarchy.
> **Important:**  You must be licensed to use *Endpoint Protection* to manage clients in your Configuration Manager hierarchy.
 
## Apply updates to Windows Defender endpoints
It is important to keep Windows Defender endpoints updated to ensure they are protected. All Windows Defender updates, including General Distribution Release (GDR) updates, are now applied as operating system updates.
You can manage the distribution of updates through the [Windows Server Update Services (WSUS)](https://technet.microsoft.com/windowsserver/bb332157).
## Manage email scans in Windows Defender
You can use Windows Defender to scan email files. Malware can install itself and hide in email files, and although real-time protection offers you the best protection from email malware, you can also scan emails stored on your PC or server with Windows Defender.
**Important**  Mail scanning only applies to on-demand and scheduled scans, not on-access scans.
> **Important:**  Mail scanning only applies to on-demand and scheduled scans, not on-access scans.
 
Windows Defender scans Microsoft Office Outlook 2003 and older email files. We identify the file type at run-time based on the content of the file, not on location or extension.
**Note**  Scanning email files might increase the time required to complete a scan.
> **Note: **  Scanning email files might increase the time required to complete a scan.
 
Windows Defender can extract embedded objects within a file (attachments and archived files, for example) and scan internally.
**Note**  While Windows Defender can be configured to scan email files, it can only remediate threats detected inside certain files, for example:
> **Note:**  While Windows Defender can be configured to scan email files, it can only remediate threats detected inside certain files, for example:
- DBX
- MBX
- MIME
 
You can configure Windows Defender to scan PST files used by Outlook 2003 or older versions (where the archive type is set to non-uni-code), but Windows Defender cannot remediate threats detected inside PST files. We recommend using real-time protection to protect against email malware.
If Windows Defender detects a threat inside an email, it will show you the following information to assist you in identifying the compromised email, so you can remediate the threat:
- Email subject
- Attachment name
@ -56,77 +72,117 @@ Email scanning in Windows Defender is turned off by default. There are three way
- *Group Policy* settings
- WMI
- PowerShell
**Important**  There are some risks associated with scanning some Microsoft Outlook files and email messages. You can read about tips and risks associated with scanning Outlook files and email messages in the following articles:
> **Important:**  There are some risks associated with scanning some Microsoft Outlook files and email messages. You can read about tips and risks associated with scanning Outlook files and email messages in the following articles:
- [Scanning Outlook files in Outlook 2013](https://technet.microsoft.com/library/dn769141.aspx#bkmk-1)
- [Scanning email messages in Outlook 2013](https://technet.microsoft.com/library/dn769141.aspx#bkmk-2)
 
## Use *Group Policy* settings to enable email scans
This policy setting allows you to turn on email scanning. When email scanning is enabled, the engine will parse the mailbox and mail files to analyze the mail bodies and attachments.
Turn on email scanning with the following *Group Policy* settings:
1. Open the **Group Policy Editor**.
2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**.
3. Click **Scan**.
4. Double-click **Turn on e-mail scanning**.
This will open the **Turn on e-mail scanning** window: ![turn on e-mail scanning window](images/defender-scanemailfiles.png)
This will open the **Turn on e-mail scanning** window:
![turn on e-mail scanning window](images/defender-scanemailfiles.png)
5. Select **Enabled**.
6. Click **OK** to apply changes.
## Use WMI to disable email scans
You can write a WMI script or application to disable email scanning. Read more about [WMI in this article](https://msdn.microsoft.com/library/windows/desktop/dn439477.aspx), and read about [Windows Preference classes in this article](https://msdn.microsoft.com/library/windows/desktop/dn455323.aspx).
Use the **DisableEmailScanning** property of the **MSFT\_MpPreference** class (part of the Windows DefenderWMI provider) to enable or disable this setting:
**DisableEmailScanning**
Data type: **boolean**
Access type: Read-only
Disable email scanning.
## Use PowerShell to enable email scans
You can also enable email scanning using the following PowerShell parameter:
1. Open PowerShell or PowerShellIntegrated Scripting Environment (ISE).
2. Type **Set-MpPreference -DisableEmailScanning $false**.
Read more about this in:
- • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
- • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
## Manage archive scans in Windows Defender
You can use Windows Defender to scan archive files. Malware can install itself and hide in archive files, and although real-time protection offers you the best protection from malware, you can also scan archives stored on your PC or server with Windows Defender.
**Important**  Archive scanning only applies to on-demand and scheduled scans, not on-access scans.
> **Important:**  Archive scanning only applies to on-demand and scheduled scans, not on-access scans.
 
Archive scanning in Windows Defender is turned on by default. There are four ways you can manage scans through Windows Defender:
- *Group Policy* settings
- WMI
- PowerShell
- Endpoint Protection
**Note**  Scanning archive files might increase the time required to complete a scan.
> **Note:**  Scanning archive files might increase the time required to complete a scan.
 
If you exclude an archive file type by using the **Extensions** box, Windows Defender will not scan files with that extension (no matter what the content is), even when you have selected the **Scan archive files** check box. For example, if you exclude .rar files but there’s a .r00 file that’s actually .rar content, it will still be scanned if archive scanning is enabled.
## Use *Group Policy* settings to enable archive scans
This policy setting allows you to turn on archive scanning.
Turn on email scanning with the following *Group Policy* settings:
1. Open the **Group Policy Editor**.
2. In the **Local Computer Policy** tree, expand **Computer Configuration**, then **Administrative Templates**, then **Windows Components**, then **Windows Defender**.
3. Click **Scan**.
4. Double-click **Scan archive files**.
This will open the **Scan archive files** window: ![scan archive files window](images/defender-scanarchivefiles.png)
This will open the **Scan archive files** window:
![scan archive files window](images/defender-scanarchivefiles.png)
5. Select **Enabled**.
6. Click **OK** to apply changes.
There are a number of archive scan settings in the **Scan** repository you can configure through *Group Policy*, for example:
- Maximum directory depth level into which archive files are unpacked during scanning ![specify the maximum depth to scan archive files window](images/defender-scanarchivedepth.png)
- Maximum size of archive files that will be scanned ![specify the maximum size of archive files to be scanned window](images/defender-scanarchivesize.png)
- Maximum percentage CPU utilization permitted during a scan ![specify the maximum percentage od cpu utilization during a scan window](images/defender-scanarchivecpu.png)
- Maximum directory depth level into which archive files are unpacked during scanning
![specify the maximum depth to scan archive files window](images/defender-scanarchivedepth.png)
- Maximum size of archive files that will be scanned
![specify the maximum size of archive files to be scanned window](images/defender-scanarchivesize.png)
- Maximum percentage CPU utilization permitted during a scan
![specify the maximum percentage od cpu utilization during a scan window](images/defender-scanarchivecpu.png)
## Use WMI to disable archive scans
You can write a WMI script or application to disable archive scanning. Read more about [WMI in this article](https://msdn.microsoft.com/library/windows/desktop/dn439477.aspx), and read about [Windows Preference classes in this article](https://msdn.microsoft.com/library/windows/desktop/dn455323.aspx).
Use the **DisableArchiveScanning** property of the **MSFT\_MpPreference** class (part of the Windows DefenderWMI provider) to enable or disable this setting:
**DisableArchiveScanning**
Data type: **boolean**
Access type: Read-only
Disable archive scanning.
## Use PowerShell to enable archive scans
You can also enable archive scanning using the following PowerShell parameter:
1. Open PowerShell or PowerShellISE.
2. Type **Set-MpPreference -DisableArchiveScanning $false**.
Read more about this in:
- • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
- • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
- [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
- [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
## Use Endpoint Protection to configure archive scans
In Endpoint Protection, you can use the advanced scanning options to configure archive scanning. For more information, see [What are advanced scanning options?](https://technet.microsoft.com/library/ff823807.aspx)
## Related topics
[Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md)
[Troubleshoot Windows Defender in Windows 10](troubleshoot-windows-defender-in-windows-10.md)
 

43
windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
View File

@ -2,28 +2,37 @@
title: Get apps to run on Device Guard-protected devices (Windows 10)
description: Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard.
ms.assetid: E62B68C3-8B9F-4842-90FC-B4EE9FF8A67E
ms.pagetype: security
keywords: ["Package Inspector", "packageinspector.exe", "sign catalog file"]
keywords: Package Inspector, packageinspector.exe, sign catalog file
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Get apps to run on Device Guard-protected devices
**Applies to**
- Windows 10
Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard. Device Guard can help to protect your enterprise devices against the accidental running of malicious apps by requiring all of your apps to be signed by a trusted entity.
To use Device Guard in an enterprise, you must be able to get your existing line-of-business and Independent Software Vendor (ISV)-developed apps to run on a protected device. Unfortunately, many line-of-business apps aren't signed, and in many cases, aren't even being actively developed. Similarly, you may have unsigned software from an ISV that you want to run, or you want to run certain applications from an ISV while not trusting all applications from that ISV. As part of the Device Guard features, Windows 10 includes a new tool called Package Inspector. Package Inspector scans your unsigned apps, and creates catalog files of the installed and running binaries, which can then be signed by the Sign Tool Windows SDK utility and distributed using Group Policy so that your apps will run on Device Guard-protected devices.
## What you need to run your apps on Device-Guard protected devices
Before you can get your apps to run on Device Guard-protected devices, you must have:
- A device running Windows 10 Enterprise, Windows 10 Education, or Windows Server 2016 Technical Preview.
- Determined which unsigned apps you need to include in your catalog file.
- Created a code integrity policy for use by Device Guard.
- A [code signing certificate](http://go.microsoft.com/fwlink/p/?LinkId=619282), created using an internal public key infrastructure (PKI).
- [SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283). A command-line tool that digitally signs files, verifies signatures in files, or time stamps files. The tool is installed in the \\Bin folder of the Microsoft Windows Software Development Kit (SDK) installation path.
## Create a catalog file for unsigned apps
You must run Package Inspector on a device that's running a temporary Code Integrity Policy in audit mode, created explicitly for this purpose. Audit mode lets this policy catch any binaries missed by the inspection tool, but because it's audit mode, allows everything to continue running.
**Important**  This temporary policy, shouldn't be used for normal business purposes.
> **Important:**  This temporary policy, shouldn't be used for normal business purposes.
 
**To create a catalog file for an existing app**
1. Start PowerShell as an administrator, and create your temporary policy file by typing:
@ -63,12 +72,13 @@ You must run Package Inspector on a device that's running a temporary Code Integ
</table>
 
4. Copy the app installation media to your C:\\ drive, and then install and run the program.
Copying the media to your local drive helps to make sure that the installer and its related files are included in your catalog file. If you miss the install files, your Code Integrity Policy might trust the app to run, but not to install. After you've installed the app, you should check for updates. If updates happen while the app is open, you should close and restart the app to make sure everything is caught during the inspection process.
**Note**  
Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process.
> **Note:**  Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process.
 
5. **Optional:** If you want to create a multi-app catalog (many apps included in a single catalog file), you can continue to run Steps 2-3 for each additional app. After you've added all of the apps you want to add, you can continue to Step 5.
**Note**  To streamline your process, we suggest:
> **Note: **  To streamline your process, we suggest:
- **Actively supported and updated apps.** Create a single catalog file for each app.
- **Legacy apps, non-active or not updated.** Create a single catalog file for all of your legacy apps.
 
@ -142,12 +152,16 @@ The following table shows the available options for both the `scan` and `stop` c
</table>
 
You can add additional parameters to your catalog beyond what's listed here. For more info, see the [MakeCat](http://go.microsoft.com/fwlink/p/?LinkId=618024) topic.
## Sign your catalog file using Sign Tool
You can sign your catalog file using Sign Tool, located in the Windows 7 or later Windows Software Development Kit (SDK) or by using the Device Guard signing portal. For details on using the Device Guard signing portal, see [Device Guard signing](http://go.microsoft.com/fwlink/p/?LinkID=698760).
This process shows how to use a password-protected Personal Information Exchange (.pfx) file to sign the catalog file.
**Important**  To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority.
> **Important:**  To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority.
 
**To use Sign Tool**
1. Check that your code signing certificates have been imported into your certificate store or that they're on the file system.
2. Open SignTool.exe and sign the catalog file, based on where your certificate is stored.
If you are using the PFX from a file system location:
@ -204,13 +218,18 @@ This process shows how to use a password-protected Personal Information Exchange
</table>
 
For more detailed info and examples using the available options, see the [SignTool.exe (Sign Tool)](http://go.microsoft.com/fwlink/p/?LinkId=618026) topic.
3. In File Explorer, right-click your catalog file, click **Properties**, and then click the **Digital Signatures** tab to make sure your catalog file's digital signature is accurate.
4. Copy your catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} and test the file.
**Note**  For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations.
 
>**Note:**  For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations.
## Troubleshooting the Package Inspector
If you see "Error 1181" while stopping the Package Inspector, you'll need to increase your USN journal size and then clear all of the cached data before re-scanning the impacted apps.
You must make sure that you clear the cache by creating and setting a new temporary policy. If you reuse the same policy, the Package Inspector will fail.
**To increase your journal size**
1. Open a command-prompt window, and then type:
``` syntax
@ -218,7 +237,9 @@ You must make sure that you clear the cache by creating and setting a new tempor
```
Where the "m" value needs to be increased. We recommend that you change the value to at least 4 times the default value of m=0x2000000.
2. Re-run the failed app installation(s).
**To clear your cached data and re-scan your apps**
1. Delete the SIPolicy.p7b file from the C:\\Windows\\System32\\CodeIntegrity\\ folder.
2. Create a new temporary Code Integrity Policy to clear all of the cached data by starting Windows Powershell as an administrator and typing:
``` syntax
@ -229,7 +250,7 @@ You must make sure that you clear the cache by creating and setting a new tempor
cp .\DenyPackageInspector.bin C:\Windows\System32\SIPolicy.p7b
```
3. Restart your device and follow the steps in the [Create a catalog file for unsigned apps](#create-a-catalog-file-for-unsigned-apps) section.
## Related topics
[Download SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283)
 
 

BIN
windows/keep-secure/images/atp.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 41 KiB

After

Width:  |  Height:  |  Size: 87 KiB

BIN
windows/keep-secure/images/machine-investigation.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 53 KiB

After

Width:  |  Height:  |  Size: 52 KiB

BIN
windows/keep-secure/images/portqry.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 67 KiB

After

Width:  |  Height:  |  Size: 66 KiB

BIN
windows/keep-secure/images/windefatp-utc-console-autostart.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 67 KiB

After

Width:  |  Height:  |  Size: 66 KiB

27
windows/keep-secure/implement-microsoft-passport-in-your-organization.md
View File

@ -2,22 +2,25 @@
title: Implement Microsoft Passport in your organization (Windows 10)
description: You can create a Group Policy or mobile device management (MDM) policy that will implement Microsoft Passport on devices running Windows 10.
ms.assetid: 47B55221-24BE-482D-BD31-C78B22AC06D8
ms.pagetype: security
keywords: ["identity", "PIN", "biometric", "Hello"]
keywords: identity, PIN, biometric, Hello
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: jdeckerMS
---
# Implement Microsoft Passport in your organization
**Applies to**
- Windows 10
- Windows 10 Mobile
You can create a Group Policy or mobile device management (MDM) policy that will implement Microsoft Passport on devices running Windows 10.
**Important**  
The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Microsoft Passport for Work** policy settings to manage PINs.
> **Important:** The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Microsoft Passport for Work** policy settings to manage PINs.
 
## Group Policy settings for Passport
The following table lists the Group Policy settings that you can configure for Passport use in your workplace. These policy settings are available in **Computer Configuration** &gt; **Policies** &gt; **Administrative Templates** &gt; **Windows Components** &gt; **Microsoft Passport for Work**.
<table>
<tr>
@ -132,7 +135,9 @@ The following table lists the Group Policy settings that you can configure for P
</td>
</tr>
</table>
## MDM policy settings for Passport
The following table lists the MDM policy settings that you can configure for Passport use in your workplace. These MDM policy settings use the [PassportForWork configuration service provider (CSP)](http://go.microsoft.com/fwlink/p/?LinkId=692070).
<table>
<tr>
@ -276,10 +281,12 @@ The following table lists the MDM policy settings that you can configure for Pas
</td>
</tr>
</table>
**Note**  
If policy is not configured to explicitly require letters or special characters, users will be restricted to creating a numeric PIN.
 
## Prerequisites
You’ll need this software to set Microsoft Passport policies in your enterprise.
<table>
<colgroup>
@ -339,16 +346,26 @@ You’ll need this software to set Microsoft Passport policies in your enterpris
Configuration Manager and MDM provide the ability to manage Passport policy and to deploy and manage certificates protected by Passport.
Azure AD provides the ability to register devices with your enterprise and to provision Passport for organization accounts.
Active Directory provides the ability to authorize users and devices using keys protected by Passport if domain controllers are running Windows 10 and the Microsoft Passport provisioning service in Windows 10 AD FS.
## Passport for BYOD
Passport can be managed on personal devices that your employees use for work purposes using MDM. On personal devices, users can create a personal Passport PIN for unlocking the device and a separate work PIN for access to work resources.
The work PIN is managed using the same Passport policies that you can use to manage Passport on organization owned devices. The personal PIN is managed separately using DeviceLock policy. DeviceLock policy can be used to control length, complexity, history, and expiration requirements and can be configured using the [Policy configuration service provider](http://go.microsoft.com/fwlink/p/?LinkID=623244).
## Related topics
[Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
 
 

87
windows/keep-secure/index.md
View File

@ -2,83 +2,36 @@
title: Keep Windows 10 secure (Windows 10)
description: Learn about keeping Windows 10 and Windows 10 Mobile secure.
ms.assetid: EA559BA8-734F-41DB-A74A-D8DBF36BE920
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Keep Windows 10 secure
Learn about keeping Windows 10 and Windows 10 Mobile secure.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md)</p></td>
<td align="left"><p>This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md).</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md)</p></td>
<td align="left"><p>To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Device Guard certification and compliance](device-guard-certification-and-compliance.md)</p></td>
<td align="left"><p>Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)</p></td>
<td align="left"><p>In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md)</p></td>
<td align="left"><p>Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md)</p></td>
<td align="left"><p>In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md)</p></td>
<td align="left"><p>Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Protect derived domain credentials with Credential Guard](credential-guard.md)</p></td>
<td align="left"><p>Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md)</p></td>
<td align="left"><p>With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md)</p></td>
<td align="left"><p>Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[VPN profile options](vpn-profile-options.md)</p></td>
<td align="left"><p>Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Security technologies](security-technologies.md)</p></td>
<td align="left"><p>Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Enterprise security guides](windows-10-enterprise-security-guides.md)</p></td>
<td align="left"><p>Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md) | This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md). |
| [Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md) | To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process. |
| [Device Guard certification and compliance](device-guard-certification-and-compliance.md) | Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when. |
| [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) | In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. |
| [Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md) | Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition. |
| [Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md) | In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with. |
| [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md) | Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services. |
| [Protect derived domain credentials with Credential Guard](credential-guard.md) | Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets. |
| [Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md) | With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage. |
| [Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md) | Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. |
| [VPN profile options](vpn-profile-options.md) | Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. |
| [Security technologies](security-technologies.md) | Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile. |
| [Enterprise security guides](windows-10-enterprise-security-guides.md) | Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. |
 
## Related topics
[Windows 10 and Windows 10 Mobile](../index.md)
 
 

28
windows/keep-secure/installing-digital-certificates-on-windows-10-mobile.md
View File

@ -2,31 +2,41 @@
title: Install digital certificates on Windows 10 Mobile (Windows 10)
description: Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information.
ms.assetid: FF7B1BE9-41F4-44B0-A442-249B650CEE25
ms.pagetype: security
keywords: ["S/MIME", "PFX", "SCEP"]
keywords: S/MIME, PFX, SCEP
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: jdeckerMS
---
# Install digital certificates on Windows 10 Mobile
**Applies to**
- Windows 10 Mobile
Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services.
Certificates in Windows 10 Mobile are primarily used for the following purposes:
- To create a secure channel using Secure Sockets Layer (SSL) between a phone and a web server or service.
- To authenticate a user to a reverse proxy server that is used to enable Microsoft Exchange ActiveSync (EAS) for email.
- For installation and licensing of applications (from the Windows Phone Store or a custom company distribution site).
## Install certificates using Internet Explorer
A certificate can be posted on a website and made available to users through a device-accessible URL that they can use to download the certificate. When a user accesses the page and taps the certificate, it opens on the device. The user can inspect the certificate, and if they choose to continue, the certificate is installed on the Windows 10 Mobile device.
## Install certificates using email
The Windows 10 Mobile certificate installer supports .cer, .p7b, .pem, and .pfx files. To install certificates via email, make sure your mail filters do not block .cer files. Certificates that are sent via email appear as message attachments. When a certificate is received, a user can tap to review the contents and then tap to install the certificate. Typically, when an identity certificate is installed, the user is prompted for the password (or passphrase) that protects it.
## Install certificates using mobile device management (MDM)
Windows 10 Mobile supports root, CA, and client certificate to be configured via MDM. Using MDM, an administrator can directly add, delete, or query root and CA certificates, and configure the device to enroll a client certificate with a certificate enrollment server that supports Simple Certificate Enrollment Protocol (SCEP). SCEP enrolled client certificates are used by Wi-Fi, VPN, email, and browser for certificate-based client authentication. An MDM server can also query and delete SCEP enrolled client certificate (including user installed certificates), or trigger a new enrollment request before the current certificate is expired.
**Warning**  
Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certificate profile to support S/MIME on Windows 10 Mobile. For instructions on creating a PFX certificate profile in Microsoft Intune, see [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=718216).
> **Warning:**  Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certificate profile to support S/MIME on Windows 10 Mobile. For instructions on creating a PFX certificate profile in Microsoft Intune, see [Enable access to company resources using certificate profiles with Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=718216).
 
**Process of installing certificates using MDM**
1. The MDM server generates the initial cert enroll request including challenge password, SCEP server URL, and other enrollment related parameters.
2. The policy is converted to the OMA DM request and sent to the device.
3. The trusted CA certificate is installed directly during MDM request.
@ -34,17 +44,17 @@ Do not use SCEP for encryption certificates for S/MIME. You must use a PFX certi
5. The device generates private/public key pair.
6. The device connects to Internet facing point exposed by MDM server.
7. MDM server creates a certificate that is signed with proper CA certificate and returns it to device.
**Note**  
The device supports the pending function to allow server side to do additional verification before issuing the cert. In this case, a pending status is sent back to the device. The device will periodically contact the server, based on preconfigured retry count and retry period parameters. Retrying ends when either:
> **Note:**  The device supports the pending function to allow server side to do additional verification before issuing the cert. In this case, a pending status is sent back to the device. The device will periodically contact the server, based on preconfigured retry count and retry period parameters. Retrying ends when either:
A certificate is successfully received from the server
The server returns an error
The number of retries reaches the preconfigured limit
 
8. The cert is installed in the device. Browser, Wi-Fi, VPN, email, and other first party applications have access to this certificate.
**Note**  
If MDM requested private key being stored in Trusted Process Module (TPM) (configured during enrollment request), the private key will be saved in TPM. Note that SCEP enrolled cert protected by TPM isn’t guarded by a PIN. However, if the certificate is imported to the Passport for Work Key Storage Provider (KSP), it is guarded by the Passport PIN.
> **Note:**  If MDM requested private key being stored in Trusted Process Module (TPM) (configured during enrollment request), the private key will be saved in TPM. Note that SCEP enrolled cert protected by TPM isn’t guarded by a PIN. However, if the certificate is imported to the Passport for Work Key Storage Provider (KSP), it is guarded by the Passport PIN.
 
## Related topics
[Configure S/MIME](configure-s-mime.md)
 
 

40
windows/keep-secure/manage-identity-verification-using-microsoft-passport.md
View File

@ -2,41 +2,54 @@
title: Manage identity verification using Microsoft Passport (Windows 10)
description: In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN.
ms.assetid: 5BF09642-8CF5-4FBC-AC9A-5CA51E19387E
ms.pagetype: security
keywords: ["identity", "PIN", "biometric", "Hello"]
keywords: identity, PIN, biometric, Hello
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: jdeckerMS
---
# Manage identity verification using Microsoft Passport
**Applies to**
- Windows 10
- Windows 10 Mobile
In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN.
Passport addresses the following problems with passwords:
- Passwords can be difficult to remember, and users often reuse passwords on multiple sites.
- Server breaches can expose symmetric network credentials.
- Passwords can be subject to [replay attacks](http://go.microsoft.com/fwlink/p/?LinkId=615673).
- Users can inadvertently expose their passwords due to [phishing attacks](http://go.microsoft.com/fwlink/p/?LinkId=615674).
Passport lets users authenticate to:
- a Microsoft account.
- an Active Directory account.
- a Microsoft Azure Active Directory (AD) account.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](http://go.microsoft.com/fwlink/p/?LinkId=533889) authentication
After an initial two-step verification of the user during Passport enrollment, Passport is set up on the user's device and the user is asked to set a gesture, which can be Windows Hello or a PIN. The user provides the gesture to verify their identity. Windows then uses Passport to authenticate users and help them to access protected resources and services.
As an administrator in an enterprise or educational organization, you can create policies to manage Passport use on Windows 10-based devices that connect to your organization.
## Benefits of Microsoft Passport
Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed.
You may wonder [how a PIN can help protect a device better than a password](why-a-pin-is-better-than-a-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone. Because they're stored on the server, a server breach can reveal those stored credentials.
In Windows 10, Passport replaces passwords. The Passport provisioning process creates two cryptographic keys bound to the Trusted Platform Module (TPM), if a device has a TPM, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Passport enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identify provider knows from the combination of Passport keys and gesture that this is a verified identity and provides an authentication token that allows Windows 10 to access resources and services. In addition, during the registration process, the attestation claim is produced for every identity provider to cryptographically prove that the Passport keys are tied to TPM. During registration, when the attestation claim is not presented to the identity provider, the identity provider must assume that the Passport key is created in software.
![how authentication works in microsoft passport](images/authflow.png)
Imagine that someone is looking over your shoulder as you get money from an ATM and sees the PIN that you enter. Having that PIN won't help them access your account because they don't have your ATM card. In the same way, learning your PIN for your device doesn't allow that attacker to access your account because the PIN is local to your specific device and doesn't enable any type of authentication from any other device.
Passport helps protect user identities and user credentials. Because no passwords are used, it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Passport credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are generated within isolated environments of TPMs.
Microsoft Passport also enables Windows 10 Mobile devices to be used as [a remote credential](prepare-people-to-use-microsoft-passport.md#bmk-remote) when signing into Windows 10 PCs. During the sign-in process, the Windows 10 PC can connect using Bluetooth to access Microsoft Passport on the user’s Windows 10 Mobile device. Because users carry their phone with them, Microsoft Passport makes implementing two-factor authentication across the enterprise less costly and complex than other solutions.
**Note**  Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.
> **Note:**  Phone sign-in is currently limited to select Technology Adoption Program (TAP) participants.
 
## How Microsoft Passport works: key points
- Passport credentials are based on certificate or asymmetrical key pair. Passport credentials are bound to the device, and the token that is obtained using the credential is also bound to the device.
- Identify provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps Microsoft Passport's public key to a user account during the registration step.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy.
@ -46,26 +59,45 @@ Microsoft Passport also enables Windows 10 Mobile devices to be used as [a remo
- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use separate containers for keys. Non-Microsoft identity providers can generate keys for their users in the same container as the Microsoft account; however, all keys are separated by identity providers' domains to help ensure user privacy.
- Certificates are added to the Passport container and are protected by the Passport gesture.
- Windows Update behavior: After a reboot is required by Windows Update, the last interactive user is automatically signed on without any user gesture and the session is locked so the user's lock screen apps can run.
## Comparing key-based and certificate-based authentication
Passport can use either keys (hardware or software) or certificates with keys in hardware or software to confirm identity. Enterprises that have a public key infrastructure (PKI) for issuing and managing certificates can continue to use PKI in combination with Passport. Enterprises that do not use PKI or want to reduce the effort associated with managing certificates can rely on key-based credentials for Passport.
Hardware-based keys, which are generated by TPM, provide the highest level of assurance. When the TPM is manufactured, an Endorsement Key (EK) certificate is resident in the TPM. This EK certificate creates a root trust for all other keys that are generated on this TPM.
EK certification is used to generate an attestation identity key (AIK) certificate issued by a Microsoft certificate authority. This AIK certificate can be used as an attestation claim to prove to identity providers that the Passport keys are generated on the same TPM. The Microsoft certificate authority (CA) generates the AIK certificate per device, per user, and per IDP to help ensure that user privacy is protected.
When identity providers such as Active Directory or Azure AD enroll a certificate in Passport, Windows 10 will support the same set of scenarios as a smart card. When the credential type is a key, only key-based trust and operations will be supported.
## Learn more
[Introduction to Windows Hello](http://go.microsoft.com/fwlink/p/?LinkId=786649), video presentation on Microsoft Virtual Academy
[What's new in Active Directory Domain Services (AD DS) in Windows Server Technical Preview](http://go.microsoft.com/fwlink/p/?LinkId=708533)
[Windows Hello face authentication](http://go.microsoft.com/fwlink/p/?LinkId=626024)
[Biometrics hardware guidelines](http://go.microsoft.com/fwlink/p/?LinkId=626995)
[Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!](http://go.microsoft.com/fwlink/p/?LinkId=533890)
[Windows 10: The End Game for Passwords and Credential Theft?](http://go.microsoft.com/fwlink/p/?LinkId=533891)
[Authenticating identities without passwords through Microsoft Passport](http://go.microsoft.com/fwlink/p/?LinkId=616778)
[Microsoft Passport guide](http://go.microsoft.com/fwlink/p/?LinkId=691928)
## Related topics
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
[Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
 
 

20
windows/keep-secure/microsoft-passport-and-password-changes.md
View File

@ -2,37 +2,49 @@
title: Microsoft Passport and password changes (Windows 10)
description: When you set up Microsoft Passport, the PIN or biometric (Windows Hello) gesture that you use is specific to that device.
ms.assetid: 83005FE4-8899-47A6-BEA9-C17CCA0B6B55
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: jdeckerMS
---
# Microsoft Passport and password changes
**Applies to**
- Windows 10
- Windows 10 Mobile
When you set up Microsoft Passport, the PIN or biometric (Windows Hello) gesture that you use is specific to that device. You can set up Passport for the same account on multiple devices. If the PIN or biometric is configured as part of a Microsoft Passport for Work, changing the account password will not impact sign-in or unlock with these gestures since it uses a key or certificate. However, if Microsoft Passport for Work is not deployed and the password for that account changes, you must provide the new password on each device to continue to use Passport.
## Example
Let's suppose that you have set up a PIN for your Microsoft account on **Device A**. You use your PIN to sign in on **Device A** and then change the password for your Microsoft account.
Because you were using **Device A** when you changed your password, the PIN on **Device A** will continue to work with no other action on your part.
Suppose instead that you sign in on **Device B** and change your password for your Microsoft account. The next time that you try to sign in on **Device A** using your PIN, sign-in will fail because the account credentials that Passport on **Device A** knows will be outdated.
**Note**  
This example also applies to an Active Directory account when [Passport for Work is not implemented](implement-microsoft-passport-in-your-organization.md).
> **Note:**  This example also applies to an Active Directory account when [Passport for Work is not implemented](implement-microsoft-passport-in-your-organization.md).
 
## How to update Passport after you change your password on another device
1. When you try to sign in using your PIN or biometric, you will see the following message: **Your password was changed on a different device. You must sign in to this device once with your new password, and then you can sign in with your PIN.**
2. Click **OK.**
3. Click **Sign-in options**.
4. Click the **Password** button.
5. Sign in with new password.
6. The next time that you sign in, you can select **Sign-in options** and then select **PIN** to resume using your PIN.
## Related topics
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
[Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
 
 

23
windows/keep-secure/microsoft-passport-errors-during-pin-creation.md
View File

@ -2,22 +2,30 @@
title: Microsoft Passport errors during PIN creation (Windows 10)
description: When you set up Microsoft Passport in Windows 10, you may get an error during the Create a work PIN step.
ms.assetid: DFEFE22C-4FEF-4FD9-BFC4-9B419C339502
ms.pagetype: security
keywords: ["PIN", "error", "create a work PIN"]
keywords: PIN, error, create a work PIN
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: jdeckerMS
---
# Microsoft Passport errors during PIN creation
**Applies to**
- Windows 10
- Windows 10 Mobile
When you set up Microsoft Passport in Windows 10, you may get an error during the **Create a work PIN** step. This topic lists some of the error codes with recommendations for mitigating the problem. If you get an error code that is not listed here, contact Microsoft Support.
## Where is the error code?
The following image shows an example of an error during **Create a work PIN**.
![](images/pinerror.png)
## Error mitigations
When a user encounters an error when creating the work PIN, advise the user to try the following steps. Many errors can be mitigated by one of these steps.
1. Try to create the PIN again. Some errors are transient and resolve themselves.
2. Sign out, sign in, and try to create the PIN again.
@ -25,6 +33,7 @@ When a user encounters an error when creating the work PIN, advise the user to t
4. Unjoin the device from Azure Active Directory (Azure AD), rejoin, and then try to create the PIN again. To unjoin a desktop PC, go to **Settings** &gt; **System** &gt; **About** and select **Disconnect from organization**. To unjoin a device running Windows 10 Mobile, you must [reset the device](http://go.microsoft.com/fwlink/p/?LinkId=715697).
5. On mobile devices, if you are unable to setup a PIN after multiple attempts, reset your device and start over. For help on how to reset your phone go to [Reset my phone](http://go.microsoft.com/fwlink/p/?LinkId=715697).
If the error occurs again, check the error code against the following table to see if there is another mitigation for that error. When no mitigation is listed in the table, contact Microsoft Support for assistance.
<table>
<thead>
@ -186,6 +195,7 @@ If the error occurs again, check the error code against the following table to s
 
## Errors with unknown mitigation
For errors listed in this table, contact Microsoft Support for assistance.
| Hex | Cause |
|-------------|-------------------------------------------------------------------------------------------------------|
| 0x80072f0c | Unknown |
@ -208,12 +218,17 @@ For errors listed in this table, contact Microsoft Support for assistance.
| 0x801C03F1 | ​There is no UPN in the token |
| ​0x801C044C | There is no core window for the current thread |
 
## Related topics
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
[Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
[Event ID 300 - Passport successfully created](passport-event-300.md)
 
 

137
windows/keep-secure/microsoft-passport-guide.md
View File

@ -2,84 +2,131 @@
title: Microsoft Passport guide (Windows 10)
description: This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system.
ms.assetid: 11EA7826-DA6B-4E5C-99FB-142CC6BD9E84
ms.pagetype: security
keywords: ["security", "credential", "password", "authentication"]
keywords: security, credential, password, authentication
ms.prod: W10
ms.pagetype: security
ms.mktglfcycl: plan
ms.sitesec: library
ms.pagetype: security
author: challum
---
# Microsoft Passport guide
**Applies to**
- Windows 10
This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system. It highlights specific capabilities of these technologies that help mitigate threats from conventional credentials and provides guidance about how to design and deploy these technologies as part of your Windows 10 rollout.
A fundamental assumption about information security is that a system can identify who’s using it. In identifying a user, the system can decide whether the user has identified himself or herself appropriately (a process known as authentication), and then determine what that properly authenticated user should be able to do (a process known as authorization). The overwhelming majority of computer systems deployed throughout the world depend on user credentials as a means of making authentication and authorization decisions, and that means that these systems depend on reusable, user-created passwords for their security. The oft-cited maxim that authentication can involve “something you know, something you have, or something you are” neatly highlights the issue: a reusable password is an authentication factor all by itself, so anyone who knows the password can impersonate the user who owns it.
## Problems with traditional credentials
Ever since the mid-1960s, when Fernando Corbató and his team at the Massachusetts Institute of Technology championed the introduction of the password, users and administrators have had to deal with the use of passwords for user authentication and authorization. Over time, the state of the art for password storage and use has advanced somewhat (with password hashing and salt being the two most noticeable improvements), but we’re still faced with two serious problems: passwords are easy to clone and easy to steal. Implementation faults may render them insecure, and users have a hard time balancing convenience and security.
**Credential theft**
The biggest risk of passwords is simple: an attacker can steal them easily. Every place a password is entered, processed, or stored is vulnerable. For example, an attacker can steal a collection of passwords or hashes from an authentication server by eavesdropping on network traffic to an application server, by implanting malware in an application or on a device, by logging user keystrokes on a device, or by watching to see which characters a user types — and those are just the most common attack methods. One can enact more exotic attacks to steal one or many passwords.
The risk of theft is driven by the fact that the authentication factor the password represents is the password. Without additional authentication factors, the system assumes that anyone who knows the password is the authorized user.
Another, related risk is that of credential replay, in which an attacker captures a valid credential by eavesdropping on an insecure network, and then replays it later to impersonate a valid user. Most authentication protocols (including Kerberos and OAuth) protect against replay attacks by including a time stamp in the credential exchange process, but that protects the token that the authentication system issues, not the password that the user provides to get the ticket in the first place.
**Credential reuse**
The common approach of using an email address as the user name makes a bad problem worse. An attacker who successfully recovers a user name–password pair from a compromised system can then try that same pair on other systems. Surprisingly often, this tactic works to allow attackers to springboard from a compromised system into other systems. The use of email addresses as user names leads to other problems, too, which we’ll explore later in this guide.
### <a href="" id="trading"></a>
**Trading convenience for complexity**
Most security is a tradeoff between convenience and security: the more secure a system is, the less convenient it will typically be for users. Although system designers and implementers have a broad range of tools to make their systems more secure, users get a vote, too. When users perceive that a security mechanism gets in the way of what they want to do, they often look for ways to circumvent it. This behavior leads to an arms race of sorts, with users adopting strategies to minimize the effort required to comply with their organization’s password policies as those policies evolve.
**Password complexity**
If the major risk to passwords is that an attacker might guess them through brute-force analysis, it might seem reasonable to require users to include a broader character set in their passwords or make them longer, but as a practical matter, password length and complexity requirements have two negative side effects. First, they encourage password reuse. Estimates by [Herley, Florêncio, and van Oorschot](http://go.microsoft.com/fwlink/p/?LinkId=627392) calculate that the stronger a password is, the more likely it is to be reused. Because users put more effort into the creation and memorization of strong passwords, they are much more likely to use the same credential across multiple systems. Second, adding length or character set complexity to passwords does not necessarily make them more difficult to guess. For example, P@ssw0rd1 is nine characters long and includes uppercase and lowercase letters, numbers, and special characters, but it’s easily guessed by many of the common password-cracking tools now available on the Internet. These tools can attack passwords by using a pre-computed dictionary of common passwords, or they can start with a base word such as password, and then apply common character substitutions. A completely random eight-character password might therefore actually take longer to guess than P@ssw0rd123.
**Password expiration**
Because a reusable password is the only authentication factor in password-based systems, designers have attempted to reduce the risk of credential theft and reuse. One common method for doing so is the use of limited-lifetime passwords. Some systems allow for passwords that can be used only once, but by far the more common approach is to make passwords expire after a certain period. Limiting the useful lifetime of a password puts a cap on how long a stolen password will be useful to an attacker. This practice helps protect against cases where a long-lived password is stolen, held, and used for a long time, but it also harkens back to the time when password cracking was impractical for everyone except nation state-level attackers. A smart attacker would attempt to steal passwords rather than crack them because of the time penalty associated with password cracking.
The widespread availability of commodity password-cracking tools and the massive computing power available through mechanisms such as GPU-powered crackers or distributed cloud-based cracking tools has reversed this equation so that it is often more effective for an attacker to crack a password than to try to steal it. In addition, the widespread availability of self-service [password-reset mechanisms](#password-reset) means that an attacker needs only a short window of time during which the password is valid to change the password and thus reset the validity period. Relatively few enterprise networks provide self-service password-reset mechanisms, but they are common for Internet services. In addition, many users use the secure credential store on Windows and Mac OS X systems to store valuable passwords for Internet services, so an attacker who can compromise the operating system password may be able to obtain a treasure trove of other service passwords at no cost.
Finally, overly short timelines for password expiration can tempt users to make small changes in their passwords at each expiration period — for example, moving from password123 to password456 to password789. This approach reduces the work necessary to crack the password, especially if the attacker knows any of the old passwords.
### <a href="" id="password-reset"></a>
**Password-reset mechanisms**
To let users better manage their own passwords, some services provide a way for users to change their own password. Some implementations require users to log on with their current password, while others allow users to select the **Forgot my password** option, which sends an email to the user’s registered email address. The problem with these mechanisms is that many of them are implemented such that an attacker can exploit them. For example, an attacker who can successfully guess or steal a user’s email password can merrily request password resets for all of the victim’s other accounts, because the reset emails go to the compromised account. For this reason, most enterprise networks are configured so that only administrators can reset user passwords; for example, Active Directory supports the use of a **Password must be changed on next logon** flag so that after the administrator resets a password, the user can reset the password only after providing the administrator-set password. Some mobile device management (MDM) systems support similar functionality for mobile devices.
**User password carelessness**
An insidious problem makes these design and implementation weaknesses worse: some users just aren’t careful with their passwords. They write them down in insecure locations, choose easy-to-guess passwords, take minimal (if any) precautions against malware, or even give their passwords to other people. These users aren’t necessarily careless because they don’t care; they want to get things done, and overly stringent password length or expiration policies or too many passwords hinders them.
**Mitigate credential risks**
Given the issues described so far, it might seem obvious that reusable passwords are a security hazard. The argument is simple: adding authentication factors reduces the value of the passwords themselves, because even a successful password theft won’t let an attacker log on to a system unless he or she also has the associated additional factors. Unfortunately, this simple argument has many practical complications. Security and operating system vendors have tried to solve the problems that reusable credentials pose for decades — with limited success.
The most obvious mitigation to the risks reusable passwords pose is to add one or more authentication factors. At different times over the past 30 years, different vendors have attempted to solve this problem by calling for the use of biometric identifiers (including fingerprints, iris and retina scans, and hand geometry), software-based and hardware-based tokens, physical and virtual smart cards, and voice or Short Message Service (SMS) authentication through the user’s mobile phone. A detailed description of each of these authenticators and its pros and cons is outside the scope of this guide, but no matter which authentication method you choose, core challenges have limited adoption of all Multi-Factor Authentication (MFA) solutions, including:
- **Infrastructure complexity and cost.** Any system that requires the user to provide an additional authentication factor at the point of access has to have a way to collect that information. Although it’s possible to retrofit fielded hardware by adding fingerprint readers, eye scanners, smart card readers, and so on, few enterprises have been willing to take on the cost and support burden required to do so.
- **Lack of standardization.** Although Microsoft included operating system–level smart card support as part of the Windows Vista operating system, smart card and reader vendors were free to continue to ship their own drivers, as were manufacturers of other authentication devices. Lack of standardization led to both application and support fragmentation, which means that it wasn’t always possible to mix and match solutions within an enterprise, even when the manufacturers of those solutions advertised them as being compatible.
- **Backward compatibility.** Retrofitting already-deployed operating systems and applications to use MFA has proven an extremely difficult task. Nearly three years after its release, Microsoft Office 2013 is finally getting support for MFA. The vast majority of both commercial and custom line-of-business (LOB) applications will never be retrofitted to take advantage of any authentication system other than what the underlying operating system provides.
- **User inconvenience.** Solutions that require users to obtain, keep track of, and use physical tokens are often unpopular. If users have to have a particular token for remote access or other scenarios that are supposed to make things more convenient, they tend to become quickly dissatisfied with the burden of keeping up with an additional device. This pushback is multiplied for solutions that have to be attached to computers (such as smart card readers) because such solutions introduce problems of portability, driver support, and operating system and application integration.
- **Device compatibility.** Not every hardware form factor supports every authentication method. For example, despite occasional feeble efforts from vendors, no market for mobile phone-compatible smart card readers ever emerged. So when Microsoft first implemented smart cards as an authenticator for remote network access, one key limitation was that employees could log on only from desktop or laptop computers that had smart card readers. Any authentication method that relies on additional hardware or software may run into this problem. For example, several popular “soft token” systems rely on mobile apps that run on a limited number of mobile hardware platforms.
- **Device compatibility.** Not every hardware form factor supports every authentication method. For example, despite occasional feeble efforts from vendors, no market for mobile phone-compatible smart card readers ever emerged.
So when Microsoft first implemented smart cards as an authenticator for remote network access, one key limitation was that employees could log on only from desktop or laptop computers that had smart card readers. Any authentication method that relies on additional hardware or software may run into this problem. For example, several popular “soft token” systems rely on mobile apps that run on a limited number of mobile hardware platforms.
Another pesky problem has to do with institutional knowledge and maturity. Strong authentication systems are complex. They have lots of components, and they can be expensive to design, maintain, and operate. For some enterprises, the additional cost and overhead of maintaining an in-house public key infrastructure (PKI) to issue smart cards or the burden of managing add-on devices exceeds the value they perceive in having stronger authentication. This is a special case of the common problem that financial institutions face: if the cost of fraud reduction is higher than the cost of the fraud itself, it’s hard to justify the economics of better fraud-prevention measures.
## Solve credential problems
Solving the problems that passwords pose is tricky. Tightening password policies alone won’t do it: users may just recycle, share, or write down passwords. Although user education is critical for authentication security, education alone doesn’t eliminate the problem, either.
As you’ve seen, additional authenticators won’t necessarily help if the new authentication systems add complexity, cost, or fragility. In Windows 10, Microsoft addresses these problems with two new technologies: Windows Hello and Microsoft Passport. Working together, these technologies help increase both security and user convenience:
- Microsoft Passport replaces passwords with strong two-factor authentication (2FA) by verifying existing credentials and by creating a device-specific credential that a user gesture (either biometric or PIN-based) protects. This combination effectively replaces physical and virtual smart cards as well as reusable passwords for logon and access control.
- Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras, and fingerprint reader hardware can be used or added to devices that don’t currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users’ Microsoft Passport credentials.
## What is Windows Hello?
Windows Hello is the name Microsoft has given to the new biometric sign-in system built into Windows 10. Because it is built directly into the operating system, Windows Hello allows face or fingerprint identification to unlock users’ devices. Authentication happens when the user supplies his or her unique biometric identifier to access the device-specific Microsoft Passport credentials, which means that an attacker who steals the device can’t log on to it unless that attacker has the PIN. The Windows secure credential store protects biometric data on the device. By using Windows Hello to unlock a device, the authorized user gains access to all of his or her Windows experience, apps, data, websites, and services.
The Windows Hello authenticator is known as a Hello. A Hello is unique to the combination of an individual device and a specific user; it doesn’t roam among devices, isn’t shared with a server, and cannot easily be extracted from a device. If multiple users share a device, each user gets a unique Hello for that device. You can think of a Hello as a token you can use to unlock (or release) a stored credential: the Hello itself doesn’t authenticate you to an app or service, but it releases credentials that can.
At the launch of Windows 10, the operating system supported three Hello types:
- **PIN.** Before you can use Windows Hello to enable biometrics on a device, you must choose a PIN as your initial Hello gesture. After you’ve set a PIN, you can add biometric gestures if you want to. You can always use the PIN gesture to release your credentials, so you can still unlock and use your device even if you can’t use your preferred biometric because of an injury or because the sensor is unavailable or not working properly.
- **Facial recognition.** This type uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well.
- **Fingerprint recognition.** This type uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10.
Biometric data used to implement these Hello gestures is stored securely on the local device only. It doesn’t roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there’s no single collection point an attacker can compromise to steal biometric data. Breaches that expose biometrics collected and stored for other uses (such as fingerprints collected and stored for law enforcement or background check purposes) don’t pose a significant threat: an attacker who steals biometrics literally has only a template of the identifier, and that template cannot easily be converted to a form that the attacker can present to a biometric sensor. The data path for Windows Hello-compatible sensors is resistant to tampering, too, which further reduces the chance that an attacker will be able to successfully inject faked biometric data. In addition, before an attacker can even attempt to inject data into the sensor pipeline, that attacker must gain physical access to the device — and an attacker who can do that can mount several other, less difficult attacks.
Windows Hello offers several major benefits. First, when combined with Microsoft Passport, it effectively solves the problems of credential theft and sharing. Because an attacker must obtain both the device and the selected biometric, it is much more difficult to gain access without the user’s knowledge. Second, the use of biometrics means that users benefit from having a simple authenticator that’s always with them: there’s nothing to forget, lose, or leave behind. Instead of worrying about memorizing long, complex passwords, users can take advantage of a convenient, secure method for signing in to all their Windows devices. Finally, in many cases, there’s nothing additional to deploy or manage to use Windows Hello (although Microsoft Passport may require additional deployment, as described later in this guide). Windows Hello support is built directly into the operating system, and users or enterprises can add compatible biometric devices to provide biometric gesture recognition, either as part of a coordinated rollout or as individual users or groups decide to add the necessary sensors. Windows Hello is part of Windows, so no additional deployment is required to start using it.
## What is Microsoft Passport?
Windows Hello provides a robust way for a device to recognize an individual user; that addresses the first part of the path between a user and a requested service or data item. After the device has recognized the user, however, it still must authenticate the user before deciding whether to grant access to a requested resource. Microsoft Passport provides strong 2FA, fully integrated into Windows, that replaces reusable passwords with the combination of a specific device and a Hello or PIN. Microsoft Passport isn’t just a replacement for traditional 2FA systems, though. It’s conceptually similar to smart cards: authentication is performed by using cryptographic primitives instead of string comparisons, and the user’s key material is secure inside tamper-resistant hardware. Microsoft Passport doesn’t require the extra infrastructure components required for smart card deployment, either. In particular, you don’t need a PKI if you don’t currently have one. Microsoft Passport combines the major advantage of smart cards — deployment flexibility for virtual smart cards and robust security for physical smart cards — without any of their drawbacks.
Microsoft Passport offers four significant advantages over the current state of Windows authentication: it’s more flexible, it’s based on industry standards, it’s an effective risk mitigator, and it’s ready for the enterprise. Let’s look at each of these advantages in more detail.
**It’s flexible**
Microsoft Passport offers unprecedented flexibility. Although the format and use of reusable passwords are fixed, Microsoft Passport gives both administrators and users options to manage authentication. First and foremost, Microsoft Passport works with both biometric identifiers and PINs, so users’ credentials are protected even on devices that don’t support biometrics. Users can even use their phone to release their credentials instead of a PIN or biometric gesture on the main device. Microsoft Passport seamlessly takes advantage of the hardware of the devices in use; as users upgrade to newer devices, Microsoft Passport is ready to use them, and organizations can upgrade existing devices by adding biometric sensors where appropriate.
Microsoft Passport offers flexibility in the datacenter, too. To deploy it, in some modes you must add Windows Server 2016 Technical Preview domain controllers to your Active Directory environment, but you don’t have to replace or remove your existing Active Directory servers — the servers required for Microsoft Passport build on and add capability to your existing infrastructure. You don’t have to change the domain or forest functional level, and you can either add on-premises servers or use Microsoft Azure Active Directory to deploy Microsoft Passport on your network. The choice of which users you should enable for Microsoft Passport use is completely up to you: you choose the policies and devices to support and which authentication factors you want users to have access to. This makes it easy to use Microsoft Passport to supplement existing smart card or token deployments by adding strong credential protection to users who don’t currently have it or to deploy Microsoft Passport in scenarios that call for extra protection for sensitive resources or systems (described in the [Design a Microsoft Passport deployment](#design) section).
**It’s standardized**
Both software vendors and enterprise customers have come to realize that proprietary identity and authentication systems are a dead end. The future lies with open, interoperable systems that allow secure authentication across a variety of devices, LOBs, and external applications and websites. To this end, a group of industry players formed the Fast IDentity Online Alliance (FIDO), a nonprofit organization intended to address the lack of interoperability among strong authentication devices as well as the problems users face when they have to create and remember multiple user names and passwords. The FIDO Alliance plans to change the nature of authentication by developing specifications that define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to securely authenticate users of online services. This new standard for security devices and browser plug ins will allow any website or cloud application to interface with a broad variety of existing and future FIDO-enabled devices that the user has for online security. For more information, see the [FIDO Alliance website](http://go.microsoft.com/fwlink/p/?LinkId=627393).
In 2013, Microsoft joined the FIDO Alliance. FIDO standards enable a universal framework that a global ecosystem delivers for a consistent and greatly improved user experience of strong passwordless authentication. The FIDO 1.0 specifications, published in December 2014, provide for two types of authentications: passwordless (known as the Universal Authentication Framework \[UAF\]) and 2nd Factor (U2F). The FIDO Alliance is working on a set of 2.0 proposals to combine the best parts of the U2F and UAF FIDO 1.0 standards. Microsoft is actively contributing to the proposals, and Windows 10 is a reference implementation of these concepts. In addition to supporting those protocols, the Windows implementation covers other aspects of the end-to-end experience that the specification does not cover, including user interface to, storage of, and protection for users’ device keys and the tokens issued after authentication; supporting administrator policies; and providing deployment tools. Microsoft expects to continue working with the FIDO Alliance as the FIDO 2.0 specification moves forward. Interoperability of FIDO products is a hallmark of FIDO authentication. Microsoft believes that bringing a FIDO solution to market will help solve a critical need for enterprises and consumers alike.
**It’s effective**
Microsoft Passport effectively mitigates two major security risks. First, by eliminating the use of reusable passwords for logon, it reduces the risk that a user’s credential will be copied or reused. On devices that support the Trusted Platform Module (TPM) standard, user key material can be stored in the user device’s TPM, which makes it more difficult for an attacker to capture the key material and reuse it. For devices that lack TPM, Microsoft Passport can encrypt and store credential data in software, but administrators can disable this feature to force a “TPM or nothing” deployment.
Second, because Microsoft Passport doesn’t depend on a single, centralized server, the risk of compromise from a breach of that server is removed. Although an attacker could theoretically compromise a single device, there’s no single point of attack that an intruder can leverage to gain widespread access to the environment.
**It’s enterprise-ready**
Every edition of Windows 10 includes Microsoft Passport functionality for individual use; enterprise and personal users can take advantage of Microsoft Passport to protect their individual credentials with compatible applications and services. In addition, enterprises whose users are running Windows 10 Professional and Windows 10 Enterprise have the ability to use Microsoft Passport for Work, an enhanced version of Microsoft Passport that includes the ability to centrally manage Microsoft Passport settings for PIN strength and biometric use through Group Policy Objects (GPOs).
## How Microsoft Passport works
To use Microsoft Passport to sign in with an identity provider (IDP), a user needs a configured device, which means that the Microsoft Passport life cycle starts when you configure a device for Microsoft Passport use. When the device is set up, its user can use the device to authenticate to services. In this section, we explore how device registration works, what happens when a user requests authentication, how key material is stored and processed, and which servers and infrastructure components are involved in different parts of this process.
**Register a new user or device**
A goal of Microsoft Passport is to allow a user to open a brand-new device, securely join an organizational network to download and manage organizational data, and create a new Hello gesture to secure the device. Microsoft refers to the process of setting up a device for use with Microsoft Passport as registration.
**Note**  
This is separate from the organizational configuration required to use Microsoft Passport with Active Directory or Azure AD; that configuration is discussed later in this guide. This configuration must be completed before users can begin to register.
> **Note:**  This is separate from the organizational configuration required to use Microsoft Passport with Active Directory or Azure AD; that configuration is discussed later in this guide. This configuration must be completed before users can begin to register.
 
The registration process works like this:
1. The user configures an account on the device.
@ -88,26 +135,44 @@ The registration process works like this:
The IDP that “owns” the account receives the credentials and authenticates the user. This IDP authentication may include the use of an existing second authentication factor, or proof. For example, a user who registers a new device by using an Azure AD account will have to provide an SMS-based proof that Azure AD sends.
3. When the user has provided the proof to the IDP, the user enables PIN authentication (Figure 1).
The PIN will be associated with this particular credential.
![figure 1](images/passport-fig1.png)
Figure 1. Set up a PIN in the **Account Settings** control panel item
When the user sets the PIN, it becomes usable immediately (Figure 2).
![figure 2](images/passport-fig2-pinimmeduse.png)
Figure 2. When set, the PIN is immediately usable
Remember that Microsoft Passport depends on pairing a device and a credential, so the PIN chosen is associated only with the combination of the active account and that specific device. The PIN must comply with whatever length and complexity policy the account administrator has configured; this policy is enforced on the device side. Other registration scenarios that Microsoft Passport supports are:
- A user who upgrades from the Windows 8.1 operating system will log on by using his or her existing enterprise password. That triggers MFA from the IDP side; after receiving and returning a proof, such as a text message or voice code, the IDP authenticates the user to the upgraded Windows 10 device, and the user can set his or her PIN.
- A user who typically uses a smart card to log on will be prompted to set up a PIN the first time he or she logs on to a Windows 10 device the user has not previously logged on to.
- A user who typically uses a virtual smart card to log on will be prompted to set up a PIN the first time he or she logs on to a Windows 10 device the user has not previously logged on to.
When the user has completed this process, Microsoft Passport generates a new public–private key pair on the device. The TPM generates and stores this private key; if the device doesn’t have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the protector key. It’s associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. The protector key securely wraps the authentication key for a specific container. Each container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys (each of which is associated with a unique gesture). Microsoft Passport also generates an administrative key that the user or administrator can use to reset credentials, when necessary. In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM.
At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means he or she is able to securely log on to the device with the PIN and thus that he or she can establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using his or her PIN, and then registers the new biometric (“smile for the camera!”), after which Windows generates a unique key pair and stores it securely. Future logons can then use either the PIN or the registered biometric gestures.
**What’s a container?**
You’ll often hear the term *container* used in reference to MDM solutions. Microsoft Passport uses the term, too, but in a slightly different way. Container in this context is shorthand for a logical grouping of key material or data. Windows 10 supports two containers: the default container holds user key material for personal accounts, including key material associated with the user’s Microsoft account or with other consumer identity providers, and the enterprise container holds credentials associated with a workplace or school account.
The enterprise container exists only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Azure AD. The enterprise container contains only key data for Active Directory or Azure AD. If the enterprise container is present on a device, it’s unlocked separately from the default container, which maintains separation of data and access across personal and enterprise credentials and services. For example, a user who uses a biometric gesture to log on to a managed computer can separately unlock his or her personal container by entering a PIN when logging on to make a purchase from a website.
These containers are logically separate. Organizations don’t have any control over the credentials users store in the default container, and applications that authenticate against services in the default container can’t use credentials from the enterprise container. However, individual Windows applications can use the Microsoft Passport application programming interfaces (APIs) to request access to credentials as appropriate, so that both consumer and LOB applications can be enhanced to take advantage of Microsoft Passport.
It’s important to keep in mind that there are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials Microsoft Passport stores are protected without the creation of actual containers or folders.
Each container actually contains a set of keys, some of which are used to protect other keys. Figure 3 shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container.
![figure 3](images/passport-fig3-logicalcontainer.png)
Figure 3. Each logical container holds one or more sets of keys
Containers can contain several types of key material:
- An *authentication key*, which is always an asymmetric public–private key pair. This key pair is generated during registration. It must be unlocked each time it’s accessed, by using either the user’s PIN or a previously generated biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key.
- *Virtual smart card keys* are generated when a virtual smart card is generated and stored securely in the container. They’re available whenever the user’s container is unlocked.
- *Secure/Multipurpose Internet Mail Extensions (S/MIME) keys and certificates*, which a certification authority (CA) generates. The keys associated with the user’s S/MIME certificate can be stored in a Microsoft Passport container so they’re available to the user whenever the container is unlocked.
@ -115,14 +180,22 @@ Containers can contain several types of key material:
Microsoft accounts, Active Directory accounts, and Azure AD accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways:
- The IDP key pair can be associated with an enterprise CA through the Windows Network Device Enrollment Service (NDES), described more fully in [Network Device Enrollment Service Guidance](http://go.microsoft.com/fwlink/p/?LinkId=733947). In this case, Microsoft Passport requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as popular virtual private network systems, require the use of certificates, when you deploy Microsoft Passport in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container.
- The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Microsoft Passport in environments that don’t have or need a PKI.
**How keys are protected**
Any time key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Microsoft Passport for Work implementation takes advantage of onboard TPM hardware to generate, store, and process keys. However, Microsoft Passport and Microsoft Passport for Work do not require an onboard TPM. Administrators can choose to allow key operations in software, in which case any user who has (or can escalate to) administrative rights on the machine can use the IDP keys to sign requests. As an alternative, in some scenarios, devices that don’t have a TPM can be remotely authenticated by using a device that does have a TPM, in which case all the sensitive operations are performed with the TPM and no key material is exposed.
Whenever possible, Microsoft recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means he or she will have to use MFA to reauthenticate to the IDP before the IDP allows him or her to re-register). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.
**Authentication**
When a user wants to access protected key material — perhaps to use an Internet site that requires a logon or to access protected resources on a corporate intranet — the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called *releasing the key*. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. On a personal device that’s connected to an organizational network, users will use their personal PIN or biometric to release the key; on a device joined to an on-premises or Azure AD domain, they will use the organizational PIN.
This process unlocks the protector key for the primary container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It’s important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or log on to a website). Access through these APIs doesn’t require explicit validation through a user gesture, and the key material isn’t exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Microsoft Passport layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure the Windows Store to require reauthentication any time a user purchases an application, even though the same account and PIN or gesture were already used to unlock the device.
The actual authentication process works like this:
1. The client sends an empty authentication request to the IDP. (This is merely for the handshake process.)
2. The IDP returns a challenge, known as a *nonce*.
3. The device signs the nonce with the appropriate private key.
@ -131,55 +204,85 @@ The actual authentication process works like this:
6. If all the checks in step 5 succeed, the IDP returns two data items: a symmetric key, which is encrypted with the device’s public key, and a security token, which is encrypted with the symmetric key.
7. The device uses its private key to decrypt the symmetric key, and then uses that symmetric key to decrypt the token.
8. The device makes a normal authentication request for the original resource, presenting the token from the IDP as its proof of authentication.
When the IDP validates the signature, it is verifying that the request came from the specified user and device. The private key specific to the device signs the nonce, which allows the IDP to determine the identity of the requesting user and device so that it can apply policies for content access based on user, device type, or both together. For example, an IDP could allow access to one set of resources only from mobile devices and a different set from desktop devices.
Remote unlock, which is planned for a future release of Windows 10, builds on these scenarios by enabling seamless remote authentication from a mobile device as a second factor. For example, suppose that you’re visiting another office at your company and you need to borrow a computer there temporarily, but you don’t want to potentially expose your credentials to capture. Rather than type in your credentials, you can click **other user** on the Windows 10 logon screen, type your user name, pick the tile for remote authentication, and use an app on your phone, which you already unlocked by using its built-in facial-recognition sensors. The phone and computer are paired and handshake via Bluetooth, you type your authentication PIN on the phone, and the computer gets confirmation of your identity from the IDP. All this happens without typing a password anywhere or typing your PIN on the PC.
**The infrastructure**
Microsoft Passport depends on having compatible IDPs available to it. As of this writing, that means you have four deployment possibilities:
- Use an existing Windows-based PKI centered around Active Directory Certificate Services. This option requires additional infrastructure, including a way to issue certificates to devices. You can use NDES to register devices directly, Microsoft System Center Configuration Manager Technical Preview or later for on-premises environments, or Microsoft Intune where it’s available to manage mobile device participation in Microsoft Passport.
- You can configure Windows Server 2016 Technical Preview domain controllers to act as IDPs for Microsoft Passport. In this mode, the Windows Server 2016 Technical Preview domain controllers act as IDPs alongside any existing Windows Server 2008 R2 or later domain controllers. There is no requirement to replace all existing domain controllers, merely to introduce at least one Windows Server 2016 Technical Preview domain controller per Active Directory site and update the forest Active Directory Domain Services (AD DS) schema to Windows Server 2016 Technical Preview.
- The normal discovery mechanism that clients use to find domain controllers and global catalogs relies on Domain Name System (DNS) SRV records, but those records don’t contain version data. Windows 10 computers will query DNS for SRV records to find all available Active Directory servers, and then query each server to identify those that can act as Microsoft Passport IDPs. The number of authentication requests your users generate, where your users are located, and the design of your network all drive the number of Windows Server 2016 Technical Preview domain controllers required.
- Azure AD can act as an IDP either by itself or alongside an on-premises AD DS forest. Organizations that use Azure AD can register devices directly without having to join them to a local domain by using the capabilities the Azure AD Device Registration service provides.
In addition to the IDP, Microsoft Passport requires an MDM system. This system can be the cloud-based Intune if you use Azure AD, or an on-premises System Center Configuration Manager deployment that meets the system requirements described in the [Deployment requirements](#deployreq) section of this document.
## <a href="" id="design"></a>Design a Microsoft Passport for Work deployment
Microsoft Passport for Work is designed for integration with your existing and future directory infrastructure and device deployments, but this flexibility means there are many considerations to think about when you design your deployment. Some of these decisions are technical, while others are organizational or even political. In this section, we examine the key points where you have to make decisions about how to implement Microsoft Passport for Work. Remember, individual devices can use the individual version of Microsoft Passport without any infrastructure changes on your part. Microsoft Passport for Work allows you to control and centrally manage user authentication and device registration. To use the initial version of Microsoft Passport for Work, each device must have an Azure AD identity, so automatic registration of devices provides a means both to register new devices and to apply optional policies to manage Microsoft Passport for Work.
**One deployment strategy**
Different organizations will necessarily take different approaches to the deployment of Microsoft Passport depending on their capabilities and needs, but there is only one strategy: deploy Microsoft Passport for Work throughout the organization to get maximum protection for the maximum number of devices and resources. Organizations can take one of three basic routes to accomplish that strategy:
- Deploy Microsoft Passport for Work everywhere according to whatever device or user deployment strategy works best for the organization.
- Deploy Microsoft Passport for Work first to high-value or high-risk targets, by using conditional access policies to restrict access to key resources only to users who hold strong authentication credentials.
- Blend Microsoft Passport for Work into an existing multi-factor environment, using it as an additional form of strong authentication alongside physical or virtual smart cards.
**Deploy Microsoft Passport for Work everywhere**
In this approach, you deploy Microsoft Passport throughout the organization in a coordinated rollout. In some ways, this method is similar to any other desktop deployment project; the only real difference is that you must already have the Microsoft Passport infrastructure in place to support device registration before you can start using Microsoft Passport on Windows 10 devices.
**Note**  
You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Microsoft Passport for Work on a device until the device joins Azure AD and receives the appropriate policy.
> **Note:**  You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Microsoft Passport for Work on a device until the device joins Azure AD and receives the appropriate policy.
 
The major benefit of this approach is that it provides uniform protection for all parts of the organization. Sophisticated attackers have shown a great deal of skill in breaching large organizations by identifying weak points in their security, including users and systems that don’t have high-value information but that can be exploited to get it. Applying consistent protection across every device that an attacker could use to access enterprise data is excellent protection against these types of attacks.
The downside to this approach is its complexity. Smaller organizations may find that managing the rollout of a new operating system across all devices is beyond the scope of their experience and capability. For these organizations, users can self-upgrade, and new users may end up with Windows 10 because they get new devices when they join. Larger organizations, especially those that are highly decentralized or have operations across many physical sites, may have more deployment knowledge and resources but face the challenge of coordinating rollout efforts across a larger user base and footprint.
For more information about desktop deployment of Windows 10, visit the [Windows 10 TechCenter](http://go.microsoft.com/fwlink/p/?LinkId=626581).
One key aspect of this deployment strategy is how to get Windows 10 in users’ hands. Because different organizations have wildly differing strategies to refresh hardware and software, there’s no one-size-fits-all strategy. For example, some organizations pursue a coordinated strategy that puts new desktop operating systems in users’ hands every 2–3 years on existing hardware, supplementing with new hardware only where and when required. Others tend to replace hardware and deploy whatever version of the Windows client operating system ships on the purchased devices. In both cases, there are typically separate deployment cycles for servers and server operating systems, and the desktop and server cycles may or may not be coordinated.
In addition to the issue of Windows 10 deployment to users, you must consider how and when (or if!) you’ll deploy biometric devices to users. Because Windows Hello can take advantage of multiple biometric identifiers, you have a flexible range of device options, which includes the purchase of new devices that incorporate your selected biometric, seeding select users with appropriate devices, rollout of biometric devices as part of a scheduled hardware refresh and using PIN gestures until users get devices, or relying on remote unlock as a second authentication factor.
**Deploy to high-value or high-risk targets**
This strategy takes into account the fact that in most networks, not every asset is equally protected or equally valuable. There are two ways to think about this. One is that you can focus on protecting the users and services that are most at risk of compromise because of their value. Examples include sensitive internal databases or the user accounts of your key executives. The other option is that you can focus on areas of your network that are the most vulnerable, such as users who travel frequently (and thus run a higher risk of lost or stolen devices or drive-by credential theft). Either way, the strategy is the same: selectively and quickly deploy Microsoft Passport to protect specific people and resources. For example, you might issue new Windows 10 devices with biometric sensors to all users who need access to a sensitive internal database, and then deploy the minimum required infrastructure to support Microsoft Passport–secured access to that database for those users.
One of the key design capabilities of Microsoft Passport for Work is that it supports Bring Your Own Device (BYOD) environments by allowing users to register their own devices with the organizational IDP (whether on premises, hybrid, or Azure AD). You may be able to take advantage of this capability to quickly deploy Microsoft Passport to protect your most vulnerable users or assets, ideally by using biometrics as an additional safety measure for the most valuable potential targets.
**Blend Microsoft Passport with your infrastructure**
Organizations that have already invested in smart cards, virtual smart cards, or token-based systems can still benefit from Microsoft Passport. Of those organizations, many use physical tokens and smart cards to protect only critical assets because of the expense and complexity of their deployment. Microsoft Passport offers a valuable complement to these systems because it protects users who currently rely on reusable credentials; protection of all users’ credentials is an important step toward blunting attacks that seek to leverage compromise of any credential into a widespread breach. This approach also gives you a great deal of flexibility in scheduling and deployment.
Some enterprises have deployed multi-use smart cards that provide building-access control, access to copiers or other office equipment, stored value for lunchroom purchases, remote network access, and other services. Deployment of Microsoft Passport in such environments doesn’t prevent you from continuing to use smart cards for these services. You can leave the existing smart card infrastructure in place for its existing use cases, and then register desktop and mobile devices in Microsoft Passport and use Microsoft Passport to secure access to network and Internet resources. This approach requires a more complicated infrastructure and a greater degree of organizational maturity because it requires you to link your existing PKI with an enrollment service and Microsoft Passport itself.
Smart cards can act as a useful complement to Microsoft Passport in another important way: to bootstrap the initial logon for Microsoft Passport registration. When a user registers with Microsoft Passport on a device, part of that registration process requires a conventional logon. Rather than using a traditional password, organizations that have previously deployed the necessary infrastructure for smart cards or virtual smart cards can allow their users to register new devices by logging on with a smart card or virtual smart card. After the user has proved his or her identity to the organizational IDP with the smart card, the user can set up a PIN and proceed to use Microsoft Passport for future logons.
**Choose a rollout method**
Which rollout method you choose depends on several factors:
- **How many devices you need to deploy.** This number has a huge influence on your overall deployment. A global rollout for 75,000 users has different requirements than a phased rollout for groups of 200–300 users in different cities.
- **How quickly you want to deploy Microsoft Passport for Work protection.** This is a classic cost–benefit tradeoff. You have to balance the security benefits of Microsoft Passport for Work against the cost and time required to deploy it broadly, and different organizations may make entirely different decisions depending on how they rate the costs and benefits involved. Getting the broadest possible Microsoft Passport coverage in the shortest time possible maximizes security benefits.
- **The type of devices you want to deploy.** Windows device manufacturers are aggressively introducing new devices optimized for Windows 10, leading to the possibility that you might deploy Microsoft Passport first on newly purchased tablets and portable devices, and then deploy it on the desktop as part of your normal refresh cycle.
- **What your current infrastructure looks like.** The individual version of Microsoft Passport doesn’t require changes to your Active Directory environment, but to support Microsoft Passport for Work, you may need a compatible MDM system. Depending on the size and composition of your network, mobile enrollment and management services deployment may be a major project in its own right.
- **Your plans for the cloud.** If you’re already planning a move to the cloud, Azure AD eases the process of Microsoft Passport for Work deployment, because you can use Azure AD as an IDP alongside your existing on-premises AD DS setup without making significant changes to your on-premises environment. Future versions of Microsoft Passport for Work will support the ability to simultaneously register devices that are already members of an on-premises AD DS domain in an Azure AD partition so that they use Microsoft Passport for Work from the cloud. Hybrid deployments that combine AD DS with Azure AD give you the ability to keep machine authentication and policy management against your local AD DS domain while providing the full set of Microsoft Passport for Work services (and Microsoft Office 365 integration) for your users. If you plan to use on-premises AD DS only, then the design and configuration of your on-premises environment will dictate what kind of changes you may need to make.
### <a href="" id="deployreq"></a>
**Deployment requirements**
Table 1 lists six scenarios for deployment of Microsoft Passport for Work in the enterprise. The initial release of Windows 10 supports Azure AD–only scenarios, with support for on-premises Microsoft Passport for Work planned for a future release (see the [Roadmap](#roadmap) section for more details).
Depending on the scenario you choose, Microsoft Passport for Work deployment may require four elements:
- An organizational IDP that supports Microsoft Passport. This can be Azure AD or a set of on-premises Windows Server 2016 Technical Preview domain controllers in an existing AD DS forest. Using Azure AD means that you can establish hybrid identity management, with Azure AD acting as a Microsoft Passport IDP and your on-premises AD DS environment handling older authentication requests. This approach provides all the flexibility of Azure AD with the ability to manage computer accounts and devices running older versions of Windows and on-premises applications such as Microsoft Exchange Server or Microsoft SharePoint.
- If you use certificates, an MDM system is required to allow policy management of Microsoft Passport for Work. Domain-joined devices in on-premises or hybrid deployments require Configuration Manager Technical Preview or later. Deployments with Azure AD must use either Intune or a compatible non-Microsoft MDM solution.
- On-premises deployments require the forthcoming Active Directory Federation Services (AD FS) version included in Windows Server 2016 Technical Preview to support provisioning of Microsoft Passport credentials to devices. In this scenario, AD FS takes the place of the provisioning that Azure AD performs in cloud-based deployments.
- Certificate-based Microsoft Passport deployments require a PKI, including CAs that are accessible to all devices that need to register. If you deploy certificate-based Microsoft Passport on premises, you don’t actually need Windows Server 2016 Technical Preview domain controllers. On-premises deployments do need to apply the Windows Server 2016 Technical Preview AD DS schema and have the Windows Server 2016 Technical Preview version of AD FS installed.
Table 1. Deployment requirements for Microsoft Passport
<table>
<colgroup>
<col width="25%" />
@ -230,42 +333,55 @@ Table 1. Deployment requirements for Microsoft Passport
Note that the current release of Windows 10 supports the Azure AD–only (RTM) and hybrid scenarios (RTM + November Update). Microsoft provides the forward-looking guidance in Table 1 to help organizations prepare their environments for planned future releases of Microsoft Passport for Work capabilities.
**Select policy settings**
Another key aspect of Microsoft Passport for Work deployment involves the choice of which policy settings to apply to the enterprise. There are two parts to this choice: which policies you deploy to manage Microsoft Passport itself and which policies you deploy to control device management and registration. A complete guide to selecting effective policies is beyond the scope of this guide, but one example reference that may be useful is [Mobile device management capabilities in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=733877).
## Implement Microsoft Passport
No configuration is necessary to use Windows Hello or Microsoft Passport on individual user devices if those users just want to protect their personal credentials. Unless the enterprise disables the feature, users have the option to use Microsoft Passport for their personal credentials, even on devices that are registered with an organizational IDP. However, when you make Microsoft Passport for Work available for users, you must add the necessary components to your infrastructure, as described earlier in the [Deployment requirements](#deployreq) section.
**How to use Azure AD**
There are three scenarios for using Microsoft Passport for Work in Azure AD–only organizations:
- **Organizations that use the version of Azure AD included with Office 365.** For these organizations, no additional work is necessary. When Windows 10 was released to general availability, Microsoft changed the behavior of the Office 365 Azure AD stack. When a user selects the option to join a work or school network (Figure 4), the device is automatically joined to the Office 365 tenant’s directory partition, a certificate is issued for the device, and it becomes eligible for Office 365 MDM if the tenant has subscribed to that feature. In addition, the user will be prompted to log on and, if MFA is enabled, to enter an MFA proof that Azure AD sends to his or her phone.
- **Organizations that use the free tier of Azure AD.** For these organizations, Microsoft has not enabled automatic domain join to Azure AD. Organizations that have signed up for the free tier have the option to enable or disable this feature, so automatic domain join won’t be enabled unless and until the organization’s administrators decide to enable it. When that feature is enabled, devices that join the Azure AD domain by using the **Connect to work or school** dialog box shown in Figure 4 will be automatically registered with Microsoft Passport for Work support, but previously joined devices will not be registered.
- **Organizations that have subscribed to Azure AD Premium have access to the full set of Azure AD MDM features.** These features include controls to manage Microsoft Passport for Work. You can set policies to disable or force the use of Microsoft Passport for Work, require the use of a TPM, and control the length and strength of PINs set on the device.
![figure 4](images/passport-fig4-join.png)
Figure 4: Joining an Office 365 organization automatically registers the device in Azure AD
**Enable device registration**
If you want to use Microsoft Passport at Work with certificates, you’ll need a device registration system. That means that you set up Configuration Manager Technical Preview, Intune, or a compatible non-Microsoft MDM system and enable it to enroll devices. This is a prerequisite step to use Microsoft Passport for Work with certificates, no matter the IDP, because the enrollment system is responsible for provisioning the devices with the necessary certificates.
**Set Microsoft Passport policies**
As of the initial release of Windows 10, you can control the following settings for the use of Microsoft Passport for Work:
- You can require that Microsoft Passport be available only on devices that have TPM security hardware, which means the device uses TPM 1.2 or TPM 2.0.
- You can enable Microsoft Passport with a hardware-preferred option, which means that keys will be generated on TPM 1.2 or TPM 2.0 when available and by software when TPM is not available.
- You can configure whether certificate-based Microsoft Passport is available to users. You do this as part of the device deployment process, not through a separately applied policy.
- You can define the complexity and length of the PIN that users generate at registration.
- You can control whether Windows Hello use is enabled in your organization.
These settings can be implemented through GPOs or through configuration service providers (CSPs) in MDM systems, so you have a familiar and flexible set of tools you can use to apply them to exactly the users you want. (For details about the Microsoft Passport for Work CSP, see [PassportForWork CSP)](http://go.microsoft.com/fwlink/p/?LinkId=733876).
## Roadmap
The speed at which Universal Windows apps and services evolve means that the traditional design-build-test-release cycle for Windows is too slow to meet customers’ needs. As part of the release of Windows 10, Microsoft is changing how it engineers, tests, and distributes Windows. Rather than large, monolithic releases every 3–5 years, the Windows engineering team is committed to smaller, more frequent releases to get new features and services into the marketplace more rapidly without sacrificing security, quality, or usability. This model has worked well in Office 365 and the Xbox ecosystem.
In the Windows 10 initial release, Microsoft supports the following Microsoft Passport and Windows Hello features:
- Biometric authentication, with fingerprint readers that use the Windows fingerprint reader framework
- Facial-recognition capability on devices that have compatible IR-capable cameras
- Microsoft Passport for personal credentials on individually owned and corporate-managed devices
- Microsoft Passport for Work support for organizations that have cloud-only Azure AD deployments
<<<<<<< HEAD
- Group Policy settings to control Microsoft Passport PIN length and complexity
In future releases of Windows 10, we plan to add support for additional features:
- Additional biometric identifier types, including iris recognition
- Key-based Microsoft Passport for Work credentials for on-premises Azure AD deployments and hybrid on-premises/Azure AD deployments
- Microsoft Passport for Work certificates issued by a trusted PKI, including smart card and virtual smart card certificates
- TPM attestation to protect keys so that a malicious user or program can’t create keys in software (because those keys won’t be TPM attested and can thus be identified as fake)
=======
- Group Policy and MDM settings to control Microsoft Passport PIN length and complexity
In the November 2015 release, Microsoft supports the following Microsoft Passport and Windows Hello features:
@ -280,7 +396,6 @@ In future releases of Windows 10, we plan to add support for additional feature
- TPM attestation to protect keys so that a malicious user or program can’t create keys in software (because those keys won’t be TPM attested and can thus be identified as fake)
>>>>>>> master
In the longer term, Microsoft will continue to improve on and expand the features of both Microsoft Passport and Windows Hello to cover additional customer requirements for manageability and security. We also are working with the FIDO Alliance and a variety of third parties to encourage adoption of Microsoft Passport by both web and LOB application developers.
 
 

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