mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 18:33:43 +00:00
New TOC for docs.microsoft.com
This commit is contained in:
Brian Lich
GitHub
@ -1,157 +0,0 @@
|
||||
# [Deploy Windows 10](index.md)
|
||||
## [What's new in Windows 10 deployment](deploy-whats-new.md)
|
||||
## [Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
|
||||
## [Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md)
|
||||
### [Upgrade Readiness architecture](upgrade-readiness-architecture.md)
|
||||
### [Upgrade Readiness requirements](upgrade-readiness-requirements.md)
|
||||
### [Upgrade Readiness release notes](upgrade-readiness-release-notes.md)
|
||||
### [Get started with Upgrade Readiness](upgrade-readiness-get-started.md)
|
||||
#### [Upgrade Readiness deployment script](upgrade-readiness-deployment-script.md)
|
||||
### [Use Upgrade Readiness to manage Windows upgrades](use-upgrade-readiness-to-manage-windows-upgrades.md)
|
||||
#### [Upgrade overview](upgrade-readiness-upgrade-overview.md)
|
||||
#### [Step 1: Identify apps](upgrade-readiness-identify-apps.md)
|
||||
#### [Step 2: Resolve issues](upgrade-readiness-resolve-issues.md)
|
||||
#### [Step 3: Deploy Windows](upgrade-readiness-deploy-windows.md)
|
||||
#### [Additional insights](upgrade-readiness-additional-insights.md)
|
||||
### [Troubleshoot Upgrade Readiness](troubleshoot-upgrade-readiness.md)
|
||||
## [Step by step guide: Configure a test lab to deploy Windows 10](windows-10-poc.md)
|
||||
### [Deploy Windows 10 in a test lab using Microsoft Deployment Toolkit](windows-10-poc-mdt.md)
|
||||
### [Deploy Windows 10 in a test lab using System Center Configuration Manager](windows-10-poc-sc-config-mgr.md)
|
||||
## [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md)
|
||||
### [Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
|
||||
#### [Key features in MDT](key-features-in-mdt.md)
|
||||
#### [MDT Lite Touch components](mdt-lite-touch-components.md)
|
||||
#### [Prepare for deployment with MDT](prepare-for-windows-deployment-with-mdt.md)
|
||||
### [Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
|
||||
### [Deploy a Windows 10 image using MDT](deploy-a-windows-10-image-using-mdt.md)
|
||||
### [Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-10-deployment.md)
|
||||
### [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
|
||||
### [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
|
||||
### [Perform an in-place upgrade to Windows 10 with MDT](upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md)
|
||||
### [Configure MDT settings](configure-mdt-settings.md)
|
||||
#### [Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
|
||||
#### [Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
#### [Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
|
||||
#### [Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
|
||||
#### [Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
|
||||
#### [Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
|
||||
#### [Use web services in MDT](use-web-services-in-mdt.md)
|
||||
#### [Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
|
||||
## [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](deploy-windows-10-with-system-center-2012-r2-configuration-manager.md)
|
||||
### [Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
### [Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
### [Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
### [Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
|
||||
### [Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
|
||||
### [Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
|
||||
### [Create a task sequence with Configuration Manager and MDT](create-a-task-sequence-with-configuration-manager-and-mdt.md)
|
||||
### [Finalize the operating system configuration for Windows 10 deployment with Configuration Manager](finalize-the-os-configuration-for-windows-10-deployment-with-configuration-manager.md)
|
||||
### [Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
|
||||
### [Monitor the Windows 10 deployment with Configuration Manager](monitor-windows-10-deployment-with-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)
|
||||
### [Perform an in-place upgrade to Windows 10 using Configuration Manager](upgrade-to-windows-10-with-system-center-configuraton-manager.md)
|
||||
## [Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md)
|
||||
## [Convert MBR partition to GPT](mbr-to-gpt.md)
|
||||
## [Configure a PXE server to load Windows PE](configure-a-pxe-server-to-load-windows-pe.md)
|
||||
## [Windows 10 upgrade paths](windows-10-upgrade-paths.md)
|
||||
## [Windows 10 edition upgrade](windows-10-edition-upgrades.md)
|
||||
## [Deploy Windows To Go in your organization](deploy-windows-to-go.md)
|
||||
## [Upgrade a Windows Phone 8.1 to Windows 10 Mobile with Mobile Device Management](upgrade-windows-phone-8-1-to-10.md)
|
||||
## [Sideload apps in Windows 10](sideload-apps-in-windows-10.md)
|
||||
## [Volume Activation [client]](volume-activation-windows-10.md)
|
||||
### [Plan for volume activation [client]](plan-for-volume-activation-client.md)
|
||||
### [Activate using Key Management Service [client]](activate-using-key-management-service-vamt.md)
|
||||
### [Activate using Active Directory-based activation [client]](activate-using-active-directory-based-activation-client.md)
|
||||
### [Activate clients running Windows 10](activate-windows-10-clients-vamt.md)
|
||||
### [Monitor activation [client]](monitor-activation-client.md)
|
||||
### [Use the Volume Activation Management Tool [client]](use-the-volume-activation-management-tool-client.md)
|
||||
### [Appendix: Information sent to Microsoft during activation [client]](appendix-information-sent-to-microsoft-during-activation-client.md)
|
||||
## [Windows 10 Enterprise E3 in CSP Overview](windows-10-enterprise-e3-overview.md)
|
||||
## [Windows 10 deployment tools reference](windows-10-deployment-tools-reference.md)
|
||||
### [Windows 10 deployment tools](windows-deployment-scenarios-and-tools.md)
|
||||
### [Windows ADK for Windows 10 scenarios for IT Pros](windows-adk-scenarios-for-it-pros.md)
|
||||
### [Volume Activation Management Tool (VAMT) Technical Reference](volume-activation-management-tool.md)
|
||||
#### [Introduction to VAMT](introduction-vamt.md)
|
||||
#### [Active Directory-Based Activation Overview](active-directory-based-activation-overview.md)
|
||||
#### [Install and Configure VAMT](install-configure-vamt.md)
|
||||
##### [VAMT Requirements](vamt-requirements.md)
|
||||
##### [Install VAMT](install-vamt.md)
|
||||
##### [Configure Client Computers](configure-client-computers-vamt.md)
|
||||
#### [Add and Manage Products](add-manage-products-vamt.md)
|
||||
##### [Add and Remove Computers](add-remove-computers-vamt.md)
|
||||
##### [Update Product Status](update-product-status-vamt.md)
|
||||
##### [Remove Products](remove-products-vamt.md)
|
||||
#### [Manage Product Keys](manage-product-keys-vamt.md)
|
||||
##### [Add and Remove a Product Key](add-remove-product-key-vamt.md)
|
||||
##### [Install a Product Key](install-product-key-vamt.md)
|
||||
##### [Install a KMS Client Key](install-kms-client-key-vamt.md)
|
||||
#### [Manage Activations](manage-activations-vamt.md)
|
||||
##### [Perform Online Activation](online-activation-vamt.md)
|
||||
##### [Perform Proxy Activation](proxy-activation-vamt.md)
|
||||
##### [Perform KMS Activation](kms-activation-vamt.md)
|
||||
##### [Perform Local Reactivation](local-reactivation-vamt.md)
|
||||
##### [Activate an Active Directory Forest Online](activate-forest-vamt.md)
|
||||
##### [Activate by Proxy an Active Directory Forest](activate-forest-by-proxy-vamt.md)
|
||||
#### [Manage VAMT Data](manage-vamt-data.md)
|
||||
##### [Import and Export VAMT Data](import-export-vamt-data.md)
|
||||
##### [Use VAMT in Windows PowerShell](use-vamt-in-windows-powershell.md)
|
||||
#### [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
|
||||
##### [Scenario 1: Online Activation](scenario-online-activation-vamt.md)
|
||||
##### [Scenario 2: Proxy Activation](scenario-proxy-activation-vamt.md)
|
||||
##### [Scenario 3: KMS Client Activation](scenario-kms-activation-vamt.md)
|
||||
#### [VAMT Known Issues](vamt-known-issues.md)
|
||||
### [User State Migration Tool (USMT) Technical Reference](usmt-technical-reference.md)
|
||||
#### [User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
|
||||
##### [User State Migration Tool (USMT) Overview](usmt-overview.md)
|
||||
##### [Getting Started with the User State Migration Tool (USMT)](getting-started-with-the-user-state-migration-tool.md)
|
||||
##### [Windows Upgrade and Migration Considerations](windows-upgrade-and-migration-considerations.md)
|
||||
#### [User State Migration Tool (USMT) How-to topics](usmt-how-to.md)
|
||||
##### [Exclude Files and Settings](usmt-exclude-files-and-settings.md)
|
||||
##### [Extract Files from a Compressed USMT Migration Store](usmt-extract-files-from-a-compressed-migration-store.md)
|
||||
##### [Include Files and Settings](usmt-include-files-and-settings.md)
|
||||
##### [Migrate Application Settings](migrate-application-settings.md)
|
||||
##### [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md)
|
||||
##### [Migrate User Accounts](usmt-migrate-user-accounts.md)
|
||||
##### [Reroute Files and Settings](usmt-reroute-files-and-settings.md)
|
||||
##### [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
|
||||
#### [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
|
||||
##### [Common Issues](usmt-common-issues.md)
|
||||
##### [Frequently Asked Questions](usmt-faq.md)
|
||||
##### [Log Files](usmt-log-files.md)
|
||||
##### [Return Codes](usmt-return-codes.md)
|
||||
##### [USMT Resources](usmt-resources.md)
|
||||
#### [User State Migration Toolkit (USMT) Reference](usmt-reference.md)
|
||||
##### [USMT Requirements](usmt-requirements.md)
|
||||
##### [USMT Best Practices](usmt-best-practices.md)
|
||||
##### [How USMT Works](usmt-how-it-works.md)
|
||||
##### [Plan Your Migration](usmt-plan-your-migration.md)
|
||||
###### [Common Migration Scenarios](usmt-common-migration-scenarios.md)
|
||||
###### [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
|
||||
###### [Choose a Migration Store Type](usmt-choose-migration-store-type.md)
|
||||
####### [Migration Store Types Overview](migration-store-types-overview.md)
|
||||
####### [Estimate Migration Store Size](usmt-estimate-migration-store-size.md)
|
||||
####### [Hard-Link Migration Store](usmt-hard-link-migration-store.md)
|
||||
####### [Migration Store Encryption](usmt-migration-store-encryption.md)
|
||||
###### [Determine What to Migrate](usmt-determine-what-to-migrate.md)
|
||||
####### [Identify Users](usmt-identify-users.md)
|
||||
####### [Identify Applications Settings](usmt-identify-application-settings.md)
|
||||
####### [Identify Operating System Settings](usmt-identify-operating-system-settings.md)
|
||||
####### [Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)
|
||||
###### [Test Your Migration](usmt-test-your-migration.md)
|
||||
##### [User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)
|
||||
###### [ScanState Syntax](usmt-scanstate-syntax.md)
|
||||
###### [LoadState Syntax](usmt-loadstate-syntax.md)
|
||||
###### [UsmtUtils Syntax](usmt-utilities.md)
|
||||
##### [USMT XML Reference](usmt-xml-reference.md)
|
||||
###### [Understanding Migration XML Files](understanding-migration-xml-files.md)
|
||||
###### [Config.xml File](usmt-configxml-file.md)
|
||||
###### [Customize USMT XML Files](usmt-customize-xml-files.md)
|
||||
###### [Custom XML Examples](usmt-custom-xml-examples.md)
|
||||
###### [Conflicts and Precedence](usmt-conflicts-and-precedence.md)
|
||||
###### [General Conventions](usmt-general-conventions.md)
|
||||
###### [XML File Requirements](xml-file-requirements.md)
|
||||
###### [Recognized Environment Variables](usmt-recognized-environment-variables.md)
|
||||
###### [XML Elements Library](usmt-xml-elements-library.md)
|
||||
##### [Offline Migration Reference](offline-migration-reference.md)
|
||||
## [Change history for Deploy Windows 10](change-history-for-deploy-windows-10.md)
|
||||
@ -1,51 +0,0 @@
|
||||
---
|
||||
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.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. 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.
|
||||
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.
|
||||
12. When the CID collection process is complete, VAMT displays a **Volume Activation Management Tool** message that shows how many confirmation IDs were successfully acquired, and the name of the file to which the IDs were saved. Click **OK** to close the message.
|
||||
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)
|
||||
@ -1,45 +0,0 @@
|
||||
---
|
||||
title: Activate an Active Directory Forest Online (Windows 10)
|
||||
description: Activate an Active Directory Forest Online
|
||||
ms.assetid: 9b5bc193-799b-4aa5-9d3e-0e495f7195d3
|
||||
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)
|
||||
@ -1,97 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: vamt, volume activation, activation, windows activation
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: activation
|
||||
author: greg-lindsay
|
||||
localizationpriority: high
|
||||
---
|
||||
|
||||
# Activate using Active Directory-based activation
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 8.1
|
||||
- Windows 8
|
||||
- Windows 7
|
||||
- Windows Server 2012 R2
|
||||
- Windows Server 2012
|
||||
- Windows Server 2008 R2
|
||||
|
||||
**Looking for retail activation?**
|
||||
- [Get Help Activating Microsoft Windows](https://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 or Windows Server 2012 R2, 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, or Windows Server 2012 R2 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.
|
||||
The process proceeds as follows:
|
||||
1. Perform one of the following tasks:
|
||||
- Install the Volume Activation Services server role on a domain controller running Windows Server 2012 R2, and add a KMS host key by using the Volume Activation Tools Wizard.
|
||||
- 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.
|
||||
|
||||
|
||||
|
||||
**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, 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.
|
||||
When a reactivation event occurs, the client queries AD DS for the activation object. Client computers examine the activation object and compare it to the local edition as defined by the GVLK. If the object and GVLK match, reactivation occurs. If the AD DS object cannot be retrieved, client computers use KMS activation. If the computer is removed from the domain, when the computer or the Software Protection service is restarted, the operating system will change the status from activated to not activated, and the computer will try to activate with KMS.
|
||||
## Step-by-step configuration: Active Directory-based activation
|
||||
**Note**
|
||||
You must be a member of the local Administrators group on all computers mentioned in these steps. You also need to be a member of the Enterprise Administrators group, because setting up Active Directory-based activation changes forest-wide settings.
|
||||
**To configure Active Directory-based activation on Windows Server 2012 R2, complete the following steps:**
|
||||
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.
|
||||
|
||||
|
||||
|
||||
**Figure 11**. Adding the Volume Activation Services role
|
||||
|
||||
4. Click the link to launch the Volume Activation Tools (Figure 12).
|
||||
|
||||
|
||||
|
||||
**Figure 12**. Launching the Volume Activation Tools
|
||||
|
||||
5. Select the **Active Directory-Based Activation** option (Figure 13).
|
||||
|
||||
|
||||
|
||||
**Figure 13**. Selecting Active Directory-Based Activation
|
||||
|
||||
6. Enter your KMS host key and (optionally) a display name (Figure 14).
|
||||
|
||||
|
||||
|
||||
**Figure 14**. Entering your KMS host key
|
||||
|
||||
7. Activate your KMS host key by phone or online (Figure 15).
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
3. If the computer is not joined to your domain, join it to the domain.
|
||||
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 **slmgr.vbs /dlv** command also indicates whether KMS has been used.
|
||||
|
||||
## See also
|
||||
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
|
||||
@ -1,141 +0,0 @@
|
||||
---
|
||||
title: Activate using Key Management Service (Windows 10)
|
||||
ms.assetid: f2417bfe-7d25-4e82-bc07-de316caa8dac
|
||||
description:
|
||||
keywords: vamt, volume activation, activation, windows activation
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: activation
|
||||
author: jdeckerMS
|
||||
localizationpriority: high
|
||||
---
|
||||
|
||||
# Activate using Key Management Service
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 8.1
|
||||
- Windows 8
|
||||
- Windows 7
|
||||
- Windows Server 2012 R2
|
||||
- Windows Server 2012
|
||||
- Windows Server 2008 R2
|
||||
|
||||
**Looking for retail activation?**
|
||||
|
||||
- [Get Help Activating Microsoft Windows](https://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
|
||||
|
||||
Check out [Windows 10 Volume Activation Tips](https://blogs.technet.microsoft.com/askcore/2015/09/15/windows-10-volume-activation-tips/).
|
||||
|
||||
## 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 <KmsKey>**.
|
||||
- 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](https://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](https://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.
|
||||
|
||||
|
||||
|
||||
**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).
|
||||
|
||||
|
||||
|
||||
**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).
|
||||
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.
|
||||
|
||||
|
||||
|
||||
**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).
|
||||
|
||||
|
||||
|
||||
**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).
|
||||
|
||||
|
||||
|
||||
**Figure 8**. Activating the software
|
||||
|
||||
The KMS key can be activated online or by phone. See Figure 9.
|
||||
|
||||
|
||||
|
||||
**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](https://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](https://go.microsoft.com/fwlink/p/?LinkId=618265) and [Update that enables Windows 7 and Windows Server 2008 R2 KMS hosts to activate Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=626590).
|
||||
|
||||
## See also
|
||||
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
|
||||
|
||||
|
||||
@ -1,122 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: vamt, volume activation, activation, windows activation
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: activation
|
||||
author: jdeckerMS
|
||||
localizationpriority: high
|
||||
---
|
||||
|
||||
# Activate clients running Windows 10
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 8.1
|
||||
- Windows 8
|
||||
- Windows 7
|
||||
- Windows Server 2012 R2
|
||||
- Windows Server 2012
|
||||
- Windows Server 2008 R2
|
||||
|
||||
**Looking for retail activation?**
|
||||
|
||||
- [Get Help Activating Microsoft Windows](https://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](https://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.
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
|
||||
|
||||
|
||||
**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)
|
||||
|
||||
|
||||
@ -1,27 +0,0 @@
|
||||
---
|
||||
title: Active Directory-Based Activation Overview (Windows 10)
|
||||
description: Active Directory-Based Activation Overview
|
||||
ms.assetid: c1dac3bd-6a86-4c45-83dd-421e63a398c0
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: activation
|
||||
author: greg-lindsay
|
||||
---
|
||||
|
||||
# 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](https://go.microsoft.com/fwlink/p/?LinkId=246565)
|
||||
- [How to Proxy Activate an Active Directory Forest](https://go.microsoft.com/fwlink/p/?LinkId=246566)
|
||||
|
||||
|
||||
@ -1,76 +0,0 @@
|
||||
---
|
||||
title: Add a Windows 10 operating system image using Configuration Manager (Windows 10)
|
||||
description: Operating system images are typically the production image used for deployment throughout the organization.
|
||||
ms.assetid: 77f769cc-1a47-4f36-8082-201cd77b8d3b
|
||||
keywords: image, deploy, distribute
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Add a Windows 10 operating system image using Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
Operating system images are typically the production image used for deployment throughout the organization. This topic shows you how to add a Windows 10 operating system image created with Microsoft System Center 2012 R2 Configuration Manager, and how to distribute the image to a distribution point.
|
||||
|
||||
For the purposes of this topic, we will use CM01, a machine running Windows Server 2012 R2 Standard, as the distribution point. CM01 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). Our image is named REFW10-X64-001.wim. For details on building this image, please see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
|
||||
|
||||
1. Using File Explorer, in the **E:\\Sources\\OSD\\OS** folder, create a subfolder named **Windows 10 Enterprise x64 RTM**.
|
||||
|
||||
2. Copy the REFW10-X64-001.wim file to the **E:\\Sources\\OSD\\OS\\Windows 10 Enterprise x64 RTM** folder.
|
||||
|
||||
|
||||
|
||||
Figure 17. The Windows 10 image copied to the Sources folder structure.
|
||||
|
||||
3. Using the Configuration Manager Console, in the Software Library workspace, right-click **Operating System Images**, and select **Add Operating System Image**.
|
||||
|
||||
4. On the **Data Source** page, in the **Path:** text box, browse to \\\\CM01\\Sources$\\OSD\\OS\\Windows 10 Enterprise x64 RTM\\REFW10-X64-001.wim and click **Next**.
|
||||
|
||||
5. On the **General** page, assign the name Windows 10 Enterprise x64 RTM and click **Next** twice, and then click **Close**.
|
||||
|
||||
6. Distribute the operating system image to the CM01 distribution point by right-clicking the Windows 10 Enterprise x64 RTM operating system image and selecting **Distribute Content**.
|
||||
|
||||
7. In the Distribute Content Wizard, add the CM01 distribution point.
|
||||
|
||||
8. View the content status for the Windows 10 Enterprise x64 RTM package. Do not continue until the distribution is completed. You also can review the E:\\Program Files\\Microsoft Configuration Manager\\Logs\\distmgr.log file and look for the **STATMSG: ID=2301** line.
|
||||
|
||||
|
||||
|
||||
Figure 18. The distributed Windows 10 Enterprise x64 RTM package.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
|
||||
[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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,109 +0,0 @@
|
||||
---
|
||||
title: Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager (Windows 10)
|
||||
description: In this topic, you will learn how to configure the Windows Preinstallation Environment (Windows PE) to include the network drivers required to connect to the deployment share and the storage drivers required to see the local storage on machines.
|
||||
ms.assetid: 97b3ea46-28d9-407e-8c42-ded2e45e8d5c
|
||||
keywords: deploy, task sequence
|
||||
ms.prod: w10
|
||||
localizationpriority: high
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
In this topic, you will learn how to configure the Windows Preinstallation Environment (Windows PE) to include the network drivers required to connect to the deployment share and the storage drivers required to see the local storage on machines. Even though the Windows PE boot image and the Windows 10 operating system contain many out-of-the-box drivers, it is likely you will have to add new or updated drivers to support all your hardware. In this section, you import drivers for both Windows PE and the full Windows 10 operating system.
|
||||
|
||||
For the purposes of this topic, we will use CM01, a machine running Windows Server 2012 R2 Standard 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).
|
||||
|
||||
## <a href="" id="sec01"></a>Add drivers for Windows PE
|
||||
|
||||
|
||||
This section will show you how to import some network and storage drivers for Windows PE. This section assumes you have downloaded some drivers to the E:\\Sources\\OSD\\DriverSources\\WinPE x64 folder on CM01.
|
||||
|
||||
1. On CM01, using the Configuration Manager Console, in the Software Library workspace, right-click the **Drivers** node and select **Import Driver**.
|
||||
|
||||
2. In the Import New Driver Wizard, on the **Specify a location to import driver** page, below the Import all drivers in the following network path (UNC) option, browse to the **\\\\CM01\\Sources$\\OSD\\DriverSources\\WinPE x64** folder and click **Next**.
|
||||
|
||||
3. On the **Specify the details for the imported driver** page, click **Categories**, create a category named **WinPE x64**, and then click **Next**.
|
||||
|
||||
4. On the **Select the packages to add the imported driver** page, click **Next**.
|
||||
|
||||
5. On the **Select drivers to include in the boot image** page, select the **Zero Touch WinPE x64** boot image. Also select the **Update distribution points when finished** check box, and click **Next** twice.
|
||||
|
||||
|
||||
|
||||
*Figure 21. Add drivers to Windows PE*
|
||||
|
||||
>[!NOTE]
|
||||
>The Updating Boot Image part of the wizard will appear to hang when displaying Done. It will complete in a minute or two.
|
||||
|
||||
|
||||
## <a href="" id="sec02"></a>Add drivers for Windows 10
|
||||
|
||||
|
||||
This section illustrates how to add drivers for Windows 10 through an example in which you want to import Windows 10 drivers for the HP EliteBook 8560w model. For the purposes of this section, we assume that you have downloaded the Windows 10 drivers for the HP EliteBook 8560w model and copied them to the E:\\Sources\\OSD\\DriverSources\\Windows 10 x64\\HP EliteBook 8560w folder on CM01.
|
||||
|
||||
1. On CM01, using the Configuration Manager Console, right-click the **Drivers** folder and select **Import Driver**.
|
||||
|
||||
2. In the Import New Driver Wizard, on the **Specify a location to import driver** page, below the Import all drivers in the following network path (UNC) option, browse to the **\\\\CM01\\Sources$\\OSD\\DriverSources\\Windows 10 x64\\HP EliteBook 8560w** folder and click **Next**.
|
||||
|
||||
3. On the **Specify the details for the imported driver** page, click **Categories**, create a category named Windows 10 x64 - HP EliteBook 8560w, and then click **Next**.
|
||||
|
||||
|
||||
|
||||
*Figure 22. Create driver categories*
|
||||
|
||||
4. On the **Select the packages to add the imported driver** page, click **New Package**, use the following settings for the package, and then click **Next**:
|
||||
|
||||
* Name: Windows 10 x64 - HP EliteBook 8560w
|
||||
|
||||
* Path: \\\\CM01\\Sources$\\OSD\\DriverPackages\\Windows 10 x64\\HP EliteBook 8560w
|
||||
|
||||
>[!NOTE]
|
||||
>The package path does not yet exist, so you have to type it in. The wizard will create the new package in that folder.
|
||||
|
||||
|
||||
5. On the **Select drivers to include in the boot image** page, do not select anything, and click **Next** twice. After the package has been created, click **Close**.
|
||||
|
||||
>[!NOTE]
|
||||
>If you want to monitor the driver import process more closely, you can open the SMSProv.log file during driver import.
|
||||
|
||||
|
||||
|
||||
*Figure 23. Drivers imported and a new driver package created*
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
|
||||
|
||||
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
|
||||
|
||||
[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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,25 +0,0 @@
|
||||
---
|
||||
title: Add and Manage Products (Windows 10)
|
||||
description: Add and Manage Products
|
||||
ms.assetid: a48fbc23-917d-40f7-985c-e49702c05e51
|
||||
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. |
|
||||
|[Update Product Status](update-product-status-vamt.md) |Describes how to update the status of product license. |
|
||||
|[Remove Products](remove-products-vamt.md) |Describes how to remove a product from the product list. |
|
||||
|
||||
|
||||
|
||||
@ -1,58 +0,0 @@
|
||||
---
|
||||
title: Add and Remove Computers (Windows 10)
|
||||
description: Add and Remove Computers
|
||||
ms.assetid: cb6f3a78-ece0-4dc7-b086-cb003d82cd52
|
||||
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.
|
||||
- To search for computers in an Active Directory domain, click **Search for computers in the Active Directory**, then under **Domain Filter Criteria**, in the list of domain names click the name of the domain 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 within the domain. This filter supports the asterisk (\*) wildcard. For example, typing "a\*" will display only computer names that start with the letter "a".
|
||||
- To search by individual computer name or IP address, click **Manually enter name or IP address**, then enter the full name or IP address in the **One or more computer names or IP addresses separated by commas** text box. Separate multiple entries with a comma. Note that VAMT supports both IPv4 and IPV6 addressing.
|
||||
- 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 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 within 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 provided. VAMT will validate only the LDAP query syntax, but will otherwise run the query without further checks.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
- 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.
|
||||
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)
|
||||
|
||||
|
||||
@ -1,34 +0,0 @@
|
||||
---
|
||||
title: Add and Remove a Product Key (Windows 10)
|
||||
description: Add and Remove a Product Key
|
||||
ms.assetid: feac32bb-fb96-4802-81b8-c69220dcfcce
|
||||
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)
|
||||
@ -1,65 +0,0 @@
|
||||
---
|
||||
title: Appendix Information sent to Microsoft during activation (Windows 10)
|
||||
ms.assetid: 4bfff495-07d0-4385-86e3-7a077cbd64b8
|
||||
description:
|
||||
keywords: vamt, volume activation, activation, windows activation
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: activation
|
||||
author: jdeckerMS
|
||||
localizationpriority: medium
|
||||
---
|
||||
# Appendix: Information sent to Microsoft during activation
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 8.1
|
||||
- Windows 8
|
||||
- Windows 7
|
||||
- Windows Server 2012 R2
|
||||
- Windows Server 2012
|
||||
- Windows Server 2008 R2
|
||||
|
||||
**Looking for retail activation?**
|
||||
|
||||
- [Get Help Activating Microsoft Windows](https://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
|
||||
- Version information for the operating system and software
|
||||
- Region and language settings
|
||||
- A unique number called a *globally unique identifier*, which is assigned to your computer
|
||||
- Product key (hashed) and product ID
|
||||
- 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](https://go.microsoft.com/fwlink/p/?LinkId=619879).
|
||||
|
||||
## See also
|
||||
|
||||
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
|
||||
|
||||
|
||||
@ -1,7 +0,0 @@
|
||||
---
|
||||
title: Assign applications using roles in MDT (Windows 10)
|
||||
redirect_url: assign-applications-using-roles-in-mdt
|
||||
---
|
||||
|
||||
|
||||
|
||||
@ -1,132 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: settings, database, deploy
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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. 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. The Standard PC role added to PC00075 (having ID 1 in the database).
|
||||
|
||||
## <a href="" id="sec03"></a>Verify database access in the MDT simulation environment
|
||||
|
||||
When the database is populated, you can use the MDT simulation environment to simulate a deployment. The applications are not installed, but you can see which applications would be installed if you did a full deployment of the computer.
|
||||
1. On PC0001, log on as **CONTOSO\\MDT\_BA**.
|
||||
2. Modify the C:\\MDT\\CustomSettings.ini file to look like the following:
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=CSettings, CRoles, RApplications, Default
|
||||
[Default]
|
||||
_SMSTSORGNAME=Contoso
|
||||
OSInstall=Y
|
||||
UserDataLocation=AUTO
|
||||
TimeZoneName=Pacific Standard Time
|
||||
AdminPassword=P@ssw0rd
|
||||
JoinDomain=contoso.com
|
||||
DomainAdmin=CONTOSO\MDT_JD
|
||||
DomainAdminPassword=P@ssw0rd
|
||||
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
|
||||
SLShare=\\MDT01\Logs$
|
||||
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
|
||||
USMTMigFiles001=MigApp.xml
|
||||
USMTMigFiles002=MigUser.xml
|
||||
HideShell=YES
|
||||
ApplyGPOPack=NO
|
||||
SkipAppsOnUpgrade=NO
|
||||
SkipAdminPassword=YES
|
||||
SkipProductKey=YES
|
||||
SkipComputerName=NO
|
||||
SkipDomainMembership=YES
|
||||
SkipUserData=NO
|
||||
SkipLocaleSelection=YES
|
||||
SkipTaskSequence=NO
|
||||
SkipTimeZone=YES
|
||||
SkipApplications=NO
|
||||
SkipBitLocker=YES
|
||||
SkipSummary=YES
|
||||
SkipCapture=YES
|
||||
SkipFinalSummary=NO
|
||||
EventService=http://MDT01:9800
|
||||
[CSettings]
|
||||
SQLServer=MDT01
|
||||
Instance=SQLEXPRESS
|
||||
Database=MDT
|
||||
Netlib=DBNMPNTW
|
||||
SQLShare=Logs$
|
||||
Table=ComputerSettings
|
||||
Parameters=UUID, AssetTag, SerialNumber, MacAddress
|
||||
ParameterCondition=OR
|
||||
[CRoles]
|
||||
SQLServer=MDT01
|
||||
Instance=SQLEXPRESS
|
||||
Database=MDT
|
||||
Netlib=DBNMPNTW
|
||||
SQLShare=Logs$
|
||||
Table=ComputerRoles
|
||||
Parameters=UUID, AssetTag, SerialNumber, MacAddress
|
||||
ParameterCondition=OR
|
||||
[RApplications]
|
||||
SQLServer=MDT01
|
||||
Instance=SQLEXPRESS
|
||||
Database=MDT
|
||||
Netlib=DBNMPNTW
|
||||
SQLShare=Logs$
|
||||
Table=RoleApplications
|
||||
Parameters=Role
|
||||
Order=Sequence
|
||||
```
|
||||
|
||||
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands. Press **Enter** after each command:
|
||||
|
||||
``` syntax
|
||||
Set-Location C:\MDT
|
||||
.\Gather.ps1
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
Figure 14. ZTIGather.log displaying the application GUID belonging to the Adobe Reader XI application that would have been installed if you deployed this machine.
|
||||
|
||||
## Related topics
|
||||
|
||||
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
|
||||
<BR>[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
<BR>[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
|
||||
<BR>[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
|
||||
<BR>[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
|
||||
<BR>[Use web services in MDT](use-web-services-in-mdt.md)
|
||||
<BR>[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
|
||||
|
||||
|
||||
@ -1,224 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: replication, replicate, deploy, configure, remote
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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. The machines used in this topic.
|
||||
|
||||
## <a href="" id="sec01"></a>Replicate deployment shares
|
||||
|
||||
Replicating the content between MDT01 (New York) and MDT02 (Stockholm) can be done in a number of different ways. The most common content replication solutions with Microsoft Deployment Toolkit (MDT) use either the Linked Deployment Shares (LDS) feature or Distributed File System Replication (DFS-R). Some organizations have used a simple robocopy script for replication of the content.
|
||||
|
||||
**Note**
|
||||
Robocopy has options that allow for synchronization between folders. It has a simple reporting function; it supports transmission retry; and, by default, it will only copy/remove files from the source that are newer than files on the target.
|
||||
|
||||
### Linked deployment shares in MDT
|
||||
|
||||
LDS is a built-in feature in MDT for replicating content. However, LDS works best with strong connections such as LAN connections with low latency. For most WAN links, DFS-R is the better option.
|
||||
|
||||
### Why DFS-R is a better option
|
||||
|
||||
DFS-R is not only very fast and reliable, but it also offers central monitoring, bandwidth control, and a great delta replication engine. DFS-R will work equally well whether you have 2 sites or 90. When using DFS-R for MDT, we recommend running your deployment servers on Windows Server 2008 R2 or higher. From that version on, you can configure the replication target(s) as read-only, which is exactly what you want for MDT. This way, you can have your master deployment share centralized and replicate out changes as they happen. DFS-R will quickly pick up changes at the central deployment share in MDT01 and replicate the delta changes to MDT02.
|
||||
|
||||
## <a href="" id="sec02"></a>Set up Distributed File System Replication (DFS-R) for replication
|
||||
|
||||
Setting up DFS-R for replication is a quick and straightforward process. You prepare the deployment servers and then create a replication group. To complete the setup, you configure some replication settings.
|
||||
|
||||
### Prepare MDT01 for replication
|
||||
1. On MDT01, using Server Manager, click **Add roles and features**.
|
||||
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
|
||||
3. On the **Select destination server** page, select **MDT01.contoso.com** and click **Next**.
|
||||
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
|
||||
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
|
||||
|
||||
|
||||
|
||||
Figure 2. Adding the DFS Replication role to MDT01.
|
||||
|
||||
6. On the **Select features** page, accept the default settings, and click **Next**.
|
||||
7. On the **Confirm installation selections** page, click **Install**.
|
||||
8. On the **Installation progress** page, click **Close**.
|
||||
|
||||
### Prepare MDT02 for replication
|
||||
|
||||
1. On MDT02, using Server Manager, click **Add roles and features**.
|
||||
2. On the **Select installation type** page, select **Role-based or feature-based installation**.
|
||||
3. On the **Select destination server** page, select **MDT02.contoso.com** and click **Next**.
|
||||
4. On the **Select server roles** page, expand **File and Storage Services (Installed)** and expand **File and iSCSI Services (Installed)**.
|
||||
5. In the **Roles** list, select **DFS Replication**. In the **Add Roles and Features Wizard** dialog box, select **Add Features**, and then click **Next**.
|
||||
6. On the **Select features** page, accept the default settings, and click **Next**.
|
||||
7. On the **Confirm installation selections** page, click **Install**.
|
||||
8. On the **Installation progress** page, click **Close**.
|
||||
|
||||
### Create the MDTProduction folder on MDT02
|
||||
|
||||
1. On MDT02, using File Explorer, create the **E:\\MDTProduction** folder.
|
||||
2. Share the **E:\\MDTProduction** folder as **MDTProduction$**. Use the default permissions.
|
||||
|
||||
|
||||
|
||||
Figure 3. Sharing the **E:\\MDTProduction folder** on MDT02.
|
||||
|
||||
### Configure the deployment share
|
||||
|
||||
When you have multiple deployment servers sharing the same content, you need to configure the Bootstrap.ini file with information about which server to connect to based on where the client is located. In MDT, that can be done by using the DefaultGateway property.
|
||||
1. On MDT01, using Notepad, navigate to the **E:\\MDTProduction\\Control** folder and modify the Boostrap.ini file to look like this:
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=DefaultGateway, Default
|
||||
[DefaultGateway]
|
||||
192.168.1.1=NewYork
|
||||
192.168.2.1=Stockholm
|
||||
[NewYork]
|
||||
DeployRoot=\\MDT01\MDTProduction$
|
||||
[Stockholm]
|
||||
DeployRoot=\\MDT02\MDTProduction$
|
||||
[Default]
|
||||
UserDomain=CONTOSO
|
||||
UserID=MDT_BA
|
||||
SkipBDDWelcome=YES
|
||||
```
|
||||
**Note**
|
||||
The DeployRoot value needs to go into the Bootstrap.ini file, but you can use the same logic in the CustomSettings.ini file. For example, you can redirect the logs to the local deployment server (SLSHARE), or have the User State Migration Tool (USMT) migration store (UDDIR) local. To learn more about USMT, see [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md) and [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md).
|
||||
|
||||
2. Save the Bootstrap.ini file.
|
||||
3. Using the Deployment Workbench, right-click the **MDT Production** deployment share and select **Update Deployment Share**.
|
||||
|
||||
|
||||
|
||||
Figure 4. 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. Replacing the updated boot image in WDS.
|
||||
|
||||
6. Browse and select the **E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim** boot image, and then complete Replace Boot Image Wizard using the default settings.
|
||||
## <a href="" id="sec03"></a>Replicate the content
|
||||
Once the MDT01 and MDT02 servers are prepared, you are ready to configure the actual replication.
|
||||
### Create the replication group
|
||||
1. On MDT01, using DFS Management, right-click **Replication**, and select **New Replication Group**.
|
||||
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. 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. 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
|
||||
1. On MDT01, using DFS Management, expand **Replication** and then select **MDTProduction**.
|
||||
2. In the middle pane, right-click the **MDT01** member and select **Properties**.
|
||||
3. On the **MDT01 (MDTProduction) Properties** page, configure the following and then click **OK**:
|
||||
1. In the **Staging** tab, set the quota to **20480 MB**.
|
||||
2. In the **Advanced** tab, set the quota to **8192 MB**.
|
||||
In this scenario the size of the deployment share is known, but you might need to change the values for your environment. A good rule of thumb is to get the size of the 16 largest files and make sure they fit in the staging area. Here is a Windows PowerShell example that calculates the size of the 16 largest files in the E:\\MDTProduction deployment share:
|
||||
|
||||
``` syntax
|
||||
(Get-ChildItem E:\MDTProduction -Recurse | Sort-Object Length -Descending | Select-Object -First 16 | Measure-Object -Property Length -Sum).Sum /1GB
|
||||
```
|
||||
|
||||
|
||||
|
||||
Figure 8. 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.
|
||||
|
||||
### Verify replication
|
||||
1. On MDT02, wait until you start to see content appear in the **E:\\MDTProduction** folder.
|
||||
2. Using DFS Management, expand **Replication**, right-click **MDTProduction**, and select **Create Diagnostics Report**.
|
||||
3. In the Diagnostics Report Wizard, on the **Type of Diagnostics Report or Test** page, select **Health report** and click **Next**.
|
||||
4. On the **Path and Name** page, accept the default settings and click **Next**.
|
||||
5. On the **Members to Include** page, accept the default settings and click **Next**.
|
||||
6. On the **Options** page, accept the default settings and click **Next**.
|
||||
7. On the **Review Settings and Create Report** page, click **Create**.
|
||||
8. Open the report in Internet Explorer, and if necessary, select the **Allow blocked content** option.
|
||||
|
||||
|
||||
|
||||
Figure 9. The DFS Replication Health Report.
|
||||
|
||||
## <a href="" id="sec04"></a>Configure Windows Deployment Services (WDS) in a remote site
|
||||
|
||||
Like you did in the previous topic for MDT01, you need to add the MDT Production Lite Touch x64 Boot image to Windows Deployment Services on MDT02. For the following steps, we assume that WDS has already been installed on MDT02.
|
||||
1. On MDT02, using the WDS console, right-click **Boot Images** and select **Add Boot Image**.
|
||||
2. Browse to the E:\\MDTProduction\\Boot\\LiteTouchPE\_x64.wim file and add the image with the default settings.
|
||||
|
||||
## <a href="" id="sec05"></a>Deploy the Windows 10 client to the remote site
|
||||
|
||||
Now you should have a solution ready for deploying the Windows 10 client to the remote site, Stockholm, connecting to the MDT Production deployment share replica on MDT02.
|
||||
|
||||
1. Create a virtual machine with the following settings:
|
||||
1. Name: PC0006
|
||||
2. Location: C:\\VMs
|
||||
3. Generation: 2
|
||||
4. Memory: 2048 MB
|
||||
5. Hard disk: 60 GB (dynamic disk)
|
||||
2. Start the PC0006 virtual machine, and press **Enter** to start the Pre-Boot Execution Environment (PXE) boot. The machine will now load the Windows PE boot image from the WDS server.
|
||||
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment Wizard using the following settings:
|
||||
1. Password: P@ssw0rd
|
||||
2. Select a task sequence to execute on this computer:
|
||||
1. Windows 10 Enterprise x64 RTM Custom Image
|
||||
2. Computer Name: PC0006
|
||||
3. Applications: Select the Install - Adobe Reader XI - x86 application
|
||||
4. The setup will now start and do the following:
|
||||
1. Install the Windows 10 Enterprise operating system.
|
||||
2. Install the added application.
|
||||
3. Update the operating system via your local Windows Server Update Services (WSUS) server.
|
||||
|
||||
## Related topics
|
||||
|
||||
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit.md)
|
||||
|
||||
[Create a Windows 10 reference image](create-a-windows-10-reference-image.md)
|
||||
|
||||
[Deploy a Windows 10 image using MDT](deploy-a-windows-10-image-using-mdt.md)
|
||||
|
||||
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-10.md)
|
||||
|
||||
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-10-computer.md)
|
||||
|
||||
[Configure MDT settings](configure-mdt-settings.md)
|
||||
|
||||
|
||||
@ -1,129 +0,0 @@
|
||||
---
|
||||
title: Change history for Deploy Windows 10 (Windows 10)
|
||||
description: This topic lists new and updated topics in the Deploy Windows 10 documentation for Windows 10 and Windows 10 Mobile.
|
||||
ms.assetid: 19C50373-6B25-4F5C-A6EF-643D36904349
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: greg-lindsay
|
||||
---
|
||||
|
||||
# Change history for Deploy Windows 10
|
||||
This topic lists new and updated topics in the [Deploy Windows 10](index.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
|
||||
|
||||
|
||||
## April 2017
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Deploy Windows 10 in a test lab using System Center Configuration Manager](windows-10-poc-sc-config-mgr.md) | Updated: The "refresh" and "replace" procedures were swapped in order so that it would not be necessary to save and restore VMs. Also a missing step was added to include the State migration point role. |
|
||||
| [Step by step guide: Configure a test lab to deploy Windows 10](windows-10-poc.md)| Updated with minor fixes. |
|
||||
| [Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md)| Updated child topics under this node to include new feature and user interface changes. |
|
||||
| [Get started with Upgrade Readiness](upgrade-readiness-get-started.md)| Added a table summarizing connection scenarios under the Enable data sharing topic. |
|
||||
|
||||
## RELEASE: Windows 10, version 1703
|
||||
The topics in this library have been updated for Windows 10, version 1703 (also known as the Creators Update). The provisioning topics have been moved to [Configure Windows 10](../configure/index.md).
|
||||
|
||||
## March 2017
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [What's new in Windows 10 deployment](deploy-whats-new.md) | New |
|
||||
| [Upgrade to Windows 10 with the Microsoft Deployment Toolkit](upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md) | Topic moved under [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md) in the table of contents and title adjusted to clarify in-place upgrade. |
|
||||
| [Upgrade to Windows 10 with System Center Configuration Manager](upgrade-to-windows-10-with-system-center-configuraton-manager.md) | Topic moved under [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](deploy-windows-10-with-system-center-2012-r2-configuration-manager.md) in the table of contents and title adjusted to clarify in-place upgrade. |
|
||||
| [Convert MBR partition to GPT](mbr-to-gpt.md) | New |
|
||||
|
||||
|
||||
## February 2017
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md) | Multiple topics updated, name changed from Upgrade Analytics to Upgrade Readiness, and other content updates. |
|
||||
| [USMT Requirements](usmt-requirements.md) | Updated: Vista support removed and other minor changes |
|
||||
| [Get started with Upgrade Analytics](upgrade-analytics-get-started.md) | Updated structure and content |
|
||||
| [Upgrade Analytics deployment script](upgrade-analytics-deployment-script.md) | Added as a separate page from get started |
|
||||
| [Use Upgrade Analytics to manage Windows upgrades](use-upgrade-analytics-to-manage-windows-upgrades.md) | Updated with links to new content and information about the target OS setting |
|
||||
| [Upgrade Analytics - Upgrade overview](upgrade-analytics-upgrade-overview.md) | New |
|
||||
| [Upgrade Analytics - Step 1: Identify important apps](upgrade-analytics-identify-apps.md) | Updated topic title and content |
|
||||
| [Upgrade Analytics - Step 2: Resolve app and driver issues](upgrade-analytics-resolve-issues.md) | New |
|
||||
| [Upgrade Analytics - Step 3: Deploy Windows](upgrade-analytics-deploy-windows.md) | New |
|
||||
| [Upgrade Analytics - Additional insights](upgrade-analytics-additional-insights.md) | New |
|
||||
|
||||
## January 2017
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Step by step guide: Configure a test lab to deploy Windows 10](windows-10-poc.md) | New |
|
||||
| [Deploy Windows 10 in a test lab using Microsoft Deployment Toolkit](windows-10-poc-mdt.md) | New |
|
||||
| [Deploy Windows 10 in a test lab using System Center Configuration Manager](windows-10-poc-sc-config-mgr.md) | New |
|
||||
| [Apply a provisioning package](provisioning-apply-package.md) | New (previously published in other topics) |
|
||||
| [Create a provisioning package for Windows 10](provisioning-create-package.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [Create a provisioning package with multivariant settings](provisioning-multivariant.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [How provisioning works in Windows 10](provisioning-how-it-works.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [Install Windows Imaging and Configuration Designer](provisioning-install-icd.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [NFC-based device provisioning](provisioning-nfc.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [Settings changed when you uninstall a provisioning package](provisioning-uninstall-package.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [Use a script to install a desktop app in provisioning packages](provisioning-script-to-install-app.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [Windows ICD command-line interface (reference)](provisioning-command-line.md) | New (previously published in Hardware Dev Center on MSDN) |
|
||||
| [Get started with Upgrade Analytics](upgrade-analytics-get-started.md) | Updated exit code table with suggested fixes, and added link to the Upgrade Analytics blog |
|
||||
| [Provision PCs with common settings for initial deployment (simple provisioning)](provision-pcs-for-initial-deployment.md) | Instructions for applying the provisioning package moved to [Apply a provisioning package](provisioning-apply-package.md) |
|
||||
| [Provision PCs with apps and certificates for initial deployments (advanced provisioning)](provision-pcs-with-apps-and-certificates.md) | Instructions for applying the provisioning package moved to [Apply a provisioning package](provisioning-apply-package.md) |
|
||||
|
||||
|
||||
## October 2016
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md) | New |
|
||||
|
||||
## September 2016
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Windows 10 Enterprise E3 in CSP Overview](windows-10-enterprise-e3-overview.md) | New |
|
||||
| [Get started with Upgrade Analytics](upgrade-analytics-get-started.md) | Updated with prerequisites for site discovery |
|
||||
| [Resolve application and driver issues](upgrade-analytics-resolve-issues.md) | Updated with app status info for Ready For Windows |
|
||||
| [Review site discovery](upgrade-analytics-review-site-discovery.md) | New |
|
||||
|
||||
## RELEASE: Windows 10, version 1607
|
||||
|
||||
The topics in this library have been updated for Windows 10, version 1607 (also known as the Anniversary Update). The following new topics have been added:
|
||||
|
||||
- [Provisioning packages for Windows 10](provisioning-packages.md)
|
||||
- [Provision PCs with apps and certificates for initial deployment](provision-pcs-with-apps-and-certificates.md)
|
||||
- [Provision PCs with common settings for initial deployment](provision-pcs-for-initial-deployment.md)
|
||||
|
||||
=======
|
||||
|
||||
## August 2016
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Windows 10 edition upgrade](windows-10-edition-upgrades.md) | Updated with reboot requirements |
|
||||
|
||||
## July 2016
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Manage Windows upgrades with Upgrade Analytics](manage-windows-upgrades-with-upgrade-analytics.md) | New |
|
||||
|
||||
## June 2016
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Configure a PXE server to load Windows PE](configure-a-pxe-server-to-load-windows-pe.md) | New |
|
||||
| [User State Migration Tool Technical Reference](usmt-technical-reference.md) | Updated support statement for Office 2016 |
|
||||
| [Windows 10 upgrade paths](windows-10-upgrade-paths.md) | New |
|
||||
|
||||
## May 2016
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Upgrade a Windows Phone 8.1 to Windows 10 Mobile with Mobile Device Management](upgrade-windows-phone-8-1-to-10.md) | New |
|
||||
|
||||
## December 2015
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Activate using Key Management Service](activate-using-key-management-service-vamt.md) | Updated |
|
||||
| [Windows 10 edition upgrade](windows-10-edition-upgrades.md) | Updated |
|
||||
|
||||
## November 2015
|
||||
| New or changed topic | Description |
|
||||
|----------------------|-------------|
|
||||
| [Windows 10 edition upgrade](windows-10-edition-upgrades.md) | New |
|
||||
|
||||
## Related topics
|
||||
- [Change history for What's new in Windows 10](../whats-new/change-history-for-what-s-new-in-windows-10.md)
|
||||
- [Change history for Plan for Windows 10 deployment](../plan/change-history-for-plan-for-windows-10-deployment.md)
|
||||
- [Change history for Keep Windows 10 secure](../keep-secure/change-history-for-keep-windows-10-secure.md)
|
||||
- [Change history for Manage and update Windows 10](../manage/change-history-for-manage-and-update-windows-10.md)
|
||||
@ -1,188 +0,0 @@
|
||||
---
|
||||
title: Configure a PXE server to load Windows PE (Windows 10)
|
||||
description: This topic describes how to configure a PXE server to load Windows PE so that it can be used with an image file to install Windows 10 from the network.
|
||||
keywords: upgrade, update, windows, windows 10, pxe, WinPE, image, wim
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.sitesec: library
|
||||
ms.pagetype: deploy
|
||||
author: greg-lindsay
|
||||
---
|
||||
|
||||
# Configure a PXE server to load Windows PE
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
## Summary
|
||||
|
||||
This walkthrough describes how to configure a PXE server to load Windows PE by booting a client computer from the network. Using the Windows PE tools and a Windows 10 image file, you can install Windows 10 from the network.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A deployment computer: A computer with the [Windows Assessment and Deployment Kit](https://go.microsoft.com/fwlink/p/?LinkId=526803) (Windows ADK) installed.
|
||||
- A DHCP server: A DHCP server or DHCP proxy configured to respond to PXE client requests is required.
|
||||
- A PXE server: A server running the TFTP service that can host Windows PE boot files that the client will download.
|
||||
- A file server: A server hosting a network file share.
|
||||
|
||||
All four of the roles specified above can be hosted on the same computer or each can be on a separate computer.
|
||||
|
||||
## Step 1: Copy Windows PE source files
|
||||
|
||||
1. On the deployment computer, click **Start**, and type **deployment**.
|
||||
|
||||
2. Right-click **Deployment and Imaging Tools Environment** and then click **Run as administrator**. The Deployment and Imaging Tools Environment shortcut opens a Command Prompt window and automatically sets environment variables to point to all the necessary tools.
|
||||
|
||||
3. Run the following command to copy the base Windows PE files into a new folder. The script requires two arguments: hardware architecture and destination location. The value of **<architecture>** can be **x86**, **amd64**, or **arm** and **<destination>** is a path to a local directory. If the directory does not already exist, it will be created.
|
||||
|
||||
```
|
||||
copype.cmd <architecture> <destination>
|
||||
```
|
||||
|
||||
For example, the following command copies **amd64** architecture files to the **C:\winpe_amd64** directory:
|
||||
|
||||
```
|
||||
copype.cmd amd64 C:\winpe_amd64
|
||||
```
|
||||
|
||||
The script creates the destination directory structure and copies all the necessary files for that architecture. In the previous example, the following directories are created:
|
||||
|
||||
```
|
||||
C:\winpe_amd64
|
||||
C:\winpe_amd64\fwfiles
|
||||
C:\winpe_amd64\media
|
||||
C:\winpe_amd64\mount
|
||||
```
|
||||
4. Mount the base Windows PE image (winpe.wim) to the \mount directory using the DISM tool. Mounting an image file unpacks the file contents into a folder so that you can make changes directly or by using tools such as DISM. See the following example.
|
||||
|
||||
```
|
||||
Dism /mount-image /imagefile:c:\winpe_amd64\media\sources\boot.wim /index:1 /mountdir:C:\winpe_amd64\mount
|
||||
```
|
||||
Verify that "The operation completed successfully" is displayed. Note: To view currently mounted images, type **dism /get-MountedWiminfo**.
|
||||
|
||||
5. Map a network share to the root TFTP directory on the PXE/TFTP server and create a \Boot folder. Consult your TFTP server documentation to determine the root TFTP server directory, then enable sharing for this directory, and verify it can be accessed on the network. In the following example, the PXE server name is PXE-1 and the TFTP root directory is shared using a network path of **\\\PXE-1\TFTPRoot**:
|
||||
|
||||
```
|
||||
net use y: \\PXE-1\TFTPRoot
|
||||
y:
|
||||
md boot
|
||||
```
|
||||
6. Copy the PXE boot files from the mounted directory to the \boot folder. For example:
|
||||
|
||||
```
|
||||
copy c:\winpe_amd64\mount\windows\boot\pxe\*.* y:\boot
|
||||
```
|
||||
7. Copy the boot.sdi file to the PXE/TFTP server.
|
||||
|
||||
```
|
||||
copy C:\winpe_amd64\media\boot\boot.sdi y:\boot
|
||||
```
|
||||
8. Copy the bootable Windows PE image (boot.wim) to the \boot folder.
|
||||
|
||||
```
|
||||
copy C:\winpe_amd64\media\sources\boot.wim y:\boot
|
||||
```
|
||||
9. (Optional) Copy true type fonts to the \boot folder
|
||||
|
||||
```
|
||||
copy C:\winpe_amd64\media\Boot\Fonts y:\boot\Fonts
|
||||
```
|
||||
|
||||
## Step 2: Configure boot settings and copy the BCD file
|
||||
|
||||
1. Create a BCD store using bcdedit.exe:
|
||||
|
||||
```
|
||||
bcdedit /createstore c:\BCD
|
||||
```
|
||||
2. Configure RAMDISK settings:
|
||||
|
||||
```
|
||||
bcdedit /store c:\BCD /create {ramdiskoptions} /d "Ramdisk options"
|
||||
bcdedit /store c:\BCD /set {ramdiskoptions} ramdisksdidevice boot
|
||||
bcdedit /store c:\BCD /set {ramdiskoptions} ramdisksdipath \boot\boot.sdi
|
||||
bcdedit /store c:\BCD /create /d "winpe boot image" /application osloader
|
||||
```
|
||||
The last command will return a GUID, for example:
|
||||
```
|
||||
The entry {a4f89c62-2142-11e6-80b6-00155da04110} was successfully created.
|
||||
```
|
||||
Copy this GUID for use in the next set of commands. In each command shown, replace "GUID1" with your GUID.
|
||||
|
||||
3. Create a new boot application entry for the Windows PE image:
|
||||
|
||||
```
|
||||
bcdedit /store c:\BCD /set {GUID1} device ramdisk=[boot]\boot\boot.wim,{ramdiskoptions}
|
||||
bcdedit /store c:\BCD /set {GUID1} path \windows\system32\winload.exe
|
||||
bcdedit /store c:\BCD /set {GUID1} osdevice ramdisk=[boot]\boot\boot.wim,{ramdiskoptions}
|
||||
bcdedit /store c:\BCD /set {GUID1} systemroot \windows
|
||||
bcdedit /store c:\BCD /set {GUID1} detecthal Yes
|
||||
bcdedit /store c:\BCD /set {GUID1} winpe Yes
|
||||
```
|
||||
4. Configure BOOTMGR settings (remember to replace GUID1 in the third command with your GUID):
|
||||
|
||||
```
|
||||
bcdedit /store c:\BCD /create {bootmgr} /d "boot manager"
|
||||
bcdedit /store c:\BCD /set {bootmgr} timeout 30
|
||||
bcdedit /store c:\BCD -displayorder {GUID1} -addlast
|
||||
```
|
||||
5. Copy the BCD file to your TFTP server:
|
||||
|
||||
```
|
||||
copy c:\BCD \\PXE-1\TFTPRoot\boot\BCD
|
||||
```
|
||||
|
||||
Your PXE/TFTP server is now configured. You can view the BCD settings that have been configured using the command bcdedit /store <BCD file location> /enum all. See the following example. Note: Your GUID will be different than the one shown below.
|
||||
|
||||
```
|
||||
C:\>bcdedit /store C:\BCD /enum all
|
||||
Windows Boot Manager
|
||||
--------------------
|
||||
identifier {bootmgr}
|
||||
description boot manager
|
||||
displayorder {a4f89c62-2142-11e6-80b6-00155da04110}
|
||||
timeout 30
|
||||
|
||||
Windows Boot Loader
|
||||
-------------------
|
||||
identifier {a4f89c62-2142-11e6-80b6-00155da04110}
|
||||
device ramdisk=[boot]\boot\boot.wim,{ramdiskoptions}
|
||||
description winpe boot image
|
||||
osdevice ramdisk=[boot]\boot\boot.wim,{ramdiskoptions}
|
||||
systemroot \Windows
|
||||
detecthal Yes
|
||||
winpe Yes
|
||||
|
||||
Setup Ramdisk Options
|
||||
---------------------
|
||||
identifier {ramdiskoptions}
|
||||
description ramdisk options
|
||||
ramdisksdidevice boot
|
||||
ramdisksdipath \boot\boot.sdi
|
||||
```
|
||||
|
||||
>[!TIP]
|
||||
>If you start the PXE boot process, but receive the error that "The boot configuration data for your PC is missing or contains errors" then verify that \\boot directory is installed under the correct TFTP server root directory. In the example used here the name of this directory is TFTPRoot, but your TFTP server might be different.
|
||||
|
||||
## PXE boot process summary
|
||||
|
||||
The following summarizes the PXE client boot process.
|
||||
|
||||
>The following assumes that you have configured DHCP option 67 (Bootfile Name) to "boot\PXEboot.n12" which enables direct boot to PXE with no user interaction. For more information about DHCP options for network boot, see [Managing Network Boot Programs](https://technet.microsoft.com/en-us/library/cc732351.aspx).
|
||||
|
||||
1. A client is directed by DHCP options 066 and 067 to download boot\\PXEboot.n12 from the TFTP server.
|
||||
2. PXEboot.n12 immediately begins a network boot.
|
||||
3. The client downloads boot\\bootmgr.exe and the boot\\BCD file from the TFTP server. Note: The BCD store must reside in the \\boot directory on the TFTP server and must be named BCD.
|
||||
5. Bootmgr.exe reads the BCD operating system entries and downloads boot\\boot.sdi and the Windows PE image (boot\\boot.wim). Optional files that can also be downloaded include true type fonts (boot\\Fonts\\wgl4\_boot.ttf) and the hibernation state file (\\hiberfil.sys) if these files are present.
|
||||
6. Bootmgr.exe starts Windows PE by calling winload.exe within the Windows PE image.
|
||||
7. Windows PE loads, a command prompt opens and wpeinit.exe is run to initialize Windows PE.
|
||||
8. The Windows PE client provides access to tools like imagex, diskpart, and bcdboot using the Windows PE command prompt. Using these tools together with a Windows 10 image file, the destination computer can be formatted properly to load a full Windows 10 operating system.
|
||||
|
||||
See Also
|
||||
---------
|
||||
|
||||
#### Concepts
|
||||
|
||||
[Windows PE Walkthroughs](https://technet.microsoft.com/en-us/library/cc748899.aspx)
|
||||
@ -1,89 +0,0 @@
|
||||
---
|
||||
title: Configure Client Computers (Windows 10)
|
||||
description: Configure Client Computers
|
||||
ms.assetid: a48176c9-b05c-4dd5-a9ef-83073e2370fc
|
||||
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](https://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**.
|
||||
3. Click **Allow a program or feature through Windows Firewall**.
|
||||
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:
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
- 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](https://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](https://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**
|
||||
**Type: DWORD**
|
||||
**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)
|
||||
|
||||
|
||||
@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Configure MDT for UserExit scripts (Windows 10)
|
||||
redirect_url: configure-mdt-for-userexit-scripts
|
||||
---
|
||||
@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Configure MDT settings (Windows 10)
|
||||
redirect_url: configure-mdt-settings
|
||||
---
|
||||
|
||||
@ -1,121 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: rules, configuration, automate, deploy
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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
|
||||
[Default]
|
||||
OSInstall=YES
|
||||
[00:15:5D:85:6B:00]
|
||||
OSDComputerName=PC00075
|
||||
```
|
||||
|
||||
In the preceding sample, you set the PC00075 computer name for a machine with a MAC Address of 00:15:5D:85:6B:00.
|
||||
|
||||
### Set computer name by serial number
|
||||
|
||||
Another way to assign a computer name is to identify the machine via its serial number.
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=SerialNumber, Default
|
||||
[Default]
|
||||
OSInstall=YES
|
||||
[CND0370RJ7]
|
||||
OSDComputerName=PC00075
|
||||
```
|
||||
|
||||
In this sample, you set the PC00075 computer name for a machine with a serial number of CND0370RJ7.
|
||||
|
||||
### Generate a computer name based on a serial number
|
||||
|
||||
You also can configure the rules engine to use a known property, like a serial number, to generate a computer name on the fly.
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
[Default]
|
||||
OSInstall=YES
|
||||
OSDComputerName=PC-%SerialNumber%
|
||||
```
|
||||
|
||||
In this sample, you configure the rules to set the computer name to a prefix (PC-) and then the serial number. If the serial number of the machine is CND0370RJ7, the preceding configuration sets the computer name to PC-CND0370RJ7.
|
||||
**Note**
|
||||
|
||||
Be careful when using the serial number to assign computer names. A serial number can contain more than 15 characters, but the Windows setup limits a computer name to 15 characters.
|
||||
|
||||
### Generate a limited computer name based on a serial number
|
||||
|
||||
To avoid assigning a computer name longer than 15 characters, you can configure the rules in more detail by adding VBScript functions, as follows:
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
[Default]
|
||||
OSInstall=YES
|
||||
OSDComputerName=PC-#Left("%SerialNumber%",12)#
|
||||
```
|
||||
|
||||
In the preceding sample, you still configure the rules to set the computer name to a prefix (PC-) followed by the serial number. However, by adding the Left VBScript function, you configure the rule to use only the first 12 serial-number characters for the name.
|
||||
|
||||
### Add laptops to a different organizational unit (OU) in Active Directory
|
||||
|
||||
In the rules, you find built-in properties that use a Windows Management Instrumentation (WMI) query to determine whether the machine you are deploying is a laptop, desktop, or server. In this sample, we assume you want to add laptops to different OUs in Active Directory. Note that ByLaptopType is not a reserved word; rather, it is the name of the section to read.
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=ByLaptopType, Default
|
||||
[Default]
|
||||
MachineObjectOU=OU=Workstations,OU=Contoso,DC=contoso,DC=com
|
||||
[ByLaptopType]
|
||||
Subsection=Laptop-%IsLaptop%
|
||||
[Laptop-True]
|
||||
MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com
|
||||
```
|
||||
|
||||
## Related topics
|
||||
|
||||
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
|
||||
|
||||
[Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
|
||||
|
||||
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
|
||||
|
||||
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
|
||||
|
||||
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
|
||||
|
||||
[Use web services in MDT](use-web-services-in-mdt.md)
|
||||
|
||||
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
|
||||
@ -1,69 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: rules, script
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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
|
||||
[Default]
|
||||
OSINSTALL=YES
|
||||
UserExit=Setname.vbs
|
||||
OSDComputerName=#SetName("%MACADDRESS%")#
|
||||
```
|
||||
|
||||
The UserExit=Setname.vbs calls the script and then assigns the computer name to what the SetName function in the script returns. In this sample the %MACADDRESS% variable is passed to the script
|
||||
|
||||
## The Setname.vbs UserExit script
|
||||
|
||||
The Setname.vbs script takes the MAC Address passed from the rules. The script then does some string manipulation to add a prefix (PC) and remove the semicolons from the MAC Address.
|
||||
|
||||
``` syntax
|
||||
Function UserExit(sType, sWhen, sDetail, bSkip)
|
||||
UserExit = Success
|
||||
End Function
|
||||
Function SetName(sMac)
|
||||
Dim re
|
||||
Set re = new RegExp
|
||||
re.IgnoreCase = true
|
||||
re.Global = true
|
||||
re.Pattern = ":"
|
||||
SetName = "PC" & re.Replace(sMac, "")
|
||||
End Function
|
||||
```
|
||||
The first three lines of the script make up a header that all UserExit scripts have. The interesting part is the lines between Function and End Function. Those lines add a prefix (PC), remove the colons from the MAC Address, and return the value to the rules by setting the SetName value.
|
||||
|
||||
**Note**
|
||||
The purpose of this sample is not to recommend that you use the MAC Address as a base for computer naming, but to show you how to take a variable from MDT, pass it to an external script, make some changes to it, and then return the new value to the deployment process.
|
||||
|
||||
## Related topics
|
||||
|
||||
[Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
|
||||
|
||||
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
|
||||
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
|
||||
|
||||
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
|
||||
|
||||
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
|
||||
|
||||
[Use web services in MDT](use-web-services-in-mdt.md)
|
||||
|
||||
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.md)
|
||||
@ -1,46 +0,0 @@
|
||||
---
|
||||
title: Configure MDT settings (Windows 10)
|
||||
description: One of the most powerful features in Microsoft Deployment Toolkit (MDT) 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
|
||||
keywords: customize, customization, deploy, features, tools
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.sitesec: library
|
||||
ms.pagetype: mdt
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Configure MDT settings
|
||||
|
||||
One of the most powerful features in Microsoft Deployment Toolkit (MDT) 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. The machines used in this topic.
|
||||
|
||||
## In this section
|
||||
|
||||
- [Set up MDT for BitLocker](set-up-mdt-for-bitlocker.md)
|
||||
- [Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
- [Configure MDT for UserExit scripts](configure-mdt-for-userexit-scripts.md)
|
||||
- [Simulate a Windows 10 deployment in a test environment](simulate-a-windows-10-deployment-in-a-test-environment.md)
|
||||
- [Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-10-deployment-information.md)
|
||||
- [Assign applications using roles in MDT](assign-applications-using-roles-in-mdt.md)
|
||||
- [Use web services in MDT](use-web-services-in-mdt.md)
|
||||
- [Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt.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](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)
|
||||
@ -1,114 +0,0 @@
|
||||
---
|
||||
title: Create a custom Windows PE boot image with Configuration Manager (Windows 10)
|
||||
description: In Microsoft System Center 2012 R2 Configuration Manager, you can create custom Windows Preinstallation Environment (Windows PE) boot images that include extra components and features.
|
||||
ms.assetid: b9e96974-324d-4fa4-b0ce-33cfc49c4809
|
||||
keywords: tool, customize, deploy, boot image
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Create a custom Windows PE boot image with Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
In Microsoft System Center 2012 R2 Configuration Manager, you can create custom Windows Preinstallation Environment (Windows PE) boot images that include extra components and features. This topic shows you how to create a custom Windows PE 5.0 boot image with the Microsoft Deployment Toolkit (MDT) wizard. You can also add the Microsoft Diagnostics and Recovery Toolset (DaRT) 10 to the boot image as part of the boot image creation process.
|
||||
|
||||
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. Both are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
## <a href="" id="sec01"></a>Add DaRT 10 files and prepare to brand the boot image
|
||||
|
||||
|
||||
The steps below outline the process for adding DaRT 10 installation files to the MDT installation directory. You also copy a custom background image to be used later. We assume you have downloaded Microsoft Desktop Optimization Pack (MDOP) 2015 and copied the x64 version of MSDaRT10.msi to the C:\\Setup\\DaRT 10 folder. We also assume you have created a custom background image and saved it in C:\\Setup\\Branding on CM01. In this section, we use a custom background image named ContosoBackground.bmp.
|
||||
|
||||
1. Install DaRT 10 (C:\\Setup\\DaRT 10\\MSDaRT10.msi) using the default settings.
|
||||
|
||||
2. Using File Explorer, navigate to the **C:\\Program Files\\Microsoft DaRT\\v10** folder.
|
||||
|
||||
3. Copy the Toolsx64.cab file to the **C:\\Program Files\\Microsoft Deployment Toolkit\\Templates\\Distribution\\Tools\\x64** folder.
|
||||
|
||||
4. Copy the Toolsx86.cab file to the **C:\\Program Files\\Microsoft Deployment Toolkit\\Templates\\Distribution\\Tools\\x86** folder.
|
||||
|
||||
5. Using File Explorer, navigate to the **C:\\Setup** folder.
|
||||
|
||||
6. Copy the **Branding** folder to **E:\\Sources\\OSD**.
|
||||
|
||||
## <a href="" id="sec02"></a>Create a boot image for Configuration Manager using the MDT wizard
|
||||
|
||||
|
||||
By using the MDT wizard to create the boot image in Configuration Manager, you gain additional options for adding components and features to the boot image. In this section, you create a boot image for Configuration Manager using the MDT wizard.
|
||||
|
||||
1. Using the Configuration Manager Console, in the Software Library workspace, expand **Operating Systems**, right-click **Boot Images**, and select **Create Boot Image using MDT**.
|
||||
|
||||
2. On the **Package Source** page, in the **Package source folder to be created (UNC Path):** text box, type **\\\\CM01\\Sources$\\OSD\\Boot\\Zero Touch WinPE x64** and click **Next**.
|
||||
|
||||
>[!NOTE]
|
||||
>The Zero Touch WinPE x64 folder does not yet exist. The folder will be created later by the wizard.
|
||||
|
||||
3. On the **General Settings** page, assign the name **Zero Touch WinPE x64** and click **Next**.
|
||||
|
||||
4. On the **Options** page, select the **x64** platform, and click **Next**.
|
||||
|
||||
5. On the **Components** page, in addition to the default selected **Microsoft Data Access Components (MDAC/ADO)** support, select the **Microsoft Diagnostics and Recovery Toolkit (DaRT)** check box.
|
||||
|
||||
|
||||
|
||||
Figure 15. Add the DaRT component to the Configuration Manager boot image.
|
||||
|
||||
6. On the **Customization** page, select the **Use a custom background bitmap file** check box, and in the **UNC path:** text box, browse to **\\\\CM01\\Sources$\\OSD\\Branding\\ ContosoBackground.bmp**. Then click **Next** twice.
|
||||
|
||||
>[!NOTE]
|
||||
>It will take a few minutes to generate the boot image.
|
||||
|
||||
7. Distribute the boot image to the CM01 distribution point by selecting the **Boot images** node, right-clicking the **Zero Touch WinPE x64** boot image, and selecting **Distribute Content**.
|
||||
|
||||
8. In the Distribute Content Wizard, add the CM01 distribution point, and complete the wizard.
|
||||
|
||||
9. Using Configuration Manager Trace, review the E:\\Program Files\\Microsoft Configuration Manager\\Logs\\distmgr.log file. Do not continue until you can see that the boot image is distributed. Look for the line that reads STATMSG: ID=2301. You also can view Content Status in the Configuration Manager Console by selecting **the Zero Touch WinPE x86** boot image.
|
||||
|
||||
|
||||
|
||||
Figure 16. Content status for the Zero Touch WinPE x64 boot image
|
||||
|
||||
10. Using the Configuration Manager Console, right-click the **Zero Touch WinPE x64** boot image and select **Properties**.
|
||||
|
||||
11. In the **Data Source** tab, select the **Deploy this boot image from the PXE-enabled distribution point** check box, and click **OK**.
|
||||
|
||||
12. Using Configuration Manager Trace, review the E:\\Program Files\\Microsoft Configuration Manager\\Logs\\distmgr.log file and look for this text: Expanding PS10000B to E:\\RemoteInstall\\SMSImages.
|
||||
|
||||
13. Review the **E:\\RemoteInstall\\SMSImages** folder. You should see three folders containing boot images. Two are from the default boot images, and the third folder (PS10000B) is from your new boot image with DaRT.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,195 +0,0 @@
|
||||
---
|
||||
title: Create a task sequence with Configuration Manager and MDT (Windows 10)
|
||||
description: In this topic, you will learn how to create a Microsoft System Center 2012 R2 Configuration Manager task sequence with Microsoft Deployment Toolkit (MDT) integration using the MDT wizard.
|
||||
ms.assetid: 0b069bec-5be8-47c6-bf64-7a630f41ac98
|
||||
keywords: deploy, upgrade, task sequence, install
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.pagetype: mdt
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Create a task sequence with Configuration Manager and MDT
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
In this topic, you will learn how to create a Microsoft System Center 2012 R2 Configuration Manager task sequence with Microsoft Deployment Toolkit (MDT) integration using the MDT wizard. Creating task sequences in System Center 2012 R2 Configuration Manager requires many more steps than creating task sequences for MDT Lite Touch installation. Luckily, the MDT wizard helps you through the process and also guides you through creating the needed packages.
|
||||
|
||||
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard, both of which 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).
|
||||
|
||||
## <a href="" id="sec01"></a>Create a task sequence using the MDT Integration Wizard
|
||||
|
||||
|
||||
This section walks you through the process of creating a System Center 2012 R2 Configuration Manager task sequence for production use.
|
||||
|
||||
1. On CM01, using the Configuration Manager Console, in the Software Library workspace, expand **Operating Systems**, right-click **Task Sequences**, and select **Create MDT Task Sequence**.
|
||||
|
||||
2. On the **Choose Template** page, select the **Client Task Sequence** template and click **Next**.
|
||||
|
||||
3. On the **General** page, assign the following settings and then click **Next**:
|
||||
|
||||
* Task sequence name: Windows 10 Enterprise x64 RTM
|
||||
|
||||
* Task sequence comments: Production image with Office 2013
|
||||
|
||||
4. On the **Details** page, assign the following settings and then click **Next**:
|
||||
|
||||
* Join a Domain
|
||||
|
||||
* Domain: contoso.com
|
||||
|
||||
* Account: CONTOSO\\CM\_JD
|
||||
|
||||
* Password: Passw0rd!
|
||||
|
||||
* Windows Settings
|
||||
|
||||
* User name: Contoso
|
||||
|
||||
* Organization name: Contoso
|
||||
|
||||
* Product key: <blank>
|
||||
|
||||
5. On the **Capture Settings** page, accept the default settings, and click **Next**.
|
||||
|
||||
6. On the **Boot Image** page, browse and select the **Zero Touch WinPE x64** boot image package. Then click **Next**.
|
||||
|
||||
7. On the **MDT Package** page, select **Create a new Microsoft Deployment Toolkit Files package**, and in the **Package source folder to be created (UNC Path):** text box, type **\\\\CM01\\Sources$\\OSD\\MDT\\MDT**. Then click **Next**.
|
||||
|
||||
8. On the **MDT Details** page, assign the name **MDT** and click **Next**.
|
||||
|
||||
9. On the **OS Image** page, browse and select the **Windows 10 Enterprise x64 RTM** package. Then click **Next**.
|
||||
|
||||
10. On the **Deployment Method** page, accept the default settings and click **Next**.
|
||||
|
||||
11. On the **Client Package** page, browse and select the **OSD / Configuration Manager Client** package. Then click **Next**.
|
||||
|
||||
12. On the **USMT Package** page, browse and select **the OSD / Microsoft Corporation User State Migration Tool for Windows 8 10.0.10240.16384** package. Then click **Next**.
|
||||
|
||||
13. On the **Settings Package** page, select the **Create a new settings package** option, and in the **Package source folder to be created (UNC Path):** text box, type **\\\\CM01\\Sources$\\OSD\\Settings\\Windows 10 x64 Settings**. Then click **Next**.
|
||||
|
||||
14. On the **Settings Details** page, assign the name **Windows 10 x64 Settings** and click **Next**.
|
||||
|
||||
15. On the **Sysprep Package** page, click **Next** twice.
|
||||
|
||||
16. On the **Confirmation** page, click **Finish**.
|
||||
|
||||
## <a href="" id="sec02"></a>Edit the task sequence
|
||||
|
||||
|
||||
After you create the task sequence, we recommend that you configure the task sequence for an optimal deployment experience. The configurations include enabling support for Unified Extensible Firmware Interface (UEFI), dynamic organizational unit (OU) allocation, computer replace scenarios, and more.
|
||||
|
||||
1. On CM01, using the Configuration Manager Console, select **Task Sequences**, right-click **Windows 10 Enterprise x64 RTM** task sequence, and select **Edit**.
|
||||
|
||||
2. In the **Install** group, select the **Set Variable for Drive Letter** action and configure the following:
|
||||
|
||||
* OSDPreserveDriveLetter: True
|
||||
|
||||
>[!NOTE]
|
||||
>If you don't change this value, your Windows installation will end up in E:\\Windows.
|
||||
|
||||
3. In the **Post Install** group, select **Apply Network Settings**, and configure the Domain OU value to use the **Contoso / Workstations** OU (browse for values).
|
||||
|
||||
4. In the **Post Install** group, disable the **Auto Apply Drivers** action. (Disabling is done by selecting the action and, in the **Options** tab, selecting the **Disable this step** check box.)
|
||||
|
||||
5. After the disabled **Post Install / Auto Apply Drivers** action, add a new group name: **Drivers**.
|
||||
|
||||
6. After the **Post Install / Drivers** group, add an **Apply Driver Package** action with the following settings:
|
||||
|
||||
* Name: HP EliteBook 8560w
|
||||
|
||||
* Driver Package: Windows 10 x64 - HP EliteBook 8560w
|
||||
|
||||
* Options: Task Sequence Variable: Model equals HP EliteBook 8560w
|
||||
|
||||
>[!NOTE]
|
||||
>You also can add a Query WMI condition with the following query: SELECT \* FROM Win32\_ComputerSystem WHERE Model LIKE '%HP EliteBook 8560w%'
|
||||
|
||||
|
||||
|
||||
*Figure 24. The driver package options*
|
||||
|
||||
7. In the **State Restore / Install Applications** group, select the **Install Application** action.
|
||||
|
||||
8. Select the **Install the following applications** option, and add the OSD / Adobe Reader XI - OSD Install application to the list.
|
||||
|
||||
|
||||
|
||||
*Figure 25. Add an application to the Configuration Manager task sequence*
|
||||
|
||||
9. In the **State Restore** group, after the **Set Status 5** action, add a **Request State Store** action with the following settings:
|
||||
|
||||
* Restore state from another computer
|
||||
|
||||
* If computer account fails to connect to state store, use the Network Access account
|
||||
|
||||
* Options: Continue on error
|
||||
|
||||
* Options / Condition:
|
||||
|
||||
* Task Sequence Variable
|
||||
|
||||
* USMTLOCAL not equals True
|
||||
|
||||
10. In the **State Restore** group, after the **Restore User State** action, add a **Release State Store** action with the following settings:
|
||||
|
||||
* Options: Continue on error
|
||||
|
||||
* Options / Condition:
|
||||
|
||||
* Task Sequence Variable
|
||||
|
||||
* USMTLOCAL not equals True
|
||||
|
||||
11. Click **OK**.
|
||||
|
||||
>[!NOTE]
|
||||
>The Request State Store and Release State Store actions need to be added for common computer replace scenarios.
|
||||
|
||||
|
||||
|
||||
## <a href="" id="sec03"></a>Move the packages
|
||||
|
||||
|
||||
While creating the task sequence with the MDT wizard, a few operating system deployment packages were created. To move these packages to the OSD folder, take the following steps.
|
||||
|
||||
1. On CM01, using the Configuration Manager Console, in the Software Library workspace, expand **Application Management**, and then select **Packages**.
|
||||
|
||||
2. Select the **MDT** and **Windows 10 x64 Settings** packages, right-click and select **Move**.
|
||||
|
||||
3. In the **Move Selected Items** dialog box, select the **OSD** folder, and click **OK**.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
|
||||
|
||||
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
|
||||
|
||||
[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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,644 +0,0 @@
|
||||
---
|
||||
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
|
||||
keywords: deploy, deployment, configure, customize, install, installation
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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). 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. 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:
|
||||
- Deployment share path: E:\\MDTBuildLab
|
||||
- Share name: MDTBuildLab$
|
||||
- Deployment share description: MDT Build Lab
|
||||
- <default>
|
||||
- Verify that you can access the \\\\MDT01\\MDTBuildLab$ share.
|
||||
|
||||
|
||||
|
||||
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. 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 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 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**.
|
||||
4. 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:
|
||||
5. Full set of source files
|
||||
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. 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
|
||||
- Install - Microsoft Visual C++ 2005 SP1 - x64
|
||||
- Install - Microsoft Visual C++ 2008 SP1 - x86
|
||||
- Install - Microsoft Visual C++ 2008 SP1 - x64
|
||||
- Install - Microsoft Visual C++ 2010 SP1 - x86
|
||||
- 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](https://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 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. 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.
|
||||
|
||||
3. In the Office Customization Tool dialog box, select the Create a new Setup customization file for the following product option, select the Microsoft Office Professional Plus 2013 (32-bit) product, and click OK.
|
||||
4. Use the following settings to configure the Office 2013 setup to be fully unattended:
|
||||
1. Install location and organization name
|
||||
- Organization name: Contoso
|
||||
2. Licensing and user interface
|
||||
1. Select Use KMS client key
|
||||
2. Select I accept the terms in the License Agreement.
|
||||
3. Select Display level: None
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
Import-Module "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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2005 SP1 - x86"
|
||||
$CommandLine = "vcredist_x86.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2005SP1x86"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2005 SP1 - x64"
|
||||
$CommandLine = "vcredist_x64.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2005SP1x64"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2008 SP1 - x86"
|
||||
$CommandLine = "vcredist_x86.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2008SP1x86"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2008 SP1 - x64"
|
||||
$CommandLine = "vcredist_x64.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2008SP1x64"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2010 SP1 - x86"
|
||||
$CommandLine = "vcredist_x86.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2010SP1x86"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2010 SP1 - x64"
|
||||
$CommandLine = "vcredist_x64.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2010SP1x64"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2012 Update 4 - x86"
|
||||
$CommandLine = "vcredist_x86.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2012Ux86"
|
||||
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:
|
||||
|
||||
``` syntax
|
||||
$ApplicationName = "Install - Microsoft Visual C++ 2012 Update 4 - x64"
|
||||
$CommandLine = "vcredist_x64.exe /Q"
|
||||
$ApplicationSourcePath = "E:\Downloads\VC++2012Ux64"
|
||||
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
|
||||
2. Task sequence name: Windows 10 Enterprise x64 RTM Default Image
|
||||
3. Task sequence comments: Reference Build
|
||||
4. Template: Standard Client Task Sequence
|
||||
5. Select OS: Windows 10 Enterprise x64 RTM Default Image
|
||||
6. Specify Product Key: Do not specify a product key at this time
|
||||
7. Full Name: Contoso
|
||||
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.
|
||||
**Note**
|
||||
Enable an action by going to the Options tab and clearing the Disable this step check box.
|
||||
|
||||
2. State Restore. Enable the Windows Update (Post-Application Installation) action.
|
||||
3. State Restore. Enable the Windows Update (Post-Application Installation) action. State Restore. After the **Tattoo** action, add a new **Group** action with the following setting:
|
||||
- Name: Custom Tasks (Pre-Windows Update)
|
||||
4. State Restore. After Windows Update (Post-Application Installation) action, rename Custom Tasks to Custom Tasks (Post-Windows Update).
|
||||
**Note**
|
||||
The reason for adding the applications after the Tattoo action but before running Windows Update is simply to save time during the deployment. This way we can add all applications that will upgrade some of the built-in components and avoid unnecessary updating.
|
||||
|
||||
5. State Restore / Custom Tasks (Pre-Windows Update). Add a new Install Roles and Features action with the following settings:
|
||||
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. 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
|
||||
7. Repeat the previous step (add a new **Install Application**) to add the following applications:
|
||||
1. Install - Microsoft Visual C++ 2005 SP1 - x64
|
||||
2. Install - Microsoft Visual C++ 2008 SP1 - x86
|
||||
3. Install - Microsoft Visual C++ 2008 SP1 - x64
|
||||
4. Install - Microsoft Visual C++ 2010 SP1 - x86
|
||||
5. Install - Microsoft Visual C++ 2010 SP1 - x64
|
||||
6. Install - Microsoft Visual C++ 2012 Update 4 - x86
|
||||
7. Install - Microsoft Visual C++ 2012 Update 4 - x64
|
||||
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. A task sequence with optional Suspend action (LTISuspend.wsf) added.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
4. In the **amd64\_Microsoft-Windows-IE-InternetExplorer\_neutral properties** window (right-hand window), set the following values:
|
||||
- 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. 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**.
|
||||
2. Select the **Rules** tab and modify using the following information:
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
[Default]
|
||||
_SMSTSORGNAME=Contoso
|
||||
UserDataLocation=NONE
|
||||
DoCapture=YES
|
||||
OSInstall=Y
|
||||
AdminPassword=P@ssw0rd
|
||||
TimeZoneName=Pacific Standard Time
|
||||
JoinWorkgroup=WORKGROUP
|
||||
HideShell=YES
|
||||
FinishAction=SHUTDOWN
|
||||
DoNotCreateExtraPartition=YES
|
||||
WSUSServer=http://mdt01.contoso.com:8530
|
||||
ApplyGPOPack=NO
|
||||
SLSHARE=\\MDT01\Logs$
|
||||
SkipAdminPassword=YES
|
||||
SkipProductKey=YES
|
||||
SkipComputerName=YES
|
||||
SkipDomainMembership=YES
|
||||
SkipUserData=YES
|
||||
SkipLocaleSelection=YES
|
||||
SkipTaskSequence=NO
|
||||
SkipTimeZone=YES
|
||||
SkipApplications=YES
|
||||
SkipBitLocker=YES
|
||||
SkipSummary=YES
|
||||
SkipRoles=YES
|
||||
SkipCapture=NO
|
||||
SkipFinalSummary=YES
|
||||
```
|
||||
|
||||
|
||||
|
||||
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
|
||||
[Default]
|
||||
DeployRoot=\\MDT01\MDTBuildLab$
|
||||
UserDomain=CONTOSO
|
||||
UserID=MDT_BA
|
||||
UserPassword=P@ssw0rd
|
||||
SkipBDDWelcome=YES
|
||||
```
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
4. In the **Windows PE** tab, in the **Platform** drop-down list, select **x86**.
|
||||
5. In the **Lite Touch Boot Image Settings** area, configure the following settings:
|
||||
1. Image description: MDT Build Lab x86
|
||||
2. ISO file name: MDT Build Lab x86.iso
|
||||
6. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
|
||||
7. In the **Lite Touch Boot Image Settings** area, configure the following settings:
|
||||
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
|
||||
[Default]
|
||||
DeployRoot=\\MDT01\MDTBuildLab$
|
||||
UserDomain=CONTOSO
|
||||
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
|
||||
[Default]
|
||||
_SMSTSORGNAME=Contoso
|
||||
UserDataLocation=NONE
|
||||
DoCapture=YES
|
||||
OSInstall=Y
|
||||
AdminPassword=P@ssw0rd
|
||||
TimeZoneName=Pacific Standard Time
|
||||
JoinWorkgroup=WORKGROUP
|
||||
HideShell=YES
|
||||
FinishAction=SHUTDOWN
|
||||
DoNotCreateExtraPartition=YES
|
||||
WSUSServer=http://mdt01.contoso.com:8530
|
||||
ApplyGPOPack=NO
|
||||
SLSHARE=\\MDT01\Logs$
|
||||
SkipAdminPassword=YES
|
||||
SkipProductKey=YES
|
||||
SkipComputerName=YES
|
||||
SkipDomainMembership=YES
|
||||
SkipUserData=YES
|
||||
SkipLocaleSelection=YES
|
||||
SkipTaskSequence=NO
|
||||
SkipTimeZone=YES
|
||||
SkipApplications=YES
|
||||
SkipBitLocker=YES
|
||||
SkipSummary=YES
|
||||
SkipRoles=YES
|
||||
SkipCapture=NO
|
||||
SkipFinalSummary=YES
|
||||
```
|
||||
- **Priority.** Has the same function as in Bootstrap.ini. Priority determines the order in which different sections are read. This CustomSettings.ini has only one section, named \[Default\]. In general, if you have multiple sections that set the same value, the value from the first section (higher priority) wins. The rare exceptions are listed in the ZTIGather.xml file.
|
||||
- **\_SMSTSORGNAME.** The organization name displayed in the task sequence progress bar window during deployment.
|
||||
- **UserDataLocation.** Controls the settings for user state backup. You do not need to use when building and capturing a reference image.
|
||||
- **DoCapture.** Configures the task sequence to run the System Preparation (Sysprep) tool and capture the image to a file when the operating system is installed.
|
||||
- **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.
|
||||
|
||||
- **JoinWorkgroup.** Configures Windows to join a workgroup.
|
||||
- **HideShell.** Hides the Windows Shell during deployment. This is especially useful for Windows 8.1 deployments in which the deployment wizard will otherwise appear behind the tiles.
|
||||
- **FinishAction.** Instructs MDT what to do when the task sequence is complete.
|
||||
- **DoNotCreateExtraPartition.** Configures the task sequence not to create the extra partition for BitLocker. There is no need to do this for your reference image.
|
||||
- **WSUSServer.** Specifies which Windows Server Update Services (WSUS) server (and port, if needed) to use during the deployment. Without this option MDT will use Microsoft Update directly, which will increase deployment time and limit your options of controlling which updates are applied.
|
||||
- **SLSHARE.** Instructs MDT to copy the log files to a server share if something goes wrong during deployment, or when a deployment is successfully completed.
|
||||
- **ApplyGPOPack.** Allows you to deploy local group policies created by Microsoft Security Compliance Manager (SCM).
|
||||
- **SkipAdminPassword.** Skips the pane that asks for the Administrator password.
|
||||
- **SkipProductKey.** Skips the pane that asks for the product key.
|
||||
- **SkipComputerName.** Skips the Computer Name pane.
|
||||
- **SkipDomainMemberShip.** Skips the Domain Membership pane. If set to Yes, you need to configure either the JoinWorkgroup value or the JoinDomain, DomainAdmin, DomainAdminDomain, and DomainAdminPassword properties.
|
||||
- **SkipUserData.** Skips the pane for user state migration.
|
||||
- **SkipLocaleSelection.** Skips the pane for selecting language and keyboard settings.
|
||||
- **SkipTimeZone.** Skips the pane for setting the time zone.
|
||||
- **SkipApplications.** Skips the Applications pane.
|
||||
- **SkipBitLocker.** Skips the BitLocker pane.
|
||||
- **SkipSummary.** Skips the initial Windows Deployment Wizard summary pane.
|
||||
- **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.
|
||||
|
||||
2. Create a virtual machine with the following settings:
|
||||
1. Name: REFW10X64-001
|
||||
2. Location: C:\\VMs
|
||||
3. Memory: 1024 MB
|
||||
4. Network: External (The network that is connected to the same infrastructure as MDT01 is)
|
||||
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.
|
||||
|
||||
4. Start the REFW10X64-001 virtual machine. After booting into Windows PE, complete the Windows Deployment Wizard using the following settings:
|
||||
1. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Default Image
|
||||
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. 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.
|
||||
3. Updates the operating system via your local Windows Server Update Services (WSUS) server.
|
||||
4. Stages Windows PE on the local disk.
|
||||
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](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-settings.md)
|
||||
@ -1,99 +0,0 @@
|
||||
---
|
||||
title: Create an application to deploy with Windows 10 using Configuration Manager (Windows 10)
|
||||
description: Microsoft System Center 2012 R2 Configuration Manager supports deploying applications as part of the Windows 10 deployment process.
|
||||
ms.assetid: 2dfb2f39-1597-4999-b4ec-b063e8a8c90c
|
||||
keywords: deployment, task sequence, custom, customize
|
||||
ms.prod: w10
|
||||
localizationpriority: high
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Create an application to deploy with Windows 10 using Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
Microsoft System Center 2012 R2 Configuration Manager supports deploying applications as part of the Windows 10 deployment process. In this section, you create an application in System Center 2012 R2 Configuration Manager that you later configure the task sequence to use.
|
||||
|
||||
For the purposes of this topic, we will use CM01, a machine running Windows Server 2012 R2 Standard 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).
|
||||
|
||||
>[!NOTE]
|
||||
>Even though the new application model is fully supported to deploy via the task sequence, the most reliable way to deploy software via the task sequence is still the legacy packages, especially if you deploy many applications.
|
||||
|
||||
## Example: Create the Adobe Reader XI application
|
||||
|
||||
|
||||
The following steps show you how to create the Adobe Reader XI application. This section assumes that you have downloaded the MSI version of Adobe Reader XI to the C:\\Setup\\Adobe Reader XI folder on CM01.
|
||||
|
||||
1. On CM01, using File Explorer, copy the **C:\\Setup\\Adobe Reader XI** folder to the **E:\\Sources\\Software\\Adobe** folder.
|
||||
|
||||
2. Using the Configuration Manager Console, in the Software Library workspace, expand **Application Management**.
|
||||
|
||||
3. Right-click **Applications** and select **Folder / Create Folder**. Assign the name **OSD**.
|
||||
|
||||
4. Right-click the **OSD** folder, and select **Create Application**.
|
||||
|
||||
5. In the Create Application Wizard, on the **General** page, use the following settings:
|
||||
|
||||
* Automatically detect information about this application from installation files
|
||||
|
||||
* Type: Windows Installer (\*.msi file)
|
||||
|
||||
* Location: \\\\CM01\\Sources$\\Software\\Adobe\\Adobe Reader XI
|
||||
|
||||
* \\AdbeRdr11000\_en\_US.msi
|
||||
|
||||
|
||||
|
||||
*Figure 19. The Create Application Wizard*
|
||||
|
||||
6. Click **Next**, and wait while Configuration Manager parses the MSI file.
|
||||
|
||||
7. On the **Import Information** page, review the information and then click **Next**.
|
||||
|
||||
8. On the **General Information** page, name the application Adobe Reader XI - OSD Install, click **Next** twice, and then click **Close**.
|
||||
|
||||
>[!NOTE]
|
||||
>Because it is not possible to reference an application deployment type in the task sequence, you should have a single deployment type for applications deployed by the task sequence. If you are deploying applications via both the task sequence and normal application deployment, and you have multiple deployment types, you should have two applications of the same software. In this section, you add the "OSD Install" suffix to applications that are deployed via the task sequence. If using packages, you can still reference both package and program in the task sequence.
|
||||
|
||||
|
||||
|
||||
*Figure 20. Add the "OSD Install" suffix to the application name*
|
||||
|
||||
9. In the **Applications** node, select the Adobe Reader XI - OSD Install application, and click **Properties** on the ribbon bar.
|
||||
|
||||
10. In the **General Information** tab, select the **Allow this application to be installed from the Install Application task sequence action without being deployed** check box, and click **OK**.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
|
||||
|
||||
[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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,654 +0,0 @@
|
||||
---
|
||||
title: Deploy a Windows 10 image using MDT (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).
|
||||
ms.assetid: 1d70a3d8-1b1d-4051-b656-c0393a93f83c
|
||||
keywords: deployment, automate, tools, configure
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.sitesec: library
|
||||
ms.pagetype: mdt
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Deploy a Windows 10 image using MDT
|
||||
|
||||
**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). 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. 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](https://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:
|
||||
1. Name: MDT\_JD
|
||||
2. User logon name: MDT\_JD
|
||||
3. Password: P@ssw0rd
|
||||
4. User must change password at next logon: Clear
|
||||
5. User cannot change password: Select
|
||||
6. Password never expires: Select
|
||||
3. In an elevated Windows PowerShell prompt (run as Administrator), run the following commands and press **Enter** after each command:
|
||||
``` syntax
|
||||
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
|
||||
Set-Location C:\Setup\Scripts
|
||||
.\Set-OUPermissions.ps1 -Account MDT_JD
|
||||
-TargetOU "OU=Workstations,OU=Computers,OU=Contoso"
|
||||
```
|
||||
4. The Set-OUPermissions.ps1 script allows the MDT\_JD user account permissions to manage computer accounts in the Contoso / Computers OU. Below you find a list of the permissions being granted:
|
||||
1. Scope: This object and all descendant objects
|
||||
1. Create Computer objects
|
||||
2. Delete Computer objects
|
||||
2. Scope: Descendant Computer objects
|
||||
1. Read All Properties
|
||||
2. Write All Properties
|
||||
3. Read Permissions
|
||||
4. Modify Permissions
|
||||
5. Change Password
|
||||
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).
|
||||
|
||||
### 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**.
|
||||
3. On the **Path** page, in the **Deployment share path** text box, type **E:\\MDTProduction** and click **Next**.
|
||||
4. On the **Share** page, in the **Share name** text box, type **MDTProduction$** and click **Next**.
|
||||
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**.
|
||||
3. On the **OS Type** page, select **Custom image file** and click **Next**.
|
||||
4. On the **Image** page, in the **Source file** text box, browse to **E:\\MDTBuildLab\\Captures\\REFW10X64-001.wim** and click **Next**.
|
||||
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. 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**.
|
||||
3. In the **Applications** node, right-click the **Adobe** folder and select **New Application**.
|
||||
4. On the **Application Type** page, select the **Application with source files** option and click **Next**.
|
||||
5. On the **Details** page, in the **Application** name text box, type **Install - Adobe Reader XI - x86** and click **Next**.
|
||||
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. 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 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, 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
|
||||
2. WinPE x64
|
||||
3. Windows 10 x64
|
||||
3. In the new Windows 10 x64 folder, create the following folder structure:
|
||||
- Dell
|
||||
- Latitude E6440
|
||||
- HP
|
||||
- HP EliteBook 8560w
|
||||
- Lenovo
|
||||
- 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
|
||||
|
||||
When you import drivers to the MDT 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:
|
||||
1. WinPE x86
|
||||
2. WinPE x64
|
||||
3. Windows 10 x64
|
||||
3. In the **Windows 10 x64** folder, create the following folder structure:
|
||||
- Dell Inc.
|
||||
- Latitude E6440
|
||||
- Hewlett-Packard
|
||||
- HP EliteBook 8560w
|
||||
- Lenovo
|
||||
- 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
|
||||
```
|
||||
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](https://go.microsoft.com/fwlink/p/?LinkId=619536).
|
||||
|
||||
|
||||
|
||||
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**.
|
||||
2. In the New Selection Profile Wizard, create a selection profile with the following settings:
|
||||
1. Selection Profile name: WinPE x86
|
||||
2. Folders: Select the WinPE x86 folder in Out-of-Box Drivers.
|
||||
3. Again, right-click the **Selection Profiles** node, and select **New Selection Profile**.
|
||||
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. 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](https://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](https://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](https://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
|
||||
2. Task sequence name: Windows 10 Enterprise x64 RTM Custom Image
|
||||
3. Task sequence comments: Production Image
|
||||
4. Template: Standard Client Task Sequence
|
||||
5. Select OS: Windows 10 Enterprise x64 RTM Custom Image
|
||||
6. Specify Product Key: Do not specify a product key at this time
|
||||
7. Full Name: Contoso
|
||||
8. Organization: Contoso
|
||||
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:
|
||||
1. Name: Set DriverGroup001
|
||||
2. Task Sequence Variable: DriverGroup001
|
||||
3. Value: Windows 10 x64\\%Make%\\%Model%
|
||||
2. Configure the **Inject Drivers** action with the following settings:
|
||||
1. Choose a selection profile: Nothing
|
||||
2. Install all drivers from the selection profile
|
||||
**Note**
|
||||
The configuration above indicates that MDT should only use drivers from the folder specified by the DriverGroup001 property, which is defined by the "Choose a selection profile: Nothing" setting, and that MDT should not use plug and play to determine which drivers to copy, which is defined by the "Install all drivers from the selection profile" setting.
|
||||
|
||||
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. 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
|
||||
2. Right-click the **MDT Production** deployment share and select **Properties**.
|
||||
3. Select the **Rules** tab and modify using the following information:
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
[Default]
|
||||
_SMSTSORGNAME=Contoso
|
||||
OSInstall=YES
|
||||
UserDataLocation=AUTO
|
||||
TimeZoneName=Pacific Standard Time
|
||||
AdminPassword=P@ssw0rd
|
||||
JoinDomain=contoso.com
|
||||
DomainAdmin=CONTOSO\MDT_JD
|
||||
DomainAdminPassword=P@ssw0rd
|
||||
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
|
||||
SLShare=\\MDT01\Logs$
|
||||
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
|
||||
USMTMigFiles001=MigApp.xml
|
||||
USMTMigFiles002=MigUser.xml
|
||||
HideShell=YES
|
||||
ApplyGPOPack=NO
|
||||
WSUSServer=mdt01.contoso.com:8530
|
||||
SkipAppsOnUpgrade=NO
|
||||
SkipAdminPassword=YES
|
||||
SkipProductKey=YES
|
||||
SkipComputerName=NO
|
||||
SkipDomainMembership=YES
|
||||
SkipUserData=YES
|
||||
SkipLocaleSelection=YES
|
||||
SkipTaskSequence=NO
|
||||
SkipTimeZone=YES
|
||||
SkipApplications=NO
|
||||
SkipBitLocker=YES
|
||||
SkipSummary=YES
|
||||
SkipCapture=YES
|
||||
SkipFinalSummary=NO
|
||||
```
|
||||
4. Click **Edit Bootstrap.ini** and modify using the following information:
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
[Default]
|
||||
DeployRoot=\\MDT01\MDTProduction$
|
||||
UserDomain=CONTOSO
|
||||
UserID=MDT_BA
|
||||
SkipBDDWelcome=YES
|
||||
```
|
||||
5. In the **Windows PE** tab, in the **Platform** drop-down list, make sure **x86** is selected.
|
||||
6. In the **General** sub tab, configure the following settings:
|
||||
- In the **Lite Touch Boot Image Settings** area:
|
||||
1. Image description: MDT Production x86
|
||||
2. ISO file name: MDT Production x86.iso
|
||||
**Note**
|
||||
Because you are going to use Pre-Boot Execution Environment (PXE) later to deploy the machines, you do not need the ISO file; however, we recommend creating ISO files because they are useful when troubleshooting deployments and for quick tests.
|
||||
|
||||
7. In the **Drivers and Patches** sub tab, select the **WinPE x86** selection profile and select the **Include all drivers from the selection profile** option.
|
||||
8. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
|
||||
9. In the **General** sub tab, configure the following settings:
|
||||
- In the **Lite Touch Boot Image Settings** area:
|
||||
1. Image description: MDT Production x64
|
||||
2. ISO file name: MDT Production x64.iso
|
||||
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 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]
|
||||
Priority=Default
|
||||
[Default]
|
||||
DeployRoot=\\MDT01\MDTProduction$
|
||||
UserDomain=CONTOSO
|
||||
UserID=MDT_BA
|
||||
SkipBDDWelcome=YES
|
||||
```
|
||||
### The CustomSettings.ini file
|
||||
|
||||
This is the CustomSettings.ini file with the new join domain information:
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
[Default]
|
||||
_SMSTSORGNAME=Contoso
|
||||
OSInstall=Y
|
||||
UserDataLocation=AUTO
|
||||
TimeZoneName=Pacific Standard Time
|
||||
AdminPassword=P@ssw0rd
|
||||
JoinDomain=contoso.com
|
||||
DomainAdmin=CONTOSO\MDT_JD
|
||||
DomainAdminPassword=P@ssw0rd
|
||||
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
|
||||
SLShare=\\MDT01\Logs$
|
||||
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
|
||||
USMTMigFiles001=MigApp.xml
|
||||
USMTMigFiles002=MigUser.xml
|
||||
HideShell=YES
|
||||
ApplyGPOPack=NO
|
||||
WSUSServer=http://mdt01.contoso.com:8530
|
||||
SkipAppsOnUpgrade=NO
|
||||
SkipAdminPassword=YES
|
||||
SkipProductKey=YES
|
||||
SkipComputerName=NO
|
||||
SkipDomainMembership=YES
|
||||
SkipUserData=YES
|
||||
SkipLocaleSelection=YES
|
||||
SkipTaskSequence=NO
|
||||
SkipTimeZone=YES
|
||||
SkipApplications=NO
|
||||
SkipBitLocker=YES
|
||||
SkipSummary=YES
|
||||
SkipCapture=YES
|
||||
SkipFinalSummary=NO
|
||||
EventService=http://MDT01:9800
|
||||
```
|
||||
The additional properties to use in the MDT Production rules file are as follows:
|
||||
- **JoinDomain.** The domain to join.
|
||||
- **DomainAdmin.** The account to use when joining the machine to the domain.
|
||||
- **DomainAdminDomain.** The domain for the join domain account.
|
||||
- **DomainAdminPassword.** The password for the join domain account.
|
||||
- **MachineObjectOU.** The organizational unit (OU) to which to add the computer account.
|
||||
- **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.
|
||||
|
||||
### 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, 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.
|
||||
- Configure the deployment share to add DaRT.
|
||||
In these steps, we assume that you downloaded MDOP 2015 R1 and copied DaRT 10 to the E:\\Setup\\DaRT 10 folder on MDT01.
|
||||
1. On MDT01, install DaRT 10 (MSDaRT10.msi) using the default settings.
|
||||
2. Using File Explorer, navigate to the **C:\\Program Files\\Microsoft DaRT\\v10** folder.
|
||||
3. Copy the Toolsx64.cab file to **E:\\MDTProduction\\Tools\\x64**.
|
||||
4. Copy the Toolsx86.cab file to **E:\\MDTProduction\\Tools\\x86**.
|
||||
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. 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. 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
|
||||
2. Location: C:\\VMs
|
||||
3. Generation: 2
|
||||
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. 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
|
||||
3. Computer Name: PC0005
|
||||
4. Applications: Select the Install - Adobe Reader XI - x86 application.
|
||||
4. The setup now starts and does the following:
|
||||
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 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. 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. 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 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. 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:
|
||||
1. General Settings
|
||||
- Selection profile name: Windows 10 Offline Media
|
||||
2. Folders
|
||||
1. Applications / Adobe
|
||||
2. Operating Systems / Windows 10
|
||||
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.
|
||||
|
||||
2. Using Deployment Workbench, in the **MDT Production / Advanced Configuration** node, right-click the **Media** node, and select **New Media**.
|
||||
3. Use the following settings for the New Media Wizard:
|
||||
- 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:
|
||||
1. Clear the Generate x86 boot image check box.
|
||||
2. ISO file name: Windows 10 Offline Media.iso
|
||||
4. Still in the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
|
||||
5. In the **General** sub tab, configure the following settings:
|
||||
1. In the **Lite Touch Boot Image Settings** area:
|
||||
- Image description: MDT Production x64
|
||||
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](https://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. 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-settings.md)
|
||||
@ -1,123 +0,0 @@
|
||||
---
|
||||
title: What's new in Windows 10 deployment
|
||||
description: Changes and new features related to Windows 10 deployment
|
||||
keywords: deployment, automate, tools, configure, news
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.prod: w10
|
||||
ms.sitesec: library
|
||||
ms.pagetype: deploy
|
||||
author: greg-lindsay
|
||||
---
|
||||
|
||||
# What's new in Windows 10 deployment
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
|
||||
|
||||
## In this topic
|
||||
|
||||
This topic provides an overview of new solutions and online content related to deploying Windows 10 in your organization.
|
||||
|
||||
- For an all-up overview of new features in Windows 10, see [What's new in Windows 10](https://technet.microsoft.com/itpro/windows/whats-new/index).
|
||||
- For a detailed list of changes to Windows 10 ITPro TechNet library content, see [Online content change history](#online-content-change-history).
|
||||
|
||||
|
||||
## Windows 10 Enterprise upgrade
|
||||
|
||||
Windows 10 Enterprise E3 launched in the Cloud Solution Provider (CSP) channel on September 1, 2016. Previously, only organizations with a Microsoft Volume Licensing Agreement could deploy Windows 10 Enterprise to their users. With Windows 10 Enterprise E3 in CSP, small and medium-sized organizations can more easily take advantage of Windows 10 Enterprise features.
|
||||
|
||||
For more information, see [Windows 10 Enterprise E3 in CSP Overview](windows-10-enterprise-e3-overview.md)
|
||||
|
||||
|
||||
## Deployment solutions and tools
|
||||
|
||||
### Upgrade Readiness
|
||||
|
||||
The Upgrade Readiness tool moved from public preview to general availability on March 2, 2017.
|
||||
|
||||
Upgrade Readiness helps you ensure that applications and drivers are ready for a Windows 10 upgrade. The solution provides up-to-date application and driver inventory, information about known issues, troubleshooting guidance, and per-device readiness and tracking details.
|
||||
|
||||
The development of Upgrade Readiness has been heavily influenced by input from the community the development of new features is ongoing. To begin using Upgrade Readiness, add it to an existing Operation Management Suite (OMS) workspace or sign up for a new OMS workspace with the Upgrade Readiness solution enabled.
|
||||
|
||||
For more information about Upgrade Readiness, see the following topics:
|
||||
|
||||
- [Windows Analytics blog](https://blogs.technet.microsoft.com/upgradeanalytics/)
|
||||
- [Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md)
|
||||
|
||||
|
||||
### Update Compliance
|
||||
|
||||
Update Compliance helps you to keep Windows 10 devices in your organization secure and up-to-date.
|
||||
|
||||
Update Compliance is a solution built using OMS Logs and Analytics that provides information about installation status of monthly quality and feature updates. Details are provided about the deployment progress of existing updates and the status of future updates. Information is also provided about devices that might need attention to resolve issues.
|
||||
|
||||
For more information about Update Compliance, see [Monitor Windows Updates with Update Compliance](../manage/update-compliance-monitor.md).
|
||||
|
||||
|
||||
### MBR2GPT
|
||||
|
||||
MBR2GPT.EXE converts a disk from Master Boot Record (MBR) to GUID Partition Table (GPT) partition style without modifying or deleting data on the disk. Previously, it was necessary to image, then wipe and reload a disk to change from MBR format to GPT.
|
||||
|
||||
There are many benefits to converting the partition style of a disk to GPT, including the use of larger disk partitions, added data reliability, and faster boot and shutdown speeds. The GPT format also enables you to use the Unified Extensible Firmware Interface (UEFI) which replaces the Basic Input/Output System (BIOS) firmware interface. Security features of Windows 10 that require UEFI mode include: Secure Boot, Early Launch Anti-malware (ELAM) driver, Windows Trusted Boot, Measured Boot, Device Guard, Credential Guard, and BitLocker Network Unlock.
|
||||
|
||||
For more information, see [MBR2GPT.EXE](mbr-to-gpt.md).
|
||||
|
||||
|
||||
### Microsoft Deployment Toolkit (MDT)
|
||||
|
||||
MDT build 884 is available, including support for:
|
||||
- Deployment and upgrade of Windows 10, version 1607 (including Enterprise LTSB and Education editions) and Windows Server 2016.
|
||||
- The Windows ADK for Windows 10, version 1607.
|
||||
- Integration with Configuration Manager version 1606.
|
||||
|
||||
For more information about MDT, see the [MDT resource page](https://technet.microsoft.com/en-US/windows/dn475741).
|
||||
|
||||
|
||||
### Windows Assessment and Deployment Kit (ADK)
|
||||
|
||||
The Windows Assessment and Deployment Kit (Windows ADK) contains tools that can be used by IT Pros to deploy Windows. See the following topics:
|
||||
|
||||
- [What's new in ADK kits and tools](https://msdn.microsoft.com/windows/hardware/commercialize/what-s-new-in-kits-and-tools)
|
||||
- [Windows ADK for Windows 10 scenarios for IT Pros](windows-adk-scenarios-for-it-pros.md)
|
||||
|
||||
|
||||
## Testing and validation guidance
|
||||
|
||||
### Windows 10 deployment proof of concept (PoC)
|
||||
|
||||
The Windows 10 PoC guide enables you to test Windows 10 deployment in a virtual environment and become familiar with deployment tools such as MDT and Configuration Manager. The PoC guide provides step-by-step instructions for installing and using Hyper-V to create a virtual lab environment. The guide makes extensive use of Windows PowerShell to streamline each phase of the installation and setup.
|
||||
|
||||
For more information, see the following guides:
|
||||
|
||||
- [Step by step guide: Configure a test lab to deploy Windows 10](windows-10-poc.md)
|
||||
- [Deploy Windows 10 in a test lab using Microsoft Deployment Toolkit](windows-10-poc-mdt.md)
|
||||
- [Deploy Windows 10 in a test lab using System Center Configuration Manager](windows-10-poc-sc-config-mgr.md)
|
||||
|
||||
|
||||
## Troubleshooting guidance
|
||||
|
||||
[Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md) was published in October of 2016 and will continue to be updated with new fixes. The topic provides a detailed explanation of the Windows 10 upgrade process and instructions on how to locate, interpret, and resolve specific errors that can be encountered during the upgrade process.
|
||||
|
||||
|
||||
## Online content change history
|
||||
|
||||
The following topics provide a change history for Windows 10 ITPro TechNet library content related to deploying and using Windows 10.
|
||||
|
||||
[Change history for Deploy Windows 10](change-history-for-deploy-windows-10.md)
|
||||
<BR>[Change history for Plan for Windows 10 deployment](../plan/change-history-for-plan-for-windows-10-deployment.md)
|
||||
<BR>[Change history for Manage and update Windows 10](../manage/change-history-for-manage-and-update-windows-10.md)
|
||||
<BR>[Change history for Keep Windows 10 secure](../keep-secure/change-history-for-keep-windows-10-secure.md)
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
[Overview of Windows as a service](../manage/waas-overview.md)
|
||||
<BR>[Windows 10 deployment considerations](../plan/windows-10-deployment-considerations.md)
|
||||
<BR>[Windows 10 release information](https://technet.microsoft.com/en-us/windows/release-info.aspx)
|
||||
<BR>[Windows 10 Specifications & Systems Requirements](https://www.microsoft.com/en-us/windows/windows-10-specifications)
|
||||
<BR>[Windows 10 upgrade paths](windows-10-upgrade-paths.md)
|
||||
<BR>[Windows 10 deployment tools](windows-deployment-scenarios-and-tools.md)
|
||||
|
||||
|
||||
@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Deploy Windows 10 using PXE and Configuration Manager (Windows 10)
|
||||
description: In this topic, you will learn how to deploy Windows 10 using Microsoft System Center 2012 R2 Configuration Manager deployment packages and task sequences.
|
||||
ms.assetid: fb93f514-5b30-4f4b-99dc-58e6860009fa
|
||||
keywords: deployment, image, UEFI, task sequence
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Deploy Windows 10 using PXE and Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
In this topic, you will learn how to deploy Windows 10 using Microsoft System Center 2012 R2 Configuration Manager deployment packages and task sequences. This topic will walk you through the process of deploying the Windows 10 Enterprise image to a Unified Extensible Firmware Interface (UEFI) machine named PC0001.
|
||||
|
||||
For the purposes of this topic, we will use two additional machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. DC01, CM01, and PC0001 are all 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).
|
||||
|
||||
1. Start the PC0001 machine. At the Pre-Boot Execution Environment (PXE) boot menu, press **Enter** to allow it to PXE boot.
|
||||
|
||||
|
||||
|
||||
Figure 31. PXE booting PC0001.
|
||||
|
||||
2. On the **Welcome to the Task Sequence Wizard** page, type in the password **Passw0rd!** and click **Next**.
|
||||
|
||||
3. On the **Select a task sequence to run** page, select **Windows 10 Enterprise x64 RTM** and click **Next**.
|
||||
|
||||
4. On the **Edit Task Sequence Variables** page, double-click the **OSDComputerName** variable, and in the **Value** field, type **PC0001** and click **OK**. Then click **Next**.
|
||||
|
||||
|
||||
|
||||
Figure 32. Typing in the computer name.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
|
||||
|
||||
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
|
||||
|
||||
[Create a task sequence with Configuration Manager and MDT](create-a-task-sequence-with-configuration-manager-and-mdt.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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,106 +0,0 @@
|
||||
---
|
||||
title: Deploy Windows 10 with System Center 2012 R2 Configuration Manager (Windows 10)
|
||||
description: If you have Microsoft System Center 2012 R2 Configuration Manager in your environment, you will most likely want to use it to deploy Windows 10.
|
||||
ms.assetid: eacd7b7b-dde0-423d-97cd-29bde9e8b363
|
||||
keywords: deployment, custom, boot
|
||||
ms.prod: w10
|
||||
localizationpriority: high
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Deploy Windows 10 with System Center 2012 R2 Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
If you have Microsoft System Center 2012 R2 Configuration Manager in your environment, you will most likely want to use it to deploy Windows 10. This topic will show you how to set up Configuration Manager for operating system deployment and how to integrate Configuration Manager with the Microsoft Deployment Toolkit (MDT).
|
||||
|
||||
For the purposes of this topic, we will use four machines: DC01, CM01, PC0003, and PC0004. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 standard. PC0003 and PC0004 are machines with Windows 7 SP1, on which Windows 10 will be deployed via both refresh and replace scenarios. In addition to these four ready-made machines, you could also include a few blank virtual machines to be used for bare-metal deployments. DC01, CM01, PC003, and PC0004 are all 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).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
## In this section
|
||||
|
||||
|
||||
- [Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
- [Prepare for Zero Touch Installation of Windows 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)
|
||||
|
||||
- [Finalize the operating system configuration for Windows 10 deployment with Configuration Manager](finalize-the-os-configuration-for-windows-10-deployment-with-configuration-manager.md)
|
||||
|
||||
- [Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-10-using-pxe-and-configuration-manager.md)
|
||||
|
||||
- [Monitor the Windows 10 deployment with Configuration Manager](monitor-windows-10-deployment-with-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)
|
||||
|
||||
## Components of Configuration Manager operating system deployment
|
||||
|
||||
|
||||
Operating system deployment with Configuration Manager is part of the normal software distribution infrastructure, but there are additional components. For example, operating system deployment in Configuration Manager may use the State Migration Point role, which is not used by normal application deployment in Configuration Manager. This section describes the Configuration Manager components involved with the deployment of an operating system, such as Windows 10.
|
||||
|
||||
- **State migration point (SMP).** The state migration point is used to store user state migration data during computer replace scenarios.
|
||||
|
||||
- **Distribution point (DP).** The distribution point is used to store all packages in Configuration Manager, including the operating system deployment-related packages.
|
||||
|
||||
- **Software update point (SUP).** The software update point, which is normally used to deploy updates to existing machines, also can be used to update an operating system as part of the deployment process. You also can use offline servicing to update the image directly on the Configuration Manager server.
|
||||
|
||||
- **Reporting services point.** The reporting services point can be used to monitor the operating system deployment process.
|
||||
|
||||
- **Boot images.** Boot images are the Windows Preinstallation Environment (Windows PE) images Configuration Manager uses to start the deployment.
|
||||
|
||||
- **Operating system images.** The operating system image package contains only one file, the custom .wim image. This is typically the production deployment image.
|
||||
|
||||
- **Operating system installers.** The operating system installers were originally added to create reference images using Configuration Manager. Instead, we recommend that you use MDT Lite Touch to create your reference images. For more information on how to create a reference image, see [Create a Windows 10 reference image](create-a-windows-10-reference-image.md).
|
||||
|
||||
- **Drivers.** Like MDT Lite Touch, Configuration Manager also provides a repository (catalog) of managed device drivers.
|
||||
|
||||
- **Task sequences.** The task sequences in Configuration Manager look and feel pretty much like the sequences in MDT Lite Touch, and they are used for the same purpose. However, in Configuration Manager the task sequence is delivered to the clients as a policy via the Management Point (MP). MDT provides additional task sequence templates to Configuration Manager.
|
||||
|
||||
**Note** Configuration Manager SP1 along with the Windows Assessment and Deployment Kit (ADK) for Windows 10 are required to support management and deployment of Windows 10.
|
||||
|
||||
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
- [Microsoft Deployment Toolkit downloads and resources](https://go.microsoft.com/fwlink/p/?LinkId=618117)
|
||||
|
||||
- [Windows deployment tools](windows-deployment-scenarios-and-tools.md)
|
||||
|
||||
- [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md)
|
||||
|
||||
- [Upgrade to Windows 10 with the Microsoft Deployment Toolkit](upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md)
|
||||
|
||||
- [Deploy Windows To Go in your organization](deploy-windows-to-go.md)
|
||||
|
||||
- [Sideload Windows Store apps](http://technet.microsoft.com/library/dn613831.aspx)
|
||||
|
||||
- [Windows ADK for Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=526803)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,93 +0,0 @@
|
||||
---
|
||||
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).
|
||||
ms.assetid: 837f009c-617e-4b3f-9028-2246067ee0fb
|
||||
keywords: deploy, tools, configure, script
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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).
|
||||
|
||||
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 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](https://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](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-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. 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. 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
|
||||
- Roles: DNS, DHCP, and Domain Controller
|
||||
- **MDT01.** 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: MDT01
|
||||
- IP Address: 192.168.1.210
|
||||
- **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](https://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](https://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](https://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](https://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)
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,192 +0,0 @@
|
||||
---
|
||||
title: Finalize the operating system configuration for Windows 10 deployment with Configuration Manager (Windows 10)
|
||||
description: This topic walks you through the steps to finalize the configuration of your Windows 10 operating deployment, which includes enablement of the optional Microsoft Deployment Toolkit (MDT) monitoring for Microsoft System Center 2012 R2 Configuration Manager, logs folder creation, rules configuration, content distribution, and deployment of the previously created task sequence.
|
||||
ms.assetid: 38b55fa8-e717-4689-bd43-8348751d493e
|
||||
keywords: configure, deploy, upgrade
|
||||
ms.prod: w10
|
||||
localizationpriority: high
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: mtniehaus
|
||||
---
|
||||
|
||||
# Finalize the operating system configuration for Windows 10 deployment with Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
This topic walks you through the steps to finalize the configuration of your Windows 10 operating deployment, which includes enablement of the optional Microsoft Deployment Toolkit (MDT) monitoring for Microsoft System Center 2012 R2 Configuration Manager, logs folder creation, rules configuration, content distribution, and deployment of the previously created task sequence.
|
||||
|
||||
For the purposes of this topic, we will use two machines: DC01 and CM01. DC01 is a domain controller and CM01 is a machine running Windows Server 2012 R2 Standard. Both are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
## <a href="" id="sec01"></a>Enable MDT monitoring
|
||||
|
||||
|
||||
This section will walk you through the process of creating the E:\\MDTProduction deployment share using the MDT Deployment Workbench to enable monitoring for Configuration Manager.
|
||||
|
||||
1. On CM01, using the Deployment Workbench, right-click **Deployment Shares** and select **New Deployment Share**. Use the following settings for the New Deployment Share Wizard:
|
||||
|
||||
* Deployment share path: E:\\MDTProduction
|
||||
|
||||
* Share name: MDTProduction$
|
||||
|
||||
* Deployment share description: MDT Production
|
||||
|
||||
* Options: <default settings>
|
||||
|
||||
2. Right-click the **MDT Production** deployment share, and select **Properties**. In the **Monitoring** tab, select the **Enable monitoring for this deployment share** check box, and click **OK**.
|
||||
|
||||
|
||||
|
||||
*Figure 26. Enable MDT monitoring for Configuration Manager*
|
||||
|
||||
## <a href="" id="sec02"></a>Create and share the Logs folder
|
||||
|
||||
|
||||
To support additional server-side logging in Configuration Manager, you create and share the E:\\Logs folder on CM01 using Windows PowerShell. Then in the next step, you enable server-side logging by modifying the CustomSettings.ini file used by the Configuration Manager task sequence.
|
||||
|
||||
1. On CM01, start an elevated Windows PowerShell prompt (run as Administrator).
|
||||
|
||||
2. Type the following commands, pressing **Enter** after each one:
|
||||
|
||||
``` syntax
|
||||
New-Item -Path E:\Logs -ItemType directory
|
||||
New-SmbShare -Name Logs$ -Path E:\Logs -ChangeAccess EVERYONE
|
||||
icacls E:\Logs /grant '"CM_NAA":(OI)(CI)(M)'
|
||||
```
|
||||
|
||||
## <a href="" id="sec03"></a>Configure the rules (Windows 10 x64 Settings package)
|
||||
|
||||
|
||||
This section will show you how to configure the rules (the Windows 10 x64 Settings package) to support the Contoso environment.
|
||||
|
||||
1. On CM01, using File Explorer, navigate to the **E:\\Sources\\OSD\\Settings\\Windows 10 x64 Settings** folder.
|
||||
|
||||
2. Using Notepad, edit the CustomSetting.ini file with the following settings:
|
||||
|
||||
``` syntax
|
||||
[Settings]
|
||||
Priority=Default
|
||||
Properties=OSDMigrateConfigFiles,OSDMigrateMode
|
||||
[Default]
|
||||
DoCapture=NO
|
||||
ComputerBackupLocation=NONE
|
||||
MachineObjectOU=ou=Workstations,ou=Computers,ou=Contoso,dc=contoso,dc=com
|
||||
OSDMigrateMode=Advanced
|
||||
OSDMigrateAdditionalCaptureOptions=/ue:*\* /ui:CONTOSO\*
|
||||
OSDMigrateConfigFiles=Miguser.xml,Migapp.xml
|
||||
SLSHARE=\\CM01\Logs$
|
||||
EventService=http://CM01:9800
|
||||
ApplyGPOPack=NO
|
||||
```
|
||||
|
||||
|
||||
|
||||
*Figure 27. The Settings package, holding the rules and the Unattend.xml template used during deployment*
|
||||
|
||||
3. Update the distribution point for the **Windows 10 x64 Settings** package by right-clicking the **Windows 10 x64 Settings** package and selecting **Update Distribution Points**.
|
||||
|
||||
>[!NOTE]
|
||||
>Although you have not yet added a distribution point, you still need to select Update Distribution Points. That process also updates the Configuration Manager 2012 content library with changes.
|
||||
|
||||
|
||||
|
||||
## <a href="" id="sec04"></a>Distribute content to the CM01 distribution portal
|
||||
|
||||
|
||||
In Configuration Manager, you can distribute all packages needed by a task sequence in a single task. In this section, you distribute packages that have not yet been distributed to the CM01 distribution point.
|
||||
|
||||
1. **On CM01, using the Configuration Manager Console**, select **Task Sequences**, right-click the **Windows 10 Enterprise x64 RTM** task sequence, and select **Distribute Content.**
|
||||
|
||||
2. In the Distribute Content Wizard, add the CM01 distribution point, and complete the wizard.
|
||||
|
||||
3. Using Configuration Manager Trace, verify the distribution to the CM01 distribution point by reviewing the distmgr.log file, or use the Distribution Status / Content Status option in the Monitoring workspace. Do not continue until you see all the new packages being distributed successfully.
|
||||
|
||||
## <a href="" id="sec05"></a>Create a deployment for the task sequence
|
||||
|
||||
|
||||
This sections provides steps to help you create a deployment for the task sequence.
|
||||
|
||||
1. On CM01, using the Configuration Manager Console, select **Task Sequences**, right-click **Windows 10 Enterprise x64 RTM**, and then select **Deploy**.
|
||||
|
||||
2. On the **General** page, select the **All Unknown Computers** collection and click **Next**.
|
||||
|
||||
3. On the **Deployment Settings** page, use the following settings and then click **Next**:
|
||||
|
||||
* Purpose: Available
|
||||
|
||||
* Make available to the following: Only media and PXE
|
||||
|
||||
|
||||
|
||||
*Figure 28. Configure the deployment settings*
|
||||
|
||||
4. On the **Scheduling** page, accept the default settings and click **Next**.
|
||||
|
||||
5. On the **User Experience** page, accept the default settings and click **Next**.
|
||||
|
||||
6. On the **Alerts** page, accept the default settings and click **Next**.
|
||||
|
||||
7. On the **Distribution Points** page, accept the default settings, click **Next** twice, and then click **Close**.
|
||||
|
||||
|
||||
|
||||
*Figure 29. The Windows 10 Enterprise x64 RTM task sequence deployed to the All Unknown Computers collections available for media and PXE*
|
||||
|
||||
## <a href="" id="sec06"></a>Configure Configuration Manager to prompt for the computer name during deployment (optional)
|
||||
|
||||
|
||||
You can have Configuration Manager prompt you for a computer name or you can use rules to generate a computer name. For more details on how to do this, see [Configure MDT settings](configure-mdt-settings.md).
|
||||
|
||||
This section provides steps to help you configure the All Unknown Computers collection to have Configuration Manager prompt for computer names.
|
||||
|
||||
1. Using the Configuration Manager Console, in the Asset and Compliance workspace, select **Device Collections**, right-click **All Unknown Computers**, and select **Properties**.
|
||||
|
||||
2. In the **Collection Variables** tab, create a new variable with the following settings:
|
||||
|
||||
* Name: OSDComputerName
|
||||
|
||||
* Clear the **Do not display this value in the Configuration Manager console** check box.
|
||||
|
||||
3. Click **OK**.
|
||||
|
||||
>[!NOTE]
|
||||
>Configuration Manager can prompt for information in many ways. Using a collection variable with an empty value is just one of them. Another option is the User-Driven Installation (UDI) wizard.
|
||||
|
||||
|
||||
|
||||
*Figure 30. Configure a collection variable*
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Integrate Configuration Manager with MDT](integrate-configuration-manager-with-mdt.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-10-operating-system-image-using-configuration-manager.md)
|
||||
|
||||
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-10-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-10-deployment-with-windows-pe-using-configuration-manager.md)
|
||||
|
||||
[Create a task sequence with Configuration Manager and MDT](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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,50 +0,0 @@
|
||||
---
|
||||
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), as part of a Windows operating system deployment.
|
||||
ms.assetid: a256442c-be47-4bb9-a105-c831f58ce3ee
|
||||
keywords: deploy, image, feature, install, tools
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
localizationpriority: high
|
||||
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), 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 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, 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).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
## In this section
|
||||
|
||||
- [Key features in MDT](key-features-in-mdt.md)
|
||||
- [MDT Lite Touch components](mdt-lite-touch-components.md)
|
||||
- [Prepare for deployment with MDT](prepare-for-windows-deployment-with-mdt.md)
|
||||
|
||||
## Related topics
|
||||
|
||||
[Microsoft Deployment Toolkit downloads and documentation](https://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](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-settings.md)
|
||||
@ -1,82 +0,0 @@
|
||||
---
|
||||
title: Getting Started with the User State Migration Tool (USMT) (Windows 10)
|
||||
description: Getting Started with the User State Migration Tool (USMT)
|
||||
ms.assetid: 506ff1d2-94b8-4460-8672-56aad963504b
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: greg-lindsay
|
||||
---
|
||||
|
||||
# Getting Started with the User State Migration Tool (USMT)
|
||||
This topic outlines the general process that you should follow to migrate files and settings.
|
||||
|
||||
## In this Topic
|
||||
- [Step 1: Plan Your Migration](#step-1-plan-your-migration)
|
||||
|
||||
- [Step 2: Collect files and settings from the source computer](#step-2-collect-files-and-settings-from-the-source-computer)
|
||||
|
||||
- [Step 3: Prepare the destination computer and restore files and settings](#step-3-prepare-the-destination-computer-and-restore-files-and-settings)
|
||||
|
||||
## Step 1: Plan your migration
|
||||
1. [Plan Your Migration](usmt-plan-your-migration.md). Depending on whether your migration scenario is refreshing or replacing computers, you can choose an online migration or an offline migration using Windows Preinstallation Environment (WinPE) or the files in the Windows.old directory. For more information, see [Common Migration Scenarios](usmt-common-migration-scenarios.md).
|
||||
|
||||
2. [Determine What to Migrate](usmt-determine-what-to-migrate.md). Data you might consider migrating includes end-user information, applications settings, operating-system settings, files, folders, and registry keys.
|
||||
|
||||
3. Determine where to store data. Depending on the size of your migration store, you can store the data remotely, locally in a hard-link migration store or on a local external storage device, or directly on the destination computer. For more information, see [Choose a Migration Store Type](usmt-choose-migration-store-type.md).
|
||||
|
||||
4. Use the **/GenMigXML** command-line option to determine which files will be included in your migration, and to determine whether any modifications are necessary. For more information see [ScanState Syntax](usmt-scanstate-syntax.md)
|
||||
|
||||
5. Modify copies of the Migration.xml and MigDocs.xml files and create custom .xml files, if it is required. To modify the migration behavior, such as migrating the **Documents** folder but not the **Music** folder, you can create a custom .xml file or modify the rules in the existing migration .xml files. The document finder, or **MigXmlHelper.GenerateDocPatterns** helper function, can be used to automatically find user documents on a computer without creating extensive custom migration .xml files.
|
||||
|
||||
**Important**
|
||||
We recommend that you always make and modify copies of the .xml files included in User State Migration Tool (USMT) 10.0. Never modify the original .xml files.
|
||||
|
||||
You can use the MigXML.xsd file to help you write and validate the .xml files. For more information about how to modify these files, see [USMT XML Reference](usmt-xml-reference.md).
|
||||
|
||||
6. Create a [Config.xml File](usmt-configxml-file.md) if you want to exclude any components from the migration. To create this file, use the [ScanState Syntax](usmt-scanstate-syntax.md) option together with the other .xml files when you use the **ScanState** command. For example, the following command creates a Config.xml file by using the MigDocs and MigApp.xml files:
|
||||
|
||||
`scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scanstate.log`
|
||||
|
||||
7. Review the migration state of the components listed in the Config.xml file, and specify `migrate=no` for any components that you do not want to migrate.
|
||||
|
||||
## Step 2: Collect files and settings from the source computer
|
||||
1. Back up the source computer.
|
||||
|
||||
2. Close all applications. If some applications are running when you run the **ScanState** command, USMT might not migrate all of the specified data. For example, if Microsoft® Office Outlook® is open, USMT might not migrate PST files.
|
||||
|
||||
**Note**
|
||||
USMT will fail if it cannot migrate a file or setting unless you specify the **/C** option. When you specify the **/C** option, USMT will ignore the errors, and log an error every time that it encounters a file that is being used that USMT did not migrate. You can use the **<ErrorControl>** section in the Config.xml file to specify which errors should be ignored, and which should cause the migration to fail.
|
||||
|
||||
3. Run the **ScanState** command on the source computer to collect files and settings. You should specify all of the .xml files that you want the **ScanState** command to use. For example,
|
||||
|
||||
`scanstate \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log`
|
||||
|
||||
**Note**
|
||||
If the source computer is running Windows 7, or Windows 8, you must run the **ScanState** command in **Administrator** mode. To run in **Administrator** mode, right-click **Command Prompt**, and then click **Run As Administrator**. If the source computer is running Windows XP, you must run the **ScanState** command from an account that has administrative credentials. For more information about the how the **ScanState** command processes and stores the data, see [How USMT Works](usmt-how-it-works.md).
|
||||
|
||||
4. Run the **USMTUtils** command with the **/Verify** option to ensure that the store you created is not corrupted.
|
||||
|
||||
## Step 3: Prepare the destination computer and restore files and settings
|
||||
1. Install the operating system on the destination computer.
|
||||
|
||||
2. Install all applications that were on the source computer. Although it is not always required, we recommend installing all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.
|
||||
|
||||
**Note**
|
||||
The application version that is installed on the destination computer should be the same version as the one on the source computer. USMT does not support migrating the settings for an older version of an application to a newer version. The exception to this is Microsoft® Office, which USMT can migrate from an older version to a newer version.
|
||||
|
||||
3. Close all applications. If some applications are running when you run the **LoadState** command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
|
||||
|
||||
**Note**
|
||||
Use **/C** to continue your migration if errors are encountered, and use the **<ErrorControl>** section in the Config.xml file to specify which errors should be ignored, and which errors should cause the migration to fail.
|
||||
|
||||
4. Run the **LoadState** command on the destination computer. Specify the same set of .xml files that you specified when you used the **ScanState** command. However, you do not have to specify the Config.xml file, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, modify the Config.xml file and specify the updated file by using the **LoadState** command. Then, the **LoadState** command will migrate only the files and settings that you want to migrate. For more information about the how the **LoadState** command processes and migrates data, see [How USMT Works](usmt-how-it-works.md).
|
||||
|
||||
For example, the following command migrates the files and settings:
|
||||
|
||||
`loadstate \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log`
|
||||
|
||||
**Note**
|
||||
Run the **LoadState** command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
|
||||
|
||||
5. Log off after you run the **LoadState** command. Some settings (for example, fonts, wallpaper, and screen saver settings) will not take effect until the next time that the user logs on.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 136 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 90 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 818 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 121 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 188 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 140 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 238 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user