mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 21:37:22 +00:00
test migration of everything
This commit is contained in:
Brian Lich
parent
db8fb9a516
commit
afab4332a6
@ -1 +1,136 @@
|
||||
#[Deploy](placeholder.md)
|
||||
# [Deploy Windows 10](deploy-windows-10.md)
|
||||
## [Change history for Deploy Windows 10](change-history-for-deploy-windows-10.md)
|
||||
## [Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
|
||||
## [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-81-with-the-microsoft-deployment-toolkit.md)
|
||||
### [Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit--mdt-.md)
|
||||
#### [Key features in MDT 2013 Update 1](key-features-in-mdt-2013.md)
|
||||
#### [MDT 2013 Update 1 Lite Touch components](mdt-2013-lite-touch-components.md)
|
||||
#### [Prepare for deployment with MDT 2013 Update 1](prepare-for-deployment-with-mdt-2013.md)
|
||||
### [Create a Windows 10 reference image](create-a-windows-81-reference-image.md)
|
||||
### [Deploy a Windows 10 image using MDT 2013 Update 1](deploy-a-windows-81-image-using-mdt-2013.md)
|
||||
### [Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-81-deployment.md)
|
||||
### [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
### [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
### [Configure MDT settings](configure-mdt-2013-settings.md)
|
||||
#### [Set up MDT for BitLocker](set-up-mdt-2013-for-bitlocker.md)
|
||||
#### [Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
#### [Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
|
||||
#### [Simulate a Windows 10 deployment in a test environment](simulate-a-windows-81-deployment-in-a-test-environment.md)
|
||||
#### [Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-81-deployment-information.md)
|
||||
#### [Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
|
||||
#### [Use web services in MDT](use-web-services-in-mdt-2013.md)
|
||||
#### [Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
|
||||
## [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](deploy-windows-81-with-system-center-2012-r2-configuration-manager.md)
|
||||
### [Integrate Configuration Manager with MDT 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
### [Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
### [Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
### [Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-using-configuration-manager.md)
|
||||
### [Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-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-operating-system-configuration-for-windows-81-deployment-with-configuration-manager.md)
|
||||
### [Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-81-using-pxe-and-configuration-manager.md)
|
||||
### [Monitor the Windows 10 deployment with Configuration Manager](monitor-the-windows-81-deployment-with-configuration-manager.md)
|
||||
### [Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
### [Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
## [Upgrade to Windows 10 with the Microsoft Deployment Toolkit](upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md)
|
||||
## [Upgrade to Windows 10 with System Center Configuration Manager](upgrade-to-windows-10-with-system-center-configuraton-manager.md)
|
||||
## [Windows 10 edition upgrade](windows-10-edition-upgrades.md)
|
||||
## [Deploy Windows To Go in your organization](deploy-windows-to-go-in-your-organization-small-scenario.md)
|
||||
## [Update Windows 10 images with provisioning packages](update-windows-10-images-with-provisioning-packages.md)
|
||||
## [Sideload apps in Windows 10](sideload-apps-in-windows-10.md)
|
||||
## [Volume Activation [client]](volume-activation-for-windows-81-client.md)
|
||||
### [Plan for volume activation [client]](plan-for-volume-activation-client.md)
|
||||
### [Activate using Key Management Service [client]](activate-using-key-management-service-client.md)
|
||||
### [Activate using Active Directory-based activation [client]](activate-using-active-directory-based-activation-client.md)
|
||||
### [Activate clients running Windows 10](activate-clients-running-windows-81-client.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 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--vamt--overview-vamt-30-win8.md)
|
||||
#### [Introduction to VAMT](introduction-to-vamtvamt-30-win8.md)
|
||||
#### [Active Directory-Based Activation Overview](active-directory-based-activation-overview.md)
|
||||
#### [Install and Configure VAMT](install-and-configure-vamt-vamt-30-win8.md)
|
||||
##### [VAMT Requirements](vamt-requirements-vamt-30-win8.md)
|
||||
##### [Install VAMT](install-vamt-vamt-30-win8.md)
|
||||
##### [Configure Client Computers](configure-client-computers-vamt-30-win8.md)
|
||||
#### [Add and Manage Products](add-and-manage-products-vamt-30-win8.md)
|
||||
##### [Add and Remove Computers](add-and-remove-computers-vamt-30-win8.md)
|
||||
##### [Update Product Status](update-product-status-vamt-30-win8.md)
|
||||
##### [Remove Products](remove-products-vamt-30-win8.md)
|
||||
#### [Manage Product Keys](manage-product-keys-vamt-30-win8.md)
|
||||
##### [Add and Remove a Product Key](add-and-remove-a-product-key-vamt-30-win8.md)
|
||||
##### [Install a Product Key](install-a-product-key-vamt-30-win8.md)
|
||||
##### [Install a KMS Client Key](install-a-kms-client-key-vamt-30-win8.md)
|
||||
#### [Manage Activations](manage-activations-vamt-30-win8.md)
|
||||
##### [Perform Online Activation](perform-online-activation-vamt-30-win8.md)
|
||||
##### [Perform Proxy Activation](perform-proxy-activation-vamt-30-win8.md)
|
||||
##### [Perform KMS Activation](perform-kms-activation-vamt-30-win8.md)
|
||||
##### [Perform Local Reactivation](perform-local-reactivation-vamt-30-win8.md)
|
||||
##### [Activate an Active Directory Forest Online](activate-an-active-directory-forest-online.md)
|
||||
##### [Activate by Proxy an Active Directory Forest](activate-by-proxy-an-active-directory-forest.md)
|
||||
#### [Manage VAMT Data](manage-vamt-data-vamt-30-win8.md)
|
||||
##### [Import and Export VAMT Data](import-and-export-vamt-data-vamt-30-win8.md)
|
||||
##### [Use VAMT in Windows PowerShell](use-vamt-in-windows-powershell.md)
|
||||
#### [VAMT Step-by-Step Scenarios](vamt-step-by-step-scenarios-vamt-30-win8.md)
|
||||
##### [Scenario 1: Online Activation](scenario-1-online-activation-vamt-30-win8.md)
|
||||
##### [Scenario 2: Proxy Activation](scenario-2-proxy-activation-vamt-30-win8.md)
|
||||
##### [Scenario 3: KMS Client Activation](scenario-3-kms-client-activation-vamt-30-win8.md)
|
||||
#### [VAMT Known Issues](vamt-known-issues-vamt-30-win8.md)
|
||||
### [User State Migration Tool (USMT) Technical Reference](user-state-migration-tool--usmt--technical-reference.md)
|
||||
#### [User State Migration Tool (USMT) Overview Topics](user-state-migration-tool--usmt--overview-topics.md)
|
||||
##### [User State Migration Tool (USMT) Overview](user-state-migration-tool--usmt--overview.md)
|
||||
##### [Getting Started with the User State Migration Tool (USMT)](getting-started-with-the-user-state-migration-tool--usmt-.md)
|
||||
##### [Windows Upgrade and Migration Considerations](windows-upgrade-and-migration-considerations-win8.md)
|
||||
#### [User State Migration Tool (USMT) How-to topics](user-state-migration-tool--usmt--how-to-topics.md)
|
||||
##### [Exclude Files and Settings](exclude-files-and-settings-usmt.md)
|
||||
##### [Extract Files from a Compressed USMT Migration Store](extract-files-from-a-compressed-usmt-migration-store.md)
|
||||
##### [Include Files and Settings](include-files-and-settings-usmt.md)
|
||||
##### [Migrate Application Settings](migrate-application-settings.md)
|
||||
##### [Migrate EFS Files and Certificates](migrate-efs-files-and-certificates-umst.md)
|
||||
##### [Migrate User Accounts](migrate-user-accounts-usmt.md)
|
||||
##### [Reroute Files and Settings](reroute-files-and-settings-usmt.md)
|
||||
##### [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
|
||||
#### [User State Migration Tool (USMT) Troubleshooting](user-state-migration-tool--usmt--troubleshooting.md)
|
||||
##### [Common Issues](common-issues-usmt-win8.md)
|
||||
##### [Frequently Asked Questions](frequently-asked-questions-usmt-win7-usmt-win8.md)
|
||||
##### [Log Files](log-files-usmt-win7-usmt-win8.md)
|
||||
##### [Return Codes](return-codes-usmt-win8.md)
|
||||
##### [USMT Resources](usmt-resources-usmt-win8.md)
|
||||
#### [User State Migration Toolkit (USMT) Reference](user-state-migration-toolkit--usmt--reference.md)
|
||||
##### [USMT Requirements](usmt-requirements-usmt-win7-usmt-win8.md)
|
||||
##### [USMT Best Practices](usmt-best-practices-usmt-win7-usmt-win8.md)
|
||||
##### [How USMT Works](how-usmt-works-usmt-win7-usmt-win8.md)
|
||||
##### [Plan Your Migration](plan-your-migration-usmt-win7-usmt-win8.md)
|
||||
###### [Common Migration Scenarios](common-migration-scenarios-usmt-win7-usmt-win8.md)
|
||||
###### [What Does USMT Migrate?](what-does-usmt-migrate-usmt-win7-usmt-win8.md)
|
||||
###### [Choose a Migration Store Type](choose-a-migration-store-type-usmt-win7-usmt-win8.md)
|
||||
####### [Migration Store Types Overview](migration-store-types-overview.md)
|
||||
####### [Estimate Migration Store Size](estimate-migration-store-size-usmt-win7-usmt-win8.md)
|
||||
####### [Hard-Link Migration Store](hard-link-migration-store-usmt-win8.md)
|
||||
####### [Migration Store Encryption](migration-store-encryption-usmt-win8.md)
|
||||
###### [Determine What to Migrate](determine-what-to-migrate-usmt-win7-usmt-win8.md)
|
||||
####### [Identify Users](identify-users-usmt-win7-usmt-win8.md)
|
||||
####### [Identify Applications Settings](identify-applications-settings-usmt-win7-usmt-win8.md)
|
||||
####### [Identify Operating System Settings](identify-operating-system-settings-usmt-win7-usmt-win8.md)
|
||||
####### [Identify File Types, Files, and Folders](identify-file-types-files-and-folders-usmt-win8.md)
|
||||
###### [Test Your Migration](test-your-migration-usmt-win7-usmt-win8.md)
|
||||
##### [User State Migration Tool (USMT) Command-line Syntax](user-state-migration-tool--usmt--command-line-syntax.md)
|
||||
###### [ScanState Syntax](scanstate-syntax-usmt-win7-usmt-win8.md)
|
||||
###### [LoadState Syntax](loadstate-syntax-usmt-win7-usmt-win8.md)
|
||||
###### [UsmtUtils Syntax](usmtutils-syntax-usmt-win8.md)
|
||||
##### [USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
###### [Understanding Migration XML Files](understanding-migration-xml-files.md)
|
||||
###### [Config.xml File](configxml-file-usmt-win7-usmt-win8.md)
|
||||
###### [Customize USMT XML Files](customize-usmt-xml-files-usmt-win7-usmt-win8.md)
|
||||
###### [Custom XML Examples](custom-xml-examples-usmt-win7-usmt-win8.md)
|
||||
###### [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md)
|
||||
###### [General Conventions](general-conventions-usmt-win7-usmt-win8.md)
|
||||
###### [XML File Requirements](xml-file-requirements.md)
|
||||
###### [Recognized Environment Variables](recognized-environment-variables-usmt-win7-usmt-win8.md)
|
||||
###### [XML Elements Library](xml-elements-library-usmt-win7-usmt-win8.md)
|
||||
##### [Offline Migration Reference](offline-migration-reference.md)
|
||||
|
||||
|
||||
69
windows/deploy/activate-an-active-directory-forest-online.md
Normal file
69
windows/deploy/activate-an-active-directory-forest-online.md
Normal file
@ -0,0 +1,69 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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-1-online-activation-vamt-30-win8.md)
|
||||
|
||||
[Add and Remove Computers](add-and-remove-computers-vamt-30-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,88 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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:
|
||||
|
||||
1. 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.
|
||||
|
||||
2. VAMT has administrative permissions to the Active Directory domain.
|
||||
|
||||
### To Perform an Active Directory Forest Proxy Activation
|
||||
|
||||
1. Open VAMT.
|
||||
|
||||
2. In the left-side pane, click the **Active Directory-Based Activation** node.
|
||||
|
||||
3. In the right-side **Actions** pane, click **Proxy activate forest** to open the **Install Product Key** dialog box.
|
||||
|
||||
4. In the **Install Product Key** dialog box, select the KMS Host key (CSVLK) that you want to activate.
|
||||
|
||||
5. If you want to rename the ADBA object, enter a new Active Directory-Based Activation Object name.
|
||||
|
||||
**Important**
|
||||
If you want to rename the ADBA object, you must do it now. After you click **Install Key**, the name cannot be changed.
|
||||
|
||||
|
||||
|
||||
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**.
|
||||
|
||||
8. 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-and-remove-computers-vamt-30-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
146
windows/deploy/activate-clients-running-windows-81-client.md
Normal file
146
windows/deploy/activate-clients-running-windows-81-client.md
Normal file
@ -0,0 +1,146 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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](http://go.microsoft.com/fwlink/p/?LinkId=618644)
|
||||
|
||||
After you have configured Key Management Service (KMS) or Active Directory-based activation on your network, activating a client running Windows 10 is easy. If the computer has been configured with a Generic Volume License Key (GVLK), neither IT nor the user need take any action. It just works.
|
||||
|
||||
Enterprise edition images and installation media should already be configured with the GVLK. When the client computer starts, the Licensing service examines the current licensing condition of the computer. If activation or reactivation is required, the following sequence occurs:
|
||||
|
||||
1. If the computer is a member of a domain, it asks a domain controller for a volume activation object. If Active Directory-based activation is configured, the domain controller returns the object. If the object matches the edition of the software that is installed and the computer has a matching GVLK, the computer is activated (or reactivated), and it will not need to be activated again for 180 days, although the operating system will attempt reactivation at much shorter, regular intervals.
|
||||
|
||||
2. If the computer is not a member of a domain or if the volume activation object is not available, the computer will issue a DNS query to attempt to locate a KMS server. If a KMS server can be contacted, activation occurs if the KMS has a key that matches the computer’s GVLK.
|
||||
|
||||
3. The computer tries to activate against Microsoft servers if it is configured with a MAK.
|
||||
|
||||
If the client is not able to activate itself successfully, it will periodically try again. The frequency of the retry attempts depends on the current licensing state and whether the client computer has been successfully activated in the past. For example, if the client computer had been previously activated by Active Directory-based activation, it will periodically try to contact the domain controller at each restart.
|
||||
|
||||
## How Key Management Service works
|
||||
|
||||
|
||||
KMS uses a client–server topology. KMS client computers can locate KMS host computers by using DNS or a static configuration. KMS clients contact the KMS host by using RPCs carried over TCP/IP.
|
||||
|
||||
### Key Management Service activation thresholds
|
||||
|
||||
You can activate physical computers and virtual machines by contacting a KMS host. To qualify for KMS activation, there must be a minimum number of qualifying computers (called the activation threshold). KMS clients will be activated only after this threshold has been met. Each KMS host counts the number of computers that have requested activation until the threshold is met.
|
||||
|
||||
A KMS host responds to each valid activation request from a KMS client with the count of how many computers have already contacted the KMS host for activation. Client computers that receive a count below the activation threshold are not activated. For example, if the first two computers that contact the KMS host are running Windows 10, the first receives an activation count of 1, and the second receives an activation count of 2. If the next computer is a virtual machine on a computer running Windows 10, it receives an activation count of 3, and so on. None of these computers will be activated, because computers running Windows 10, like other client operating system versions, must receive an activation count of 25 or more.
|
||||
|
||||
When KMS clients are waiting for the KMS to reach the activation threshold, they will connect to the KMS host every two hours to get the current activation count. They will be activated when the threshold is met.
|
||||
|
||||
In our example, if the next computer that contacts the KMS host is running Windows Server 2012 R2, it receives an activation count of 4, because activation counts are cumulative. If a computer running Windows Server 2012 R2 receives an activation count that is 5 or more, it is activated. If a computer running Windows 10 receives an activation count of 25 or more, it is activated.
|
||||
|
||||
### Activation count cache
|
||||
|
||||
To track the activation threshold, the KMS host keeps a record of the KMS clients that request activation. The KMS host gives each KMS client a client ID designation, and the KMS host saves each client ID in a table. By default, each activation request remains in the table for up to 30 days. When a client renews its activation, the cached client ID is removed from the table, a new record is created, and the 30day period begins again. If a KMS client computer does not renew its activation within 30 days, the KMS host removes the corresponding client ID from the table and reduces the activation count by one.
|
||||
|
||||
However, the KMS host only caches twice the number of client IDs that are required to meet the activation threshold. Therefore, only the 50 most recent client IDs are kept in the table, and a client ID could be removed much sooner than 30 days.
|
||||
|
||||
The total size of the cache is set by the type of client computer that is attempting to activate. If a KMS host receives activation requests only from servers, the cache will hold only 10 client IDs (twice the required 5). If a client computer running Windows 10 contacts that KMS host, KMS increases the cache size to 50 to accommodate the higher threshold. KMS never reduces the cache size.
|
||||
|
||||
### Key Management Service connectivity
|
||||
|
||||
KMS activation requires TCP/IP connectivity. By default, KMS hosts and clients use DNS to publish and find the KMS. The default settings can be used, which require little or no administrative action, or KMS hosts and client computers can be manually configured based on network configuration and security requirements.
|
||||
|
||||
### Key Management Service activation renewal
|
||||
|
||||
KMS activations are valid for 180 days (the *activation validity interval*). To remain activated, KMS client computers must renew their activation by connecting to the KMS host at least once every 180 days. By default, KMS client computers attempt to renew their activation every 7 days. If KMS activation fails, the client computer retries every two hours. After a client computer’s activation is renewed, the activation validity interval begins again.
|
||||
|
||||
### Publication of the Key Management Service
|
||||
|
||||
The KMS uses service (SRV) resource records in DNS to store and communicate the locations of KMS hosts. KMS hosts use the DNS dynamic update protocol, if available, to publish the KMS service (SRV) resource records. If dynamic update is not available or the KMS host does not have rights to publish the resource records, the DNS records must be published manually, or you must configure client computers to connect to specific KMS hosts.
|
||||
|
||||
### Client discovery of the Key Management Service
|
||||
|
||||
By default, KMS client computers query DNS for KMS information. The first time a KMS client computer queries DNS for KMS information, it randomly chooses a KMS host from the list of service (SRV) resource records that DNS returns. The address of a DNS server that contains the service (SRV) resource records can be listed as a suffixed entry on KMS client computers, which allows one DNS server to advertise the service (SRV) resource records for KMS, and KMS client computers with other primary DNS servers to find it.
|
||||
|
||||
Priority and weight parameters can be added to the DnsDomainPublishList registry value for KMS. Establishing KMS host priority groupings and weighting within each group allows you to specify which KMS host the client computers should try first and balances traffic among multiple KMS hosts. Only Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 provide these priority and weight parameters.
|
||||
|
||||
If the KMS host that a client computer selects does not respond, the KMS client computer removes that KMS host from its list of service (SRV) resource records and randomly selects another KMS host from the list. When a KMS host responds, the KMS client computer caches the name of the KMS host and uses it for subsequent activation and renewal attempts. If the cached KMS host does not respond on a subsequent renewal, the KMS client computer discovers a new KMS host by querying DNS for KMS service (SRV) resource records.
|
||||
|
||||
By default, client computers connect to the KMS host for activation by using anonymous RPCs through TCP port 1688. (You can change the default port.) After establishing a TCP session with the KMS host, the client computer sends a single request packet. The KMS host responds with the activation count. If the count meets or exceeds the activation threshold for that operating system, the client computer is activated and the session is closed. The KMS client computer uses this same process for renewal requests. 250 bytes are used for communication each way.
|
||||
|
||||
### Domain Name System server configuration
|
||||
|
||||
The default KMS automatic publishing feature requires the service (SRV) resource record and support for DNS dynamic update protocol. KMS client computer default behavior and the KMS service (SRV) resource record publishing are supported on a DNS server that is running Microsoft software or any other DNS server that supports service (SRV) resource records (per Internet Engineering Task Force \[IETF\] Request for Comments \[RFC\] 2782) and dynamic updates (per IETF RFC 2136). For example, Berkeley Internet Domain Name versions 8.x and 9.x support service (SRV) resource records and dynamic update.
|
||||
|
||||
The KMS host must be configured so that it has the credentials needed to create and update the following resource records on the DNS servers: service (SRV), IPv4 host (A), and IPv6 host (AAAA), or the records need to be created manually. The recommended solution for giving the KMS host the needed credentials is to create a security group in AD DS, then add all KMS hosts to that group. On a DNS server that is running Microsoft software, ensure that this security group is given full control over the \_VLMCS.\_TCP record in each DNS domain that will contain the KMS service (SRV) resource records.
|
||||
|
||||
### Activating the first Key Management Service host
|
||||
|
||||
KMS hosts on the network need to install a KMS key, and then be activated with Microsoft. Installation of a KMS key enables the KMS on the KMS host. After installing the KMS key, complete the activation of the KMS host by telephone or online. Beyond this initial activation, a KMS host does not communicate any information to Microsoft. KMS keys are only installed on KMS hosts, never on individual KMS client computers.
|
||||
|
||||
### Activating subsequent Key Management Service hosts
|
||||
|
||||
Each KMS key can be installed on up to six KMS hosts. These hosts can be physical computers or virtual machines. After activating a KMS host, the same host can be reactivated up to nine times with the same key. If the organization needs more than six KMS hosts, you can request additional activations for your organization’s KMS key by calling a Microsoft Volume [Licensing Activation Center](http://go.microsoft.com/fwlink/p/?LinkID=618264) to request an exception.
|
||||
|
||||
## How Multiple Activation Key works
|
||||
|
||||
|
||||
A MAK is used for one-time activation with Microsoft’s hosted activation services. Each MAK has a predetermined number of allowed activations. This number is based on volume licensing agreements, and it might not match the organization’s exact license count. Each activation that uses a MAK with the Microsoft hosted activation service counts toward the activation limit.
|
||||
|
||||
You can activate computers by using a MAK in two ways:
|
||||
|
||||
- **MAK independent activation**. Each computer independently connects and is activated with Microsoft over the Internet or by telephone. MAK independent activation is best suited to computers within an organization that do not maintain a connection to the corporate network. MAK independent activation is shown in Figure 16.
|
||||
|
||||
|
||||
|
||||
**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-for-windows-81-client.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,139 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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](http://go.microsoft.com/fwlink/p/?LinkId=618644)
|
||||
|
||||
Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects. Active Directory-based activation requires that the forest schema be updated by adprep.exe on a computer running Windows Server 2012 R2 or Windows Server 2012, but after the schema is updated, older domain controllers can still activate clients.
|
||||
|
||||
Any domain-joined computers running Windows 10, Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 with a GVLK will be activated automatically and transparently. They will stay activated as long as they remain members of the domain and maintain periodic contact with a domain controller. Activation takes place after the Licensing service starts. When this service starts, the computer contacts AD DS automatically, receives the activation object, and is activated without user intervention.
|
||||
|
||||
To allow computers with GVLKs to activate themselves, use the Volume Activation Tools console in Windows Server 2012 R2 or the VAMT in earlier versions of Windows Server to create an object in the AD DS forest. You create this activation object by submitting a KMS host key to Microsoft, as shown in Figure 10.
|
||||
|
||||
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 R2, or Windows Server 2012 R2, and they are joined to a domain, Active Directory-based activation is the best option for activating all client computers and servers, and you may be able to remove any KMS hosts from your environment.
|
||||
|
||||
If an environment will continue to contain earlier volume licensing operating systems and applications or if you have workgroup computers outside the domain, you need to maintain a KMS host to maintain activation status for earlier volume licensing editions of Windows and Office.
|
||||
|
||||
Clients that are activated with Active Directory-based activation will maintain their activated state for up to 180 days since the last contact with the domain, but they will periodically attempt to reactivate before then and at the end of the 180day period. By default, this reactivation event occurs every seven days.
|
||||
|
||||
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**
|
||||
If you are using both KMS and Active Directory-based activation, it may be difficult to see whether a client has been activated by KMS or by Active Directory-based activation. Consider disabling KMS during the test, or make sure that you are using a client computer that has not already been activated by KMS. The **slmrg.vbs /dlv** command also indicates whether KMS has been used.
|
||||
|
||||
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
- [Volume Activation for Windows 10](volume-activation-for-windows-81-client.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
175
windows/deploy/activate-using-key-management-service-client.md
Normal file
175
windows/deploy/activate-using-key-management-service-client.md
Normal file
@ -0,0 +1,175 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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](http://go.microsoft.com/fwlink/p/?LinkId=618644)
|
||||
|
||||
There are three possible scenarios for volume activation of Windows 10 or Windows Server 2012 R2 by using a Key Management Service (KMS) host:
|
||||
|
||||
- Host KMS on a computer running Windows 10
|
||||
|
||||
- Host KMS on a computer running Windows Server 2012 R2
|
||||
|
||||
- Host KMS on a computer running an earlier version of Windows
|
||||
|
||||
## Key Management Service in Windows 10
|
||||
|
||||
|
||||
Installing a KMS host key on a computer running Windows 10 allows you to activate other computers running Windows 10 against this KMS host and earlier versions of the client operating system, such as Windows 8.1 or Windows 7.
|
||||
|
||||
Clients locate the KMS server by using resource records in DNS, so some configuration of DNS may be required. This scenario can be beneficial if your organization uses volume activation for clients and MAK-based activation for a smaller number of servers.
|
||||
|
||||
To enable KMS functionality, a KMS key is installed on a KMS host; then, the host is activated over the Internet or by phone using Microsoft’s activation services.
|
||||
|
||||
**Configure KMS in Windows 10**
|
||||
|
||||
1. Open an elevated command prompt.
|
||||
|
||||
2. Enter one of the following commands.
|
||||
- To install a KMS key, type **slmgr.vbs /ipk <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](http://go.microsoft.com/fwlink/p/?LinkId=717032).
|
||||
|
||||
## Key Management Service in Windows Server 2012 R2
|
||||
|
||||
|
||||
Installing a KMS host key on a computer running Windows Server allows you to activate computers running Windows Server 2012 R2, Windows Sever 2008 R2, Windows Server 2008, Windows 10, Windows 8.1, Windows 7, and Windows Vista.
|
||||
|
||||
**Note**
|
||||
You cannot install a client KMS key into the KMS in Windows Server.
|
||||
|
||||
|
||||
|
||||
This scenario is commonly used in larger organizations that do not find the overhead of using a server a burden.
|
||||
|
||||
**Note**
|
||||
If you receive error 0xC004F015 when trying to activate Windows 10 Enterprise, see [KB 3086418](http://go.microsoft.com/fwlink/p/?LinkId=620687).
|
||||
|
||||
|
||||
|
||||
**Configure KMS in Windows Server 2012 R2**
|
||||
|
||||
1. Sign in to a computer running Windows Server 2012 R2 with an account that has local administrative credentials.
|
||||
|
||||
2. Launch Server Manager.
|
||||
|
||||
3. Add the Volume Activation Services role, as shown in Figure 4.
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
|
||||
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.
|
||||
|
||||
The **/dlv** command displays the detailed licensing information. The response should return an error that states that the KMS activation count is too low. This confirms that KMS is functioning correctly, even though the client has not been activated.
|
||||
|
||||
For more information about the use and syntax of slmgr.vbs, see [Slmgr.vbs Options](http://go.microsoft.com/fwlink/p/?LinkId=733639).
|
||||
|
||||
## Key Management Service in earlier versions of Windows
|
||||
|
||||
|
||||
If you have already established a KMS infrastructure in your organization for an earlier version of Windows, you may want to continue using that infrastructure to activate computers running Windows 10 or Windows Server 2012 R2. Your existing KMS host must be running Windows 7 or later. To upgrade your KMS host, complete the following steps:
|
||||
|
||||
1. Download and install the correct update for your current KMS host operating system. Restart the computer as directed.
|
||||
|
||||
2. Request a new KMS host key from the Volume Licensing Service Center.
|
||||
|
||||
3. Install the new KMS host key on your KMS host.
|
||||
|
||||
4. Activate the new KMS host key by running the slmrg.vbs script.
|
||||
|
||||
For detailed instructions, see [Update that enables Windows 8.1 and Windows 8 KMS hosts to activate a later version of Windows](http://go.microsoft.com/fwlink/p/?LinkId=618265) and [Update that enables Windows 7 and Windows Server 2008 R2 KMS hosts to activate Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=626590).
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
- [Volume Activation for Windows 10](volume-activation-for-windows-81-client.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
39
windows/deploy/active-directory-based-activation-overview.md
Normal file
39
windows/deploy/active-directory-based-activation-overview.md
Normal file
@ -0,0 +1,39 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Active Directory-Based Activation Overview
|
||||
|
||||
|
||||
Active Directory-Based Activation (ADBA) enables enterprises to activate computers through a connection to their domain. Many companies have computers at offsite locations that use products that are registered to the company. Previously these computers needed to either use a retail key or a Multiple Activation Key (MAK), or physically connect to the network in order to activate their products by using Key Management Services (KMS). ADBA provides a way to activate these products if the computers can join the company’s domain. When the user joins their computer to the domain, the ADBA object automatically activates Windows installed on their computer, as long as the computer has a Generic Volume License Key (GVLK) installed. No single physical computer is required to act as the activation object, because it is distributed throughout the domain.
|
||||
|
||||
## Active Directory-Based Activation Scenarios
|
||||
|
||||
|
||||
VAMT enables IT Professionals to manage and activate the Active Directory-Based Activation object. Activation can be performed by using a scenario such as the following:
|
||||
|
||||
- Online activation: To activate an ADBA forest online, the user selects the **Online activate forest** function, selects a KMS Host key (CSVLK) to use, and gives the Active Directory-Based Activation Object a name.
|
||||
|
||||
- Proxy activation: For a proxy activation, the user first selects the **Proxy activate forest** function, selects a KMS Host key (CSVLK) to use, gives the Active Directory-Based Activation Object a name, and provides a file name to save the CILx file that contains the Installation ID. Next, the user takes that file to a computer that is running VAMT with an Internet connection and then selects the **Acquire confirmation IDs for CILX** function on the VAMT landing page, and provides the original CILx file. When VAMT has loaded the Confirmation IDs into the original CILx file, the user takes this file back to the original VAMT instance, where the user completes the proxy activation process by selecting the **Apply confirmation ID to Active Directory domain** function.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[How to Activate an Active Directory Forest Online](http://go.microsoft.com/fwlink/p/?LinkId=246565)
|
||||
|
||||
[How to Proxy Activate an Active Directory Forest](http://go.microsoft.com/fwlink/p/?LinkId=246566)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,75 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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-81-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-81-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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Create an application to deploy with Windows 10 using Configuration Manager](create-an-application-to-deploy-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-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-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
49
windows/deploy/add-and-manage-products-vamt-30-win8.md
Normal file
49
windows/deploy/add-and-manage-products-vamt-30-win8.md
Normal file
@ -0,0 +1,49 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Add and Remove Computers](add-and-remove-computers-vamt-30-win8.md)</p></td>
|
||||
<td align="left"><p>Describes how to add client computers to VAMT.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Update Product Status](update-product-status-vamt-30-win8.md)</p></td>
|
||||
<td align="left"><p>Describes how to update the status of product license.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Remove Products](remove-products-vamt-30-win8.md)</p></td>
|
||||
<td align="left"><p>Describes how to remove a product from the product list.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
53
windows/deploy/add-and-remove-a-product-key-vamt-30-win8.md
Normal file
53
windows/deploy/add-and-remove-a-product-key-vamt-30-win8.md
Normal file
@ -0,0 +1,53 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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-30-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
89
windows/deploy/add-and-remove-computers-vamt-30-win8.md
Normal file
89
windows/deploy/add-and-remove-computers-vamt-30-win8.md
Normal file
@ -0,0 +1,89 @@
|
||||
---
|
||||
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: brianlic-msft
|
||||
---
|
||||
|
||||
# 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-30-win8.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**
|
||||
Note that 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-and-manage-products-vamt-30-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,118 @@
|
||||
---
|
||||
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
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Add drivers for Windows PE](#sec01)
|
||||
- [Add drivers for Windows 10](#sec02)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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-81-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
## 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**:
|
||||
|
||||
1. Name: Windows 10 x64 - HP EliteBook 8560w
|
||||
|
||||
2. 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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-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-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,92 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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](http://go.microsoft.com/fwlink/p/?LinkId=618644)
|
||||
|
||||
When you activate a computer running Windows 10, the following information is sent to Microsoft:
|
||||
|
||||
- The Microsoft product code (a five-digit code that identifies the Windows product you are activating)
|
||||
|
||||
- A channel ID or site code that identifies how the Windows product was originally obtained
|
||||
|
||||
For example, a channel ID or site code identifies whether the product was originally purchased from a retail store, obtained as an evaluation copy, obtained through a volume licensing program, or preinstalled by a computer manufacturer.
|
||||
|
||||
- The date of installation and whether the installation was successful
|
||||
|
||||
- Information that helps confirm that your Windows product key has not been altered
|
||||
|
||||
- Computer make and model
|
||||
|
||||
- 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](http://go.microsoft.com/fwlink/p/?LinkId=619879).
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
- [Volume Activation for Windows 10](volume-activation-for-windows-81-client.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
167
windows/deploy/assign-applications-using-roles-in-mdt-2013.md
Normal file
167
windows/deploy/assign-applications-using-roles-in-mdt-2013.md
Normal file
@ -0,0 +1,167 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Assign applications using roles in MDT
|
||||
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Create and assign a role entry in the database](#sec01)
|
||||
- [Associate the role with a computer in the database](#sec02)
|
||||
- [Verify database access in the MDT simulation environment](#sec03)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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.
|
||||
|
||||
## 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
|
||||
|
||||
## 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).
|
||||
|
||||
## 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-2013-for-bitlocker.md)
|
||||
|
||||
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
|
||||
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
|
||||
|
||||
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-81-deployment-in-a-test-environment.md)
|
||||
|
||||
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-81-deployment-information.md)
|
||||
|
||||
[Use web services in MDT](use-web-services-in-mdt-2013.md)
|
||||
|
||||
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,320 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Build a distributed environment for Windows 10 deployment
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Replicate deployment shares](#sec01)
|
||||
- [Set up Distributed File System Replication (DFS-R) for replication](#sec02)
|
||||
- [Replicate the content](#sec03)
|
||||
- [Configure Windows Deployment Services (WDS) in a remote site](#sec04)
|
||||
- [Deploy the Windows 10 client to the remote site](#sec05)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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-81-with-the-microsoft-deployment-toolkit.md#proof).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
## Replicate deployment shares
|
||||
|
||||
|
||||
Replicating the content between MDT01 (New York) and MDT02 (Stockholm) can be done in a number of different ways. The most common content replication solutions with Microsoft Deployment Toolkit (MDT) 2013 use either the Linked Deployment Shares (LDS) feature or Distributed File System Replication (DFS-R). Some organizations have used a simple robocopy script for replication of the content.
|
||||
|
||||
**Note**
|
||||
Robocopy has options that allow for synchronization between folders. It has a simple reporting function; it supports transmission retry; and, by default, it will only copy/remove files from the source that are newer than files on the target.
|
||||
|
||||
|
||||
|
||||
### Linked deployment shares in MDT 2013 Update 1
|
||||
|
||||
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.
|
||||
|
||||
## 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-81.md) and [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-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.
|
||||
|
||||
## 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.
|
||||
|
||||
## 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.
|
||||
|
||||
## 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--mdt-.md)
|
||||
|
||||
[Create a Windows 10 reference image](create-a-windows-81-reference-image.md)
|
||||
|
||||
[Deploy a Windows 10 image using MDT 2013 Update 1](deploy-a-windows-81-image-using-mdt-2013.md)
|
||||
|
||||
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
|
||||
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
|
||||
[Configure MDT settings](configure-mdt-2013-settings.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
53
windows/deploy/change-history-for-deploy-windows-10.md
Normal file
53
windows/deploy/change-history-for-deploy-windows-10.md
Normal file
@ -0,0 +1,53 @@
|
||||
---
|
||||
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: brianlic-msft
|
||||
---
|
||||
|
||||
# Change history for Deploy Windows 10
|
||||
|
||||
|
||||
This topic lists new and updated topics in the [Deploy Windows 10](deploy-windows-10.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
|
||||
|
||||
## December 2015
|
||||
|
||||
|
||||
| New or changed topic | Description |
|
||||
|-------------------------------------------------------------------------------------------|-------------|
|
||||
| [Activate using Key Management Service](activate-using-key-management-service-client.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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Choose a Migration Store Type (Windows 10)
|
||||
description: Choose a Migration Store Type
|
||||
ms.assetid: 4e163e90-9c57-490b-b849-2ed52ab6765f
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Choose a Migration Store Type
|
||||
|
||||
|
||||
One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store.
|
||||
|
||||
## In This Section
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Migration Store Types Overview](migration-store-types-overview.md)</p></td>
|
||||
<td align="left"><p>Choose the migration store type that works best for your needs and migration scenario.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Estimate Migration Store Size](estimate-migration-store-size-usmt-win7-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Hard-Link Migration Store](hard-link-migration-store-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Learn about hard-link migration stores and the scenarios in which they are used.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Migration Store Encryption](migration-store-encryption-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Learn about the using migration store encryption to protect user data integrity during a migration.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Plan Your Migration](plan-your-migration-usmt-win7-usmt-win8.md)
|
||||
|
||||
[User State Migration Tool (USMT) How-to topics](user-state-migration-tool--usmt--how-to-topics.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
307
windows/deploy/common-issues-usmt-win8.md
Normal file
307
windows/deploy/common-issues-usmt-win8.md
Normal file
@ -0,0 +1,307 @@
|
||||
---
|
||||
title: Common Issues (Windows 10)
|
||||
description: Common Issues
|
||||
ms.assetid: 5a37e390-8617-4768-9eee-50397fbbb2e1
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Common Issues
|
||||
|
||||
|
||||
The following sections discuss common issues that you might see when you run the User State Migration Tool (USMT) 10.0 tools. USMT produces log files that describe in further detail any errors that occurred during the migration process. These logs can be used to troubleshoot migration failures.
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
[User Account Problems](#User)
|
||||
|
||||
[Command-line Problems](#Command)
|
||||
|
||||
[XML File Problems](#XML)
|
||||
|
||||
[Migration Problems](#Migration)
|
||||
|
||||
[Offline Migration Problems](#BKMK_Offline)
|
||||
|
||||
[Hard Link Migration Problems](#BKMK_Hardlink)
|
||||
|
||||
## General Guidelines for Identifying Migration Problems
|
||||
|
||||
|
||||
When you encounter a problem or error message during migration, you can use the following general guidelines to help determine the source of the problem:
|
||||
|
||||
- Examine the ScanState, LoadState, and UsmtUtils logs to obtain the exact USMT error messages and Windows® application programming interface (API) error messages. For more information about USMT return codes and error messages, see [Return Codes](return-codes-usmt-win8.md). For more information about Windows API error messages, type **nethelpmsg** on the command line.
|
||||
|
||||
In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the **/v***:5* option when testing your migration. This verbosity level can be adjusted in a production migration; however, reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. You can use a verbosity level higher than 5 if you want the log files output to go to a debugger.
|
||||
|
||||
**Note**
|
||||
Running the ScanState and LoadState tools with the **/v***:5* option creates a detailed log file. Although this option makes the log file large, the extra detail can help you determine where migration errors occurred.
|
||||
|
||||
|
||||
|
||||
- Use the **/Verify** option in the UsmtUtils tool to determine whether any files in a compressed migration store are corrupted. For more information, see [Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md).
|
||||
|
||||
- Use the **/Extract** option in the UsmtUtils tool to extract files from a compressed migration store. For more information, see [Extract Files from a Compressed USMT Migration Store](extract-files-from-a-compressed-usmt-migration-store.md).
|
||||
|
||||
- Create a progress log using the **/Progress** option to monitor your migration.
|
||||
|
||||
- For the source and destination computers, obtain operating system information, and versions of applications such as Internet Explorer and any other relevant programs. Then verify the exact steps that are needed to reproduce the problem. This information might help you to understand what is wrong and to reproduce the issue in your testing environment.
|
||||
|
||||
- Log off after you run the LoadState tool. Some settings—for example, fonts, desktop backgrounds, and screen-saver settings—will not take effect until the next time the end user logs on.
|
||||
|
||||
- Close all applications before running ScanState or LoadState tools. If some applications are running during the ScanState or LoadState process, USMT might not migrate some data. For example, if Microsoft 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 ignores errors. However, it logs an error when it encounters a file that is in use that did not migrate.
|
||||
|
||||
|
||||
|
||||
## User Account Problems
|
||||
|
||||
|
||||
The following sections describe common user account problems. Expand the section to see recommended solutions.
|
||||
|
||||
### I'm having problems creating local accounts on the destination computer.
|
||||
|
||||
**Resolution:** For more information about creating accounts and migrating local accounts, see [Migrate User Accounts](migrate-user-accounts-usmt.md).
|
||||
|
||||
### Not all of the user accounts were migrated to the destination computer.
|
||||
|
||||
**Causes/Resolutions** There are two possible causes for this problem:
|
||||
|
||||
When running the ScanState tool on Windows Vista, or the ScanState and LoadState tools on Windows 7, Windows 8, or Windows 10, you must run them in Administrator mode from an account with administrative credentials to ensure that all specified users are migrated. To run in Administrator mode:
|
||||
|
||||
1. Click **Start**.
|
||||
|
||||
2. Click **All Programs**.
|
||||
|
||||
3. Click **Accessories**.
|
||||
|
||||
4. Right-click **Command Prompt**.
|
||||
|
||||
5. Click **Run as administrator**.
|
||||
|
||||
Then specify your LoadState or ScanState command. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration.
|
||||
|
||||
Any user accounts on the computer that have not been used will not be migrated. For example, if you add User1 to the computer, but User1 never logs on, then USMT will not migrate the User1 account.
|
||||
|
||||
### User accounts that I excluded were migrated to the destination computer.
|
||||
|
||||
**Cause:** The command that you specified might have had conflicting **/ui** and **/ue** options. If a user is specified with the **/ui** option and is also specified to be excluded with either the **/ue** or **/uel** options, the user will be included in the migration. For example, if you specify `/ui:domain1\* /ue:domain1\user1`, then User1 will be migrated because the **/ui** option takes precedence.
|
||||
|
||||
**Resolution:** For more information about how to use the **/ui** and **/ue** options together, see the examples in the [ScanState Syntax](scanstate-syntax-usmt-win7-usmt-win8.md) topic.
|
||||
|
||||
### I am using the /uel option, but many accounts are still being included in the migration.
|
||||
|
||||
**Cause** The **/uel** option depends on the last modified date of the users' NTUser.dat file. There are scenarios in which this last modified date might not match the users' last logon date.
|
||||
|
||||
**Resolution** This is a limitation of the **/uel** option. You might need to exclude these users manually with the **/ue** option.
|
||||
|
||||
### The LoadState tool reports an error as return code 71 and fails to restore a user profile during a migration test.
|
||||
|
||||
**Cause:** During a migration test, if you run the ScanState tool on your test computer and then delete user profiles in order to test the LoadState tool on the same computer, you may have a conflicting key present in the registry. Using the **net use** command to remove a user profile will delete folders and files associated with that profile, but will not remove the registry key.
|
||||
|
||||
**Resolution:** To delete a user profile, use the **User Accounts** item in Control Panel. To correct an incomplete deletion of a user profile:
|
||||
|
||||
1. Open the registry editor by typing `regedit` at an elevated command prompt.
|
||||
|
||||
2. Navigate to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList`.
|
||||
|
||||
Each user profile is stored in a System Identifier key under `ProfileList`.
|
||||
|
||||
3. Delete the key for the user profile you are trying to remove.
|
||||
|
||||
### Files that were not encrypted before the migration are now encrypted with the account used to run the LoadState tool.
|
||||
|
||||
**Cause:** The ScanState tool was run using the **/EFS: copyraw** option to migrate encrypted files and Encrypting File System (EFS) certificates. The encryption attribute was set on a folder that was migrated, but the attribute was removed from file contents of that folder prior to migration.
|
||||
|
||||
**Resolution:** Before using the ScanState tool for a migration that includes encrypted files and EFS certificates, you can run the Cipher tool at the command prompt to review and change encryption settings on files and folders. You must remove the encryption attribute from folders that contain unencrypted files or encrypt the contents of all files within an encrypted folder.
|
||||
|
||||
To remove encryption from files that have already been migrated incorrectly, you must log on to the computer with the account that you used to run the LoadState tool and then remove the encryption from the affected files.
|
||||
|
||||
### The LoadState tool reports an error as return code 71 and a Windows Error 2202 in the log file.
|
||||
|
||||
**Cause:** The computer name was changed during an offline migration of a local user profile.
|
||||
|
||||
**Resolution:** You can use the **/mu** option when you run the LoadState tool to specify a new name for the user. For example,
|
||||
|
||||
``` syntax
|
||||
loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
|
||||
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1
|
||||
```
|
||||
|
||||
## Command-line Problems
|
||||
|
||||
|
||||
The following sections describe common command-line problems. Expand the section to see recommended solutions.
|
||||
|
||||
### I received the following error message: "Usage Error: You cannot specify a file path with any of the command-line options that exceeds 256 characters."
|
||||
|
||||
**Cause:** You might receive this error message in some cases even if you do not specify a long store or file path, because the path length is calculated based on the absolute path. For example, if you run the **scanstate.exe /o store** command from C:\\Program Files\\USMT40, then each character in "`C:\Program Files\USMT40`" will be added to the length of "store" to get the length of the path.
|
||||
|
||||
**Resolution:** Ensure that the total path length—the store path plus the current directory—does not exceed 256 characters.
|
||||
|
||||
### I received the following error message: "USMT was unable to create the log file(s). Ensure that you have write access to the log directory."
|
||||
|
||||
**Cause:** If you are running the ScanState or LoadState tools from a shared network resource, you will receive this error message if you do not specify **/l**.
|
||||
|
||||
**Resolution:** To fix this issue in this scenario, specify the **/l:scan.log** or **/l:load.log** option.
|
||||
|
||||
## XML File Problems
|
||||
|
||||
|
||||
The following sections describe common XML file problems. Expand the section to see recommended solutions.
|
||||
|
||||
### I used the /genconfig option to create a Config.xml file, but I see only a few applications and components that are in MigApp.xml. Why does Config.xml not contain all of the same applications?
|
||||
|
||||
**Cause:** Config.xml will contain only operating system components, applications, and the user document sections that are in both of the .xml files and are installed on the computer when you run the **/genconfig** option. Otherwise, these applications and components will not appear in the Config.xml file.
|
||||
|
||||
**Resolution:** Install all of the desired applications on the computer before running the **/genconfig** option. Then run ScanState with all of the .xml files. For example, run the following:
|
||||
|
||||
`scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
|
||||
|
||||
### I am having problems with a custom .xml file that I authored, and I cannot verify that the syntax is correct.
|
||||
|
||||
**Resolution:** You can load the XML schema (MigXML.xsd), included with USMT, into your XML authoring tool. For examples, see the [Visual Studio Development Center](http://go.microsoft.com/fwlink/p/?LinkId=74513). Then, load your .xml file in the authoring tool to see if there is a syntax error. In addition, see [USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md) for more information about using the XML elements.
|
||||
|
||||
### I am using a MigXML helper function, but the migration isn’t working the way I expected it to. How do I troubleshoot this issue?
|
||||
|
||||
**Cause:** Typically, this issue is caused by incorrect syntax used in a helper function. You receive a Success return code, but the files you wanted to migrate did not get collected or applied, or weren’t collected or applied in the way you expected.
|
||||
|
||||
**Resolution:** You should search the ScanState or LoadState log for either the component name which contains the MigXML helper function, or the MigXML helper function title, so that you can locate the related warning in the log file.
|
||||
|
||||
## Migration Problems
|
||||
|
||||
|
||||
The following sections describe common migration problems. Expand the section to see recommended solutions.
|
||||
|
||||
### Files that I specified to exclude are still being migrated.
|
||||
|
||||
**Cause:** There might be another rule that is including the files. If there is a more specific rule or a conflicting rule, the files will be included in the migration.
|
||||
|
||||
**Resolution:** For more information, see [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md) and the Diagnostic Log section in [Log Files](log-files-usmt-win7-usmt-win8.md).
|
||||
|
||||
### I specified rules to move a folder to a specific location on the destination computer, but it has not migrated correctly.
|
||||
|
||||
**Cause:** There might be an error in the XML syntax.
|
||||
|
||||
**Resolution:** You can use the USMT XML schema (MigXML.xsd) to write and validate migration .xml files. Also see the XML examples in the following topics:
|
||||
|
||||
[Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md)
|
||||
|
||||
[Exclude Files and Settings](exclude-files-and-settings-usmt.md)
|
||||
|
||||
[Reroute Files and Settings](reroute-files-and-settings-usmt.md)
|
||||
|
||||
[Include Files and Settings](include-files-and-settings-usmt.md)
|
||||
|
||||
[Custom XML Examples](custom-xml-examples-usmt-win7-usmt-win8.md)
|
||||
|
||||
### After LoadState completes, the new desktop background does not appear on the destination computer.
|
||||
|
||||
There are three typical causes for this issue.
|
||||
|
||||
**Cause \#1:**: Some settings such as fonts, desktop backgrounds, and screen-saver settings are not applied by LoadState until after the destination computer has been restarted.
|
||||
|
||||
**Resolution:** To fix this issue, log off, and then log back on to see the migrated desktop background.
|
||||
|
||||
**Cause \#2:** If the source computer was running Windows® XP and the desktop background was stored in the *Drive*:\\WINDOWS\\Web\\Wallpaper folder—the default folder where desktop backgrounds are stored in Windows XP—the desktop background will not be migrated. Instead, the destination computer will have the default Windows® desktop background. This will occur even if the desktop background was a custom picture that was added to the \\WINDOWS\\Web\\Wallpaper folder. However, if the end user sets a picture as the desktop background that was saved in another location, for example, My Pictures, then the desktop background will migrate.
|
||||
|
||||
**Resolution:** Ensure that the desktop background images that you want to migrate are not in the \\WINDOWS\\Web\\Wallpaper folder on the source computer.
|
||||
|
||||
**Cause \#3:** If ScanState was not run on Windows XP from an account with administrative credentials, some operating system settings will not migrate. For example, desktop background settings, screen-saver selections, modem options, media-player settings, and Remote Access Service (RAS) connection phone book (.pbk) files and settings will not migrate.
|
||||
|
||||
**Resolution:** Run the ScanState and LoadState tools from within an account with administrative credentials.
|
||||
|
||||
### I included MigApp.xml in the migration, but some PST files aren’t migrating.
|
||||
|
||||
**Cause:** The MigApp.xml file migrates only the PST files that are linked to Outlook profiles.
|
||||
|
||||
**Resolution:** To migrate PST files that are not linked to Outlook profiles, you must create a separate migration rule to capture these files.
|
||||
|
||||
## Offline Migration Problems
|
||||
|
||||
|
||||
The following sections describe common offline migration problems. Expand the section to see recommended solutions.
|
||||
|
||||
### Some of my system settings do not migrate in an offline migration.
|
||||
|
||||
**Cause:** Some system settings, such as desktop backgrounds and network printers, are not supported in an offline migration. For more information, see [What Does USMT Migrate?](what-does-usmt-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
**Resolution:** In an offline migration, these system settings must be restored manually.
|
||||
|
||||
### The ScanState tool fails with return code 26.
|
||||
|
||||
**Cause:** A common cause of return code 26 is that a temp profile is active on the source computer. This profile maps to c:\\users\\temp. The ScanState log shows a MigStartupOfflineCaught exception that includes the message "User profile duplicate SID error".
|
||||
|
||||
**Resolution:** You can reboot the computer to get rid of the temp profile or you can set MIG\_FAIL\_ON\_PROFILE\_ERROR=0 to skip the error and exclude the temp profile.
|
||||
|
||||
### Include and Exclude rules for migrating user profiles do not work the same offline as they do online.
|
||||
|
||||
**Cause:** When offline, the DNS server cannot be queried to resolve the user name and SID mapping.
|
||||
|
||||
**Resolution:** Use a Security Identifier (SID) to include a user when running the ScanState tool. For example:
|
||||
|
||||
``` syntax
|
||||
Scanstate /ui:S1-5-21-124525095-708259637-1543119021*
|
||||
```
|
||||
|
||||
The wild card (\*) at the end of the SID will migrate the *SID*\_Classes key as well.
|
||||
|
||||
You can also use patterns for SIDs that identify generic users or groups. For example, you can use the */ue:\*-500* option to exclude the local administrator accounts. For more information about Windows SIDs, see [this Microsoft Web site](http://go.microsoft.com/fwlink/p/?LinkId=190277).
|
||||
|
||||
### My script to wipe the disk fails after running the ScanState tool on a 64-bit system.
|
||||
|
||||
**Cause:** The HKLM registry hive is not unloaded after the ScanState tool has finished running.
|
||||
|
||||
**Resolution:** Reboot the computer or unload the registry hive at the command prompt after the ScanState tool has finished running. For example, at a command prompt, type:
|
||||
|
||||
``` syntax
|
||||
reg.exe unload hklm\$dest$software
|
||||
```
|
||||
|
||||
## Hard-Link Migration Problems
|
||||
|
||||
|
||||
The following sections describe common hard-link migration problems. Expand the section to see recommended solutions.
|
||||
|
||||
### EFS files are not restored to the new partition.
|
||||
|
||||
**Cause:** EFS files cannot be moved to a new partition with a hard link. The **/efs:hardlink** command-line option is only applicable to files migrated on the same partition.
|
||||
|
||||
**Resolution:** Use the **/efs:copyraw** command-line option to copy EFS files during the migration instead of creating hard links, or manually copy the EFS files from the hard-link store.
|
||||
|
||||
### The ScanState tool cannot delete a previous hard-link migration store.
|
||||
|
||||
**Cause:** The migration store contains hard links to locked files.
|
||||
|
||||
**Resolution:** Use the UsmtUtils tool to delete the store or change the store name. For example, at a command prompt, type:
|
||||
|
||||
``` syntax
|
||||
USMTutils /rd <storedir>
|
||||
```
|
||||
|
||||
You should also reboot the machine.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[User State Migration Tool (USMT) Troubleshooting](user-state-migration-tool--usmt--troubleshooting.md)
|
||||
|
||||
[Frequently Asked Questions](frequently-asked-questions-usmt-win7-usmt-win8.md)
|
||||
|
||||
[Return Codes](return-codes-usmt-win8.md)
|
||||
|
||||
[UsmtUtils Syntax](usmtutils-syntax-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
149
windows/deploy/common-migration-scenarios-usmt-win7-usmt-win8.md
Normal file
149
windows/deploy/common-migration-scenarios-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,149 @@
|
||||
---
|
||||
title: Common Migration Scenarios (Windows 10)
|
||||
description: Common Migration Scenarios
|
||||
ms.assetid: 1d8170d5-e775-4963-b7a5-b55e8987c1e4
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Common Migration Scenarios
|
||||
|
||||
|
||||
You use the User State Migration Tool (USMT) 10.0 when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing the user's operating-system settings, application settings, and personal files from a source computer and reinstalling them on a destination computer after the upgrade has occurred.
|
||||
|
||||
One common scenario when only the operating system, and not the hardware, is being upgraded is referred to as *PC refresh*. A second common scenario is known as *PC replacement*, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system.
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
[PC Refresh](#BKMK_PCRefresh)
|
||||
|
||||
[Scenario One: PC-refresh offline using Windows PE and a hard-link migration store](#BKMK_OnePCRefresh)
|
||||
|
||||
[Scenario Two: PC-refresh using a compressed migration store](#BKMK_TwoPCRefresh)
|
||||
|
||||
[Scenario Three: PC-refresh using a hard-link migration store](#BKMK_ThreePCRefresh)
|
||||
|
||||
[Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store](#BKMK_FourPCRefresh)
|
||||
|
||||
[PC Replacement](#BKMK_PCReplace)
|
||||
|
||||
[Scenario One: Offline migration using Windows PE and an external migration store](#BKMK_OnePCReplace)
|
||||
|
||||
[Scenario Two: Manual network migration](#BKMK_TwoPCReplace)
|
||||
|
||||
[Scenario Three: Managed network migration](#BKMK_ThreePCReplace)
|
||||
|
||||
## PC-Refresh
|
||||
|
||||
|
||||
The following diagram shows a PC-refresh migration, also known as a computer refresh migration. First, the administrator migrates the user state from a source computer to an intermediate store. After installing the operating system, the administrator migrates the user state back to the source computer.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Scenario One: PC-refresh offline using Windows PE and a hard-link migration store
|
||||
|
||||
A company has just received funds to update the operating system on all of its computers in the accounting department to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled completely offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer.
|
||||
|
||||
1. On each computer, the administrator boots the machine into WinPE and runs the ScanState command-line tool, specifying the **/hardlink /nocompress** command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic as well as minimizing migration failures on computers with very limited space available on the hard drive.
|
||||
|
||||
2. On each computer, the administrator installs the company’s standard operating environment (SOE) which includes Windows 10 and other company applications.
|
||||
|
||||
3. The administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back to each computer.
|
||||
|
||||
### Scenario Two: PC-refresh using a compressed migration store
|
||||
|
||||
A company has just received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server.
|
||||
|
||||
1. The administrator runs the ScanState command-line tool on each computer. ScanState saves each user state to a server.
|
||||
|
||||
2. On each computer, the administrator installs the company's standard SOE which includes Windows 10 and other company applications.
|
||||
|
||||
3. The administrator runs the LoadState command-line tool on each source computer, and LoadState restores each user state back to the computer.
|
||||
|
||||
### Scenario Three: PC-refresh using a hard-link migration store
|
||||
|
||||
A company has just received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer.
|
||||
|
||||
1. The administrator runs the ScanState command-line tool on each computer, specifying the **/hardlink /nocompress** command-line options. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic as well as minimizing migration failures on computers with very limited space available on the hard drive.
|
||||
|
||||
2. On each computer, the administrator installs the company's SOE which includes Windows 10 and other company applications.
|
||||
|
||||
3. The administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back on each computer.
|
||||
|
||||
### Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store
|
||||
|
||||
A company has decided to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses Windows.old and a hard-link migration store to save each user state to their respective computer.
|
||||
|
||||
1. The administrator clean installs Windows 10 on each computer, making sure that the Windows.old directory is created by installing Windows 10 without formatting or repartitioning and by selecting a partition that contains the previous version of Windows.
|
||||
|
||||
2. On each computer, the administrator installs the company’s SOE which includes company applications.
|
||||
|
||||
3. The administrator runs the ScanState and LoadState command-line tools successively on each computer while specifying the **/hardlink /nocompress** command-line options.
|
||||
|
||||
## PC-Replacement
|
||||
|
||||
|
||||
The following diagram shows a PC-replacement migration. First, the administrator migrates the user state from the source computer to an intermediate store. After installing the operating system on the destination computer, the administrator migrates the user state from the store to the destination computer.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Scenario One: Offline migration using WinPE and an external migration store
|
||||
|
||||
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer with their files and settings. In this scenario, migration is being handled completely offline, without a network connection.
|
||||
|
||||
1. On each source computer, an administrator boots the machine into WinPE and runs ScanState to collect the user state to either a server or an external hard disk.
|
||||
|
||||
2. On each new computer, the administrator installs the company's SOE which includes Windows 10 and other company applications.
|
||||
|
||||
3. On each of the new computers, the administrator runs the LoadState tool, restoring each user state from the migration store to one of the new computers.
|
||||
|
||||
### Scenario Two: Manual network migration
|
||||
|
||||
A company receives 50 new laptops for their managers and needs to reallocate 50 older laptops to new employees. In this scenario, an administrator runs the ScanState tool from the cmd prompt on each computer to collect the user states and save them to a server in a compressed migration store.
|
||||
|
||||
1. The administrator runs the ScanState tool on each of the manager’s old laptops, and saves each user state to a server.
|
||||
|
||||
2. On the new laptops, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
|
||||
|
||||
3. The administrator runs the LoadState tool on the new laptops to migrate the managers’ user states to the appropriate computer. The new laptops are now ready for the managers to use.
|
||||
|
||||
4. On the old computers, the administrator installs the company’s SOE, which includes Windows 10, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
|
||||
|
||||
### Scenario Three: Managed network migration
|
||||
|
||||
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer that contains their files and settings. An administrator uses a management technology such as a logon script or a batch file to run ScanState on each source computer to collect the user states and save them to a server in a compressed migration store.
|
||||
|
||||
1. On each source computer, the administrator runs the ScanState tool using Microsoft System Center Configuration Manager (SCCM), Microsoft Deployment Toolkit (MDT), a logon script, a batch file, or a non-Microsoft management technology. ScanState collects the user state from each source computer and then saves it to a server.
|
||||
|
||||
2. On each new computer, the administrator installs the company's SOE, which includes Windows 10 and other company applications.
|
||||
|
||||
3. On each of the new computers, the administrator runs the LoadState tool using System Center Configuration Manager, a logon script, a batch file, or a non-Microsoft management technology. LoadState migrates each user state from the migration store to one of the new computers.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Plan Your Migration](plan-your-migration-usmt-win7-usmt-win8.md)
|
||||
|
||||
[Choose a Migration Store Type](choose-a-migration-store-type-usmt-win7-usmt-win8.md)
|
||||
|
||||
[Offline Migration Reference](offline-migration-reference.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
134
windows/deploy/configure-client-computers-vamt-30-win8.md
Normal file
134
windows/deploy/configure-client-computers-vamt-30-win8.md
Normal file
@ -0,0 +1,134 @@
|
||||
---
|
||||
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
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Configure Client Computers
|
||||
|
||||
|
||||
To enable the Volume Activation Management Tool (VAMT) to function correctly, certain configuration changes are required on all client computers:
|
||||
|
||||
- An exception must be set in the client computer's firewall.
|
||||
|
||||
- A registry key must be created and set properly, for computers in a workgroup; otherwise, Windows® User Account Control (UAC) will not allow remote administrative operations.
|
||||
|
||||
Organizations where the VAMT will be widely used may benefit from making these changes inside the master image for Windows.
|
||||
|
||||
**Important**
|
||||
This procedure only applies to clients running Windows Vista or later. For clients running Windows XP Service Pack 1, see [Connecting Through Windows Firewall](http://go.microsoft.com/fwlink/p/?LinkId=182933).
|
||||
|
||||
|
||||
|
||||
## Configuring the Windows Firewall to allow VAMT access
|
||||
|
||||
|
||||
Enable the VAMT to access client computers using the **Windows Firewall** Control Panel:
|
||||
|
||||
1. Open Control Panel and double-click **System and Security**.
|
||||
|
||||
2. Click **Windows Firewall**.
|
||||
|
||||
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. For each of the following three WMI items, for the applicable Network Profile (Domain, Public, Private), make the changes listed in steps a-c:
|
||||
|
||||
- Windows Management Instrumentation (ASync-In)
|
||||
|
||||
- Windows Management Instrumentation (DCOM-In)
|
||||
|
||||
- Windows Management Instrumentation (WMI-In)
|
||||
|
||||
1. In the **Windows Firewall with Advanced Security** dialog box, select **Inbound Rules** from the left-hand panel.
|
||||
|
||||
2. Right-click the desired rule and select **Properties** to open the **Properties** dialog box.
|
||||
|
||||
3. On the **General** tab, select the **Allow the connection** checkbox.
|
||||
|
||||
4. On the **Scope** tab, change the Remote IP Address setting from "Local Subnet" (default) to allow the specific access you need.
|
||||
|
||||
5. On the **Advanced** tab, verify selection of all profiles that are applicable to the network (Domain or Private/Public).
|
||||
|
||||
In certain scenarios, only a limited set of TCP/IP ports are allowed through a hardware firewall. Administrators must ensure that WMI (which relies on RPC over TCP/IP) is allowed through these types of firewalls. By default, the WMI port is a dynamically allocated random port above 1024. The following Microsoft knowledge article discusses how administrators can limit the range of dynamically-allocated ports. This is useful if, for example, the hardware firewall only allows traffic in a certain range of ports.
|
||||
|
||||
For more info, see [How to configure RPC dynamic port allocation to work with firewalls](http://go.microsoft.com/fwlink/p/?LinkId=182911).
|
||||
|
||||
## Create a registry value for the VAMT to access workgroup-joined computers
|
||||
|
||||
|
||||
**Caution**
|
||||
This section contains information about how to modify the registry. Make sure to back up the registry before you modify it; in addition, ensure that you know how to restore the registry, if a problem occurs. For more information about how to back up, restore, and modify the registry, see [Windows registry information for advanced users](http://go.microsoft.com/fwlink/p/?LinkId=182912).
|
||||
|
||||
|
||||
|
||||
On the client computer, create the following registry key using regedit.exe.
|
||||
|
||||
1. Navigate to `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system`
|
||||
|
||||
2. Enter the following details:
|
||||
|
||||
**Value Name: LocalAccountTokenFilterPolicy**
|
||||
|
||||
**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-and-configure-vamt-vamt-30-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
89
windows/deploy/configure-mdt-2013-for-userexit-scripts.md
Normal file
89
windows/deploy/configure-mdt-2013-for-userexit-scripts.md
Normal file
@ -0,0 +1,89 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Configure MDT for UserExit scripts
|
||||
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Configure the rules to call a UserExit script](#configure_the_rules_to_call_a_userexit_script)
|
||||
- [The Setname.vbs UserExit script](#the_setname.vbs_userexit_script)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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-2013-for-bitlocker.md)
|
||||
|
||||
[Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
|
||||
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-81-deployment-in-a-test-environment.md)
|
||||
|
||||
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-81-deployment-information.md)
|
||||
|
||||
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
|
||||
|
||||
[Use web services in MDT](use-web-services-in-mdt-2013.md)
|
||||
|
||||
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
64
windows/deploy/configure-mdt-2013-settings.md
Normal file
64
windows/deploy/configure-mdt-2013-settings.md
Normal file
@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Configure MDT settings (Windows 10)
|
||||
description: One of the most powerful features in Microsoft Deployment Toolkit (MDT) 2013 is its extension capabilities; there is virtually no limitation to what you can do in terms of customization.
|
||||
ms.assetid: d3e1280c-3d1b-4fad-8ac4-b65dc711f122
|
||||
keywords: ["customize, customization, deploy, features, tools"]
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Configure MDT settings
|
||||
|
||||
|
||||
One of the most powerful features in Microsoft Deployment Toolkit (MDT) 2013 is its extension capabilities; there is virtually no limitation to what you can do in terms of customization. In this topic, you learn about configuring customizations for your environment.
|
||||
|
||||
For the purposes of this topic, we will use four machines: DC01, MDT01, HV01, and PC0001. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 Standard server, and PC0001 is a Windows 10 Enterprise x64 client used for the MDT simulation environment. OR01 has Microsoft System Center 2012 R2 Orchestrator installed. MDT01, OR01, and PC0001 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-81-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-2013-for-bitlocker.md)
|
||||
|
||||
- [Configure MDT deployment share rules](configure-mdt-deployment-share-rules.md)
|
||||
|
||||
- [Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
|
||||
|
||||
- [Simulate a Windows 10 deployment in a test environment](simulate-a-windows-81-deployment-in-a-test-environment.md)
|
||||
|
||||
- [Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-81-deployment-information.md)
|
||||
|
||||
- [Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
|
||||
|
||||
- [Use web services in MDT](use-web-services-in-mdt-2013.md)
|
||||
|
||||
- [Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit--mdt-.md)
|
||||
|
||||
[Create a Windows 10 reference image](create-a-windows-81-reference-image.md)
|
||||
|
||||
[Deploy a Windows 10 image using MDT 2013 Update 1](deploy-a-windows-81-image-using-mdt-2013.md)
|
||||
|
||||
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-81-deployment.md)
|
||||
|
||||
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
|
||||
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
143
windows/deploy/configure-mdt-deployment-share-rules.md
Normal file
143
windows/deploy/configure-mdt-deployment-share-rules.md
Normal file
@ -0,0 +1,143 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Configure MDT deployment share rules
|
||||
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Assign settings](#sec01)
|
||||
- [Sample configurations](#sec02)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
||||
## 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-2013-for-bitlocker.md)
|
||||
|
||||
[Configure MDT for UserExit scripts](configure-mdt-2013-for-userexit-scripts.md)
|
||||
|
||||
[Simulate a Windows 10 deployment in a test environment](simulate-a-windows-81-deployment-in-a-test-environment.md)
|
||||
|
||||
[Use the MDT database to stage Windows 10 deployment information](use-the-mdt-database-to-stage-windows-81-deployment-information.md)
|
||||
|
||||
[Assign applications using roles in MDT](assign-applications-using-roles-in-mdt-2013.md)
|
||||
|
||||
[Use web services in MDT](use-web-services-in-mdt-2013.md)
|
||||
|
||||
[Use Orchestrator runbooks with MDT](use-orchestrator-runbooks-with-mdt-2013.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
584
windows/deploy/configxml-file-usmt-win7-usmt-win8.md
Normal file
584
windows/deploy/configxml-file-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,584 @@
|
||||
---
|
||||
title: Config.xml File (Windows 10)
|
||||
description: Config.xml File
|
||||
ms.assetid: 9dc98e76-5155-4641-bcb3-81915db538e8
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Config.xml File
|
||||
|
||||
|
||||
## Config.xml File
|
||||
|
||||
|
||||
The Config.xml file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the **/genconfig** option with the ScanState.exe tool. If you want to include all of the default components, and do not want to change the default store-creation or profile-migration behavior, you do not need to create a Config.xml file.
|
||||
|
||||
However, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigUser.xml and MigDocs.xml files, but you want to exclude certain components, you can create and modify a Config.xml file and leave the other .xml files unchanged. For example, you must create and modify the Config.xml file if you want to exclude any of the operating-system settings that are migrated. It is necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior.
|
||||
|
||||
The Config.xml file has a different format than the other migration .xml files, because it does not contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, as well as user-profile policy and error-control policy. For this reason, excluding components using the Config.xml file is easier than modifying the migration .xml files, because you do not need to be familiar with the migration rules and syntax. However, you cannot use wildcard characters in this file.
|
||||
|
||||
For more information about using the Config.xml file with other migration files, such as the MigDocs.xml and MigApps.xml files, see [Understanding Migration XML Files](understanding-migration-xml-files.md).
|
||||
|
||||
**Note**
|
||||
To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration.
|
||||
|
||||
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
In USMT there are new migration policies that can be configured in the Config.xml file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. The following elements and parameters are for use in the Config.xml file only.
|
||||
|
||||
[<Policies>](#BKMK_Policies)
|
||||
|
||||
[<ErrorControl>](#BKMK_ErrorControl)
|
||||
|
||||
[<fatal>](#BKMK_fatal)
|
||||
|
||||
[<fileError>](#BKMK_fileError)
|
||||
|
||||
[<nonfatal>](#BKMK_nonFatal)
|
||||
|
||||
[<registryError>](#BKMK_registryError)
|
||||
|
||||
[<HardLinkStoreControl>](#BKMK_HardLinkStoreControl)
|
||||
|
||||
[<fileLocked>](#BKMK_fileLock)
|
||||
|
||||
[<createHardLink>](#BKMK_createHardLink)
|
||||
|
||||
[<errorHardLink>](#BKMK_errorHardLink)
|
||||
|
||||
[<ProfileControl>](#BKMK_ProfileControl)
|
||||
|
||||
[<localGroups>](#BKMK_localGroups)
|
||||
|
||||
[<mappings>](#BKMK_mappings)
|
||||
|
||||
[<changeGroup>](#BKMK_changeGrou)
|
||||
|
||||
[<include>](#BKMK_include)
|
||||
|
||||
[<exclude>](#BKMK_exclude)
|
||||
|
||||
[Sample Config.xml File](#BKMK_SampleConfigXJMLfile)
|
||||
|
||||
## <Policies>
|
||||
|
||||
|
||||
The **<Policies>** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **<Policies>** element are **<ErrorControl>** and **<HardLinkStoreControl>**. The **<Policies>** element is a child of **<Configuration>**.
|
||||
|
||||
Syntax: `<Policies> </Policies>`
|
||||
|
||||
## <ErrorControl>
|
||||
|
||||
|
||||
The **<ErrorControl>** element is an optional element you can configure in the Config.xml file. The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
- **Parent elements**: The **<Policies>** element
|
||||
|
||||
- **Child elements**: The **<fileError>** and **<registryError>** element
|
||||
|
||||
Syntax: `<ErrorControl></ErrorControl>`
|
||||
|
||||
The following example specifies that all locked files, regardless of their location (including files in C:\\Users), should be ignored. However, the migration fails if any file in C:\\Users cannot be accessed because of any other reason. In the example below, the **<ErrorControl>** element ignores any problems in migrating registry keys that match the supplied pattern, and it resolves them to an **Access denied** error.
|
||||
|
||||
Additionally, the order in the **<ErrorControl>** section implies priority. In this example, the first **<nonFatal>** tag takes precedence over the second **<fatal>** tag. This precedence is applied, regardless of how many tags are listed.
|
||||
|
||||
``` syntax
|
||||
<ErrorControl>
|
||||
<fileError>
|
||||
<nonFatal errorCode="33">* [*]</nonFatal>
|
||||
<fatal errorCode="any">C:\Users\* [*]</fatal>
|
||||
</fileError>
|
||||
<registryError>
|
||||
<nonFatal errorCode="5">HKCU\SOFTWARE\Microsoft\* [*]</nonFatal>
|
||||
</registryError>
|
||||
</ErrorControl>
|
||||
```
|
||||
|
||||
**Important**
|
||||
The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
|
||||
|
||||
|
||||
|
||||
### <fatal>
|
||||
|
||||
The **<fatal>** element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
- **Parent elements**: **<fileError>** and **<registryError>**
|
||||
|
||||
- **Child elements**: None.
|
||||
|
||||
Syntax: `<fatal errorCode="any">`*<pattern>*`</fatal>`
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Parameter</th>
|
||||
<th align="left">Required</th>
|
||||
<th align="left">Value</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>errorCode</p></td>
|
||||
<td align="left"><p>No</p></td>
|
||||
<td align="left"><p>"any" or "<em>specify system error message here</em>"</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
You use the **<fatal>** element to specify that errors matching a specific pattern should cause USMT to halt the migration.
|
||||
|
||||
## <fileError>
|
||||
|
||||
|
||||
The **<fileError>** element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
- **Parent elements**: **<ErrorControl>**
|
||||
|
||||
- **Child elements**: **<nonFatal>** and **<fatal>**
|
||||
|
||||
Syntax: `<fileError></fileError>`
|
||||
|
||||
You use the **<fileError>** element to represent the behavior associated with file errors.
|
||||
|
||||
## <nonFatal>
|
||||
|
||||
|
||||
The **<nonFatal>** element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
- **Parent elements**: The **<fileError>** and **<registryError>** elements.
|
||||
|
||||
- **Child elements**: None.
|
||||
|
||||
Syntax: `<nonfatal errorCode="any">`*<pattern>*`</nonFatal>`
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Parameter</th>
|
||||
<th align="left">Required</th>
|
||||
<th align="left">Value</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong><errorCode></strong></p></td>
|
||||
<td align="left"><p>No</p></td>
|
||||
<td align="left"><p>"any" or "<em>specify system error message here</em>". If system error messages are not specified, the default behavior applies the parameter to all system error messages.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
You use the **<nonFatal>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
|
||||
|
||||
## <registryError>
|
||||
|
||||
|
||||
The **<registryError>**element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
- **Parent elements**: **<ErrorControl>**
|
||||
|
||||
- **Child elements**: **<nonfatal>** and **<fatal>**
|
||||
|
||||
Syntax: `<registryError></registryError>`
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Parameter</th>
|
||||
<th align="left">Required</th>
|
||||
<th align="left">Value</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong><errorCode></strong></p></td>
|
||||
<td align="left"><p>No</p></td>
|
||||
<td align="left"><p>"any" or "<em>specify system error message here</em>". If system error messages are not specified, the default behavior applies the parameter to all system error messages.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
You use the **<registryError>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
|
||||
|
||||
## <HardLinkStoreControl>
|
||||
|
||||
|
||||
The **<HardLinkStoreControl>** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **<fileLocked>**.
|
||||
|
||||
Syntax: `<HardLinkStoreControl> </HardLinkStoreControl>`
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
- **Parent elements**: **<Policies>**
|
||||
|
||||
- **Child elements**: **<fileLocked>**
|
||||
|
||||
Syntax: `<HardLinkStoreControl></HardLinkStoreControl>`
|
||||
|
||||
The **<HardLinkStoreControl>** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that cannot be copied, even though is technically possible for the link to be created.
|
||||
|
||||
**Important**
|
||||
The **<ErrorControl>** section can be configured to conditionally ignore file access errors, based on the file’s location.
|
||||
|
||||
|
||||
|
||||
``` syntax
|
||||
<Policy>
|
||||
<HardLinkStoreControl>
|
||||
<fileLocked>
|
||||
<createHardLink>C:\Users\*</createHardLink>
|
||||
<errorHardLink>C:\*</errorHardLink>
|
||||
</fileLocked>
|
||||
</HardLinkStoreControl>
|
||||
<ErrorControl>
|
||||
[…]
|
||||
</ErrorControl>
|
||||
</Policy>
|
||||
```
|
||||
|
||||
## <fileLocked>
|
||||
|
||||
|
||||
The **<fileLocked>** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **<fileLocked>** element are processed in the order in which they appear in the XML file.
|
||||
|
||||
Syntax: `<fileLocked></fileLocked>`
|
||||
|
||||
## <createHardLink>
|
||||
|
||||
|
||||
The **<createHardLink>** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.
|
||||
|
||||
Syntax: `<createHardLink>`*<pattern>*`</createHardLink>`
|
||||
|
||||
## <errorHardLink>
|
||||
|
||||
|
||||
The **<errorHardLink>** element defines a standard MigXML pattern that describes file paths where hard links should not be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that is not possible, **Error\_Locked** is thrown. This is a standard Windows application programming interface (API) error that can be captured by the **<ErrorControl>** section to either cause USMT to skip the file or abort the migration.
|
||||
|
||||
Syntax: `<errorHardLink>`*<pattern>*`</errorHardLink>`
|
||||
|
||||
## <ProfileControl>
|
||||
|
||||
|
||||
This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **<ProfileMigration>** is a child of **<Configuration>**.
|
||||
|
||||
Syntax: <`ProfileControl> </ProfileControl>`
|
||||
|
||||
## <localGroups>
|
||||
|
||||
|
||||
This element is used to contain other elements that establish rules for how to migrate local groups. **<localGroups>** is a child of **<ProfileControl>**.
|
||||
|
||||
Syntax: `<localGroups> </localGroups>`
|
||||
|
||||
## <mappings>
|
||||
|
||||
|
||||
This element is used to contain other elements that establish mappings between groups.
|
||||
|
||||
Syntax: `<mappings> </mappings>`
|
||||
|
||||
## <changeGroup>
|
||||
|
||||
|
||||
This element describes the source and destination groups for a local group membership change during the migration. It is a child of **<localGroups>**. The following parameters are defined:
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Parameter</th>
|
||||
<th align="left">Required</th>
|
||||
<th align="left">Value</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>From</p></td>
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p>A valid local group on the source machine that contains users selected for migration on the command line.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>To</p></td>
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p>A local group that the users are to be moved to during the migration.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>appliesTo</p></td>
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p>nonmigratedUsers, migratedUsers, AllUsers. This value defines which users the change group operation should apply to.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
The valid and required children of **<changeGroup>** are **<include>** and **<exclude>**. Although both can be children at the same time, only one is required.
|
||||
|
||||
Syntax: `<changeGroup From="Group1" To= "Group2"> </changeGroup>`
|
||||
|
||||
## <include>
|
||||
|
||||
|
||||
This element specifies that its required child, *<pattern>*, should be included in the migration.
|
||||
|
||||
Syntax: `<include>``</include>`
|
||||
|
||||
## <exclude>
|
||||
|
||||
|
||||
This element specifies that its required child, *<pattern>*, should be excluded from the migration.
|
||||
|
||||
Syntax: `<exclude>`` </exclude>`
|
||||
|
||||
## Sample Config.xml File
|
||||
|
||||
|
||||
Refer to the following sample Config.xml file for additional details about items you can choose to exclude from a migration.
|
||||
|
||||
``` syntax
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<Configuration>
|
||||
<Applications/>
|
||||
<Documents/>
|
||||
<WindowsComponents>
|
||||
<component displayname="Tablet PC Settings" migrate="yes" ID="tablet_pc_settings">
|
||||
<component displayname="Accessories" migrate="yes" ID="tablet_pc_settings\tablet_pc_accessories">
|
||||
<component displayname="Microsoft-Windows-TabletPC-StickyNotes" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-stickynotes/microsoft-windows-tabletpc-stickynotes/settings"/>
|
||||
<component displayname="Microsoft-Windows-TabletPC-SnippingTool" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-snippingtool/microsoft-windows-tabletpc-snippingtool/settings"/>
|
||||
<component displayname="Microsoft-Windows-TabletPC-Journal" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-journal/microsoft-windows-tabletpc-journal/settings"/>
|
||||
</component>
|
||||
<component displayname="Input Panel" migrate="yes" ID="tablet_pc_settings\tablet_pc_input_panel">
|
||||
<component displayname="Microsoft-Windows-TabletPC-InputPanel" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-inputpanel/microsoft-windows-tabletpc-inputpanel/settings"/>
|
||||
</component>
|
||||
<component displayname="General Options" migrate="yes" ID="tablet_pc_settings\tablet_pc_general_options">
|
||||
<component displayname="Microsoft-Windows-TabletPC-UIHub" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-uihub/microsoft-windows-tabletpc-uihub/settings"/>
|
||||
<component displayname="Microsoft-Windows-TabletPC-Platform-Input-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-platform-input-core/microsoft-windows-tabletpc-platform-input-core/settings"/>
|
||||
</component>
|
||||
<component displayname="Handwriting Recognition" migrate="yes" ID="tablet_pc_settings\handwriting_recognition">
|
||||
<component displayname="Microsoft-Windows-TabletPC-InputPersonalization" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-inputpersonalization/microsoft-windows-tabletpc-inputpersonalization/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Sound and Speech Recognition" migrate="yes" ID="sound_and_speech_recognition">
|
||||
<component displayname="Speech Recognition" migrate="yes" ID="sound_and_speech_recognition\speech_recognition">
|
||||
<component displayname="Microsoft-Windows-SpeechCommon" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-speechcommon/microsoft-windows-speechcommon/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Hardware" migrate="yes" ID="hardware">
|
||||
<component displayname="Phone and Modem" migrate="yes" ID="hardware\phone_and_modem">
|
||||
<component displayname="Microsoft-Windows-TapiSetup" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tapisetup/microsoft-windows-tapisetup/settings"/>
|
||||
</component>
|
||||
<component displayname="Printers and Faxes" migrate="yes" ID="hardware\printers_and_faxes">
|
||||
<component displayname="Microsoft-Windows-Printing-Spooler-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-printing-spooler-core/microsoft-windows-printing-spooler-core/settings"/>
|
||||
<component displayname="Microsoft-Windows-Printing-Spooler-Networkclient" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-printing-spooler-networkclient/microsoft-windows-printing-spooler-networkclient/settings"/>
|
||||
<component displayname="Microsoft-Windows-Printing-Spooler-Core-Localspl" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-printing-spooler-core-localspl/microsoft-windows-printing-spooler-core-localspl/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Programs" migrate="yes" ID="programs">
|
||||
<component displayname="Media Player Settings" migrate="yes" ID="programs\media_player_settings">
|
||||
<component displayname="Microsoft-Windows-MediaPlayer-Migration" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-mediaplayer-migration/microsoft-windows-mediaplayer-migration/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Communications and Sync" migrate="yes" ID="communications_and_sync">
|
||||
<component displayname="Windows Mail" migrate="yes" ID="communications_and_sync\windows_mail">
|
||||
<component displayname="Microsoft-Windows-WAB" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-wab/microsoft-windows-wab/settings"/>
|
||||
<component displayname="Microsoft-Windows-Mail" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-mail/microsoft-windows-mail/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Microsoft-Windows-Migration-DisplayGroups" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-migration-displaygroups/microsoft-windows-migration-displaygroups/settings"/>
|
||||
<component displayname="Performance and Maintenance" migrate="yes" ID="performance_and_maintenance">
|
||||
<component displayname="Diagnostics" migrate="yes" ID="performance_and_maintenance\diagnostics">
|
||||
<component displayname="Microsoft-Windows-RemoteAssistance-Exe" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-remoteassistance-exe/microsoft-windows-remoteassistance-exe/settings"/>
|
||||
<component displayname="Microsoft-Windows-Feedback-Service" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-feedback-service/microsoft-windows-feedback-service/settings"/>
|
||||
</component>
|
||||
<component displayname="Error Reporting" migrate="yes" ID="performance_and_maintenance\error_reporting">
|
||||
<component displayname="Microsoft-Windows-ErrorReportingCore" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-errorreportingcore/microsoft-windows-errorreportingcore/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Network and Internet" migrate="yes" ID="network_and_internet">
|
||||
<component displayname="Offline Files" migrate="yes" ID="network_and_internet\offline_files">
|
||||
<component displayname="Microsoft-Windows-OfflineFiles-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-offlinefiles-core/microsoft-windows-offlinefiles-core/settings"/>
|
||||
</component>
|
||||
<component displayname="Internet Options" migrate="yes" ID="network_and_internet\internet_options">
|
||||
<component displayname="Microsoft-Windows-ieframe" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-ieframe/microsoft-windows-ieframe/settings"/>
|
||||
<component displayname="Microsoft-Windows-IE-InternetExplorer" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-ie-internetexplorer/microsoft-windows-ie-internetexplorer/settings"/>
|
||||
<component displayname="Microsoft-Windows-IE-Feeds-Platform" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-ie-feeds-platform/microsoft-windows-ie-feeds-platform/settings"/>
|
||||
<component displayname="Microsoft-Windows-IE-ClientNetworkProtocolImplementation" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-ie-clientnetworkprotocolimplementation/microsoft-windows-ie-clientnetworkprotocolimplementation/settings"/>
|
||||
</component>
|
||||
<component displayname="Networking Connections" migrate="yes" ID="network_and_internet\networking_connections">
|
||||
<component displayname="Microsoft-Windows-Wlansvc" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-wlansvc/microsoft-windows-wlansvc/settings"/>
|
||||
<component displayname="Microsoft-Windows-RasConnectionManager" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasconnectionmanager/microsoft-windows-rasconnectionmanager/settings"/>
|
||||
<component displayname="Microsoft-Windows-RasApi" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasapi/microsoft-windows-rasapi/settings"/>
|
||||
<component displayname="Microsoft-Windows-PeerToPeerCollab" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-peertopeercollab/microsoft-windows-peertopeercollab/settings"/>
|
||||
<component displayname="Microsoft-Windows-MPR" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-mpr/microsoft-windows-mpr/settings"/>
|
||||
<component displayname="Microsoft-Windows-Dot3svc" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-dot3svc/microsoft-windows-dot3svc/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Date, Time, Language and Region" migrate="yes" ID="date_time_language_and_region">
|
||||
<component displayname="Regional Language Options" migrate="yes" ID="date_time_language_and_region\regional_language_options">
|
||||
<component displayname="Microsoft-Windows-TableDrivenTextService-Migration" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabledriventextservice-migration/microsoft-windows-tabledriventextservice-migration/settings"/>
|
||||
<component displayname="Microsoft-Windows-TextServicesFramework-Migration" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-textservicesframework-migration/microsoft-windows-textservicesframework-migration/settings"/>
|
||||
<component displayname="Microsoft-Windows-MUI-Settings" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-mui-settings/microsoft-windows-mui-settings/settings"/>
|
||||
<component displayname="Microsoft-Windows-International-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-international-core/microsoft-windows-international-core/settings"/>
|
||||
<component displayname="Microsoft-Windows-IME-Traditional-Chinese-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-ime-traditional-chinese-core/microsoft-windows-ime-traditional-chinese-core/settings"/>
|
||||
<component displayname="Microsoft-Windows-IME-Simplified-Chinese-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-ime-simplified-chinese-core/microsoft-windows-ime-simplified-chinese-core/settings"/>
|
||||
<component displayname="Microsoft-Windows-Desktop_Technologies-Text_Input_Services-IME-Japanese-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-desktop_technologies-text_input_services-ime-japanese-core/microsoft-windows-desktop_technologies-text_input_services-ime-japanese-core/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Security" migrate="yes" ID="security">
|
||||
<component displayname="Microsoft-Windows-Rights-Management-Client-v1-API" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rights-management-client-v1-api/microsoft-windows-rights-management-client-v1-api/settings"/>
|
||||
<component displayname="Security Options" migrate="yes" ID="security\security_options">
|
||||
<component displayname="Microsoft-Windows-Credential-Manager" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-credential-manager/microsoft-windows-credential-manager/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Appearance and Display" migrate="yes" ID="appearance_and_display">
|
||||
<component displayname="Windows Games Settings" migrate="yes" ID="appearance_and_display\windows_games_settings">
|
||||
<component displayname="Microsoft-Windows-GameExplorer" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-gameexplorer/microsoft-windows-gameexplorer/settings"/>
|
||||
</component>
|
||||
<component displayname="Taskbar and Start Menu" migrate="yes" ID="appearance_and_display\taskbar_and_start_menu">
|
||||
<component displayname="Microsoft-Windows-stobject" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-stobject/microsoft-windows-stobject/settings"/>
|
||||
<component displayname="Microsoft-Windows-explorer" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-explorer/microsoft-windows-explorer/settings"/>
|
||||
</component>
|
||||
<component displayname="Personalized Settings" migrate="yes" ID="appearance_and_display\personalized_settings">
|
||||
<component displayname="Microsoft-Windows-uxtheme" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-uxtheme/microsoft-windows-uxtheme/settings"/>
|
||||
<component displayname="Microsoft-Windows-themeui" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-themeui/microsoft-windows-themeui/settings"/>
|
||||
<component displayname="Microsoft-Windows-shmig" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-shmig/microsoft-windows-shmig/settings"/>
|
||||
<component displayname="Microsoft-Windows-shell32" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-shell32/microsoft-windows-shell32/settings"/>
|
||||
<component displayname="Microsoft-Windows-CommandPrompt" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-commandprompt/microsoft-windows-commandprompt/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Additional Options" migrate="yes" ID="additional_options">
|
||||
<component displayname="Help Settings" migrate="yes" ID="additional_options\help_settings">
|
||||
<component displayname="Microsoft-Windows-Help-Client" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-help-client/microsoft-windows-help-client/settings"/>
|
||||
</component>
|
||||
<component displayname="Windows Core Settings" migrate="yes" ID="additional_options\windows_core_settings">
|
||||
<component displayname="Microsoft-Windows-Win32k-Settings" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-win32k-settings/microsoft-windows-win32k-settings/settings"/>
|
||||
<component displayname="Microsoft-Windows-Web-Services-for-Management-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-web-services-for-management-core/microsoft-windows-web-services-for-management-core/settings"/>
|
||||
<component displayname="Microsoft-Windows-UPnPSSDP" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-upnpssdp/microsoft-windows-upnpssdp/settings"/>
|
||||
<component displayname="Microsoft-Windows-UPnPDeviceHost" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-upnpdevicehost/microsoft-windows-upnpdevicehost/settings"/>
|
||||
<component displayname="Microsoft-Windows-UPnPControlPoint" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-upnpcontrolpoint/microsoft-windows-upnpcontrolpoint/settings"/>
|
||||
<component displayname="Microsoft-Windows-TerminalServices-RemoteConnectionManager" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-terminalservices-remoteconnectionmanager/microsoft-windows-terminalservices-remoteconnectionmanager/settings"/>
|
||||
<component displayname="Microsoft-Windows-TerminalServices-Drivers" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-terminalservices-drivers/microsoft-windows-terminalservices-drivers/settings"/>
|
||||
<component displayname="Microsoft-Windows-SQMApi" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-sqmapi/microsoft-windows-sqmapi/settings"/>
|
||||
<component displayname="Microsoft-Windows-RPC-Remote" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rpc-remote/microsoft-windows-rpc-remote/settings"/>
|
||||
<component displayname="Microsoft-Windows-RPC-Local" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rpc-local/microsoft-windows-rpc-local/settings"/>
|
||||
<component displayname="Microsoft-Windows-RPC-HTTP" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rpc-http/microsoft-windows-rpc-http/settings"/>
|
||||
<component displayname="Microsoft-Windows-Rasppp" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasppp/microsoft-windows-rasppp/settings"/>
|
||||
<component displayname="Microsoft-Windows-RasMprDdm" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasmprddm/microsoft-windows-rasmprddm/settings"/>
|
||||
<component displayname="Microsoft-Windows-RasBase" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasbase/microsoft-windows-rasbase/settings"/>
|
||||
<component displayname="Microsoft-Windows-Microsoft-Data-Access-Components-(MDAC)-ODBC-DriverManager-Dll" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-microsoft-data-access-components-(mdac)-odbc-drivermanager-dll/microsoft-windows-microsoft-data-access-components-(mdac)-odbc-drivermanager-dll/settings"/>
|
||||
<component displayname="Microsoft-Windows-ICM-Profiles" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-icm-profiles/microsoft-windows-icm-profiles/settings"/>
|
||||
<component displayname="Microsoft-Windows-feclient" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-feclient/microsoft-windows-feclient/settings"/>
|
||||
<component displayname="Microsoft-Windows-dpapi-keys" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-dpapi-keys/microsoft-windows-dpapi-keys/settings"/>
|
||||
<component displayname="Microsoft-Windows-Crypto-keys" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-crypto-keys/microsoft-windows-crypto-keys/settings"/>
|
||||
<component displayname="Microsoft-Windows-COM-DTC-Setup" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-com-dtc-setup/microsoft-windows-com-dtc-setup/settings"/>
|
||||
<component displayname="Microsoft-Windows-COM-ComPlus-Setup" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-com-complus-setup/microsoft-windows-com-complus-setup/settings"/>
|
||||
<component displayname="Microsoft-Windows-COM-Base" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-com-base/microsoft-windows-com-base/settings"/>
|
||||
<component displayname="Microsoft-Windows-CAPI2-certs" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-capi2-certs/microsoft-windows-capi2-certs/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
<component displayname="Accessibility" migrate="yes" ID="accessibility">
|
||||
<component displayname="Accessibility Settings" migrate="yes" ID="accessibility\accessibility_settings">
|
||||
<component displayname="Microsoft-Windows-accessibilitycpl" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-accessibilitycpl/microsoft-windows-accessibilitycpl/settings"/>
|
||||
</component>
|
||||
</component>
|
||||
</WindowsComponents>
|
||||
<Policies>
|
||||
<ErrorControl>
|
||||
<!-- Example:
|
||||
|
||||
<fileError>
|
||||
<nonFatal errorCode="33">* [*]</nonFatal>
|
||||
<fatal errorCode="any">C:\Users\* [*]</fatal>
|
||||
</fileError>
|
||||
<registryError>
|
||||
<nonFatal errorCode="5">* [*]</nonFatal>
|
||||
</registryError>
|
||||
-->
|
||||
</ErrorControl>
|
||||
<HardLinkStoreControl>
|
||||
<!-- Example:
|
||||
|
||||
<fileLocked>
|
||||
<createHardLink>c:\Users\* [*]</createHardLink>
|
||||
<errorHardLink>C:\* [*]</errorHardLink>
|
||||
</fileLocked>
|
||||
-->
|
||||
</HardLinkStoreControl>
|
||||
</Policies>
|
||||
<ProfileControl>
|
||||
<!-- Example:
|
||||
|
||||
<localGroups>
|
||||
<mappings>
|
||||
<changeGroup from="Administrators" to="Users" appliesTo="MigratedUsers">
|
||||
<include>
|
||||
<pattern>DomainName1\Username</pattern>
|
||||
</include>
|
||||
<exclude>
|
||||
<pattern>DomainName2\Username</pattern>
|
||||
</exclude>
|
||||
</changeGroup>
|
||||
</mappings>
|
||||
</localGroups>
|
||||
|
||||
-->
|
||||
</ProfileControl>
|
||||
</Configuration>
|
||||
```
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
459
windows/deploy/conflicts-and-precedence-usmt-win7-usmt-win8.md
Normal file
459
windows/deploy/conflicts-and-precedence-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,459 @@
|
||||
---
|
||||
title: Conflicts and Precedence (Windows 10)
|
||||
description: Conflicts and Precedence
|
||||
ms.assetid: 0e2691a8-ff1e-4424-879b-4d5a2f8a113a
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Conflicts and Precedence
|
||||
|
||||
|
||||
When you include, exclude, and reroute files and settings, it is important to know how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind.
|
||||
|
||||
- **If there are conflicting rules within a component, the most specific rule is applied.** However, the <unconditionalExclude> rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions. For examples, see [What happens when there are conflicting include and exclude rules?](#BKMK1) and the first example in [Include and exclude precedence examples](#PrecExamples)****later in this topic.
|
||||
|
||||
- **Only rules inside the same component can affect each other, depending on specificity.** Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule.
|
||||
|
||||
- **If the rules are equally specific, <exclude> takes precedence over <include>.** For example, if you use the <exclude> rule to exclude a file and use the <include> rule to include the same file, the file will be excluded.
|
||||
|
||||
- **The ordering of components does not matter.** It does not matter which components are listed in which .xml file, because each component is processed independently of the other components across all of the .xml files.
|
||||
|
||||
- **The ordering of the <include> and <exclude> rules within a component does not matter.**
|
||||
|
||||
- **You can use the <unconditionalExclude> element to globally exclude data.** This element excludes objects, regardless of any other <include> rules that are in the .xml files. For example, you can use the <unconditionalExclude> element to exclude all MP3 files on the computer or to exclude all files from C:\\UserData.
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
**General**
|
||||
|
||||
- [What is the relationship between rules that are located within different components?](#BKMK2)
|
||||
|
||||
- [How does precedence work with the Config.xml file?](#BKMK3)
|
||||
|
||||
- [How does USMT process each component in an .xml file with multiple components?](#BKMK4)
|
||||
|
||||
- [How are rules processed?](#BKMK5)
|
||||
|
||||
- [How does USMT combine all of the .xml files that I specify on the command line?](#BKMK6)
|
||||
|
||||
**The <include> and <exclude> rules**
|
||||
|
||||
- [What happens when there are conflicting include and exclude rules?](#BKMK1)
|
||||
|
||||
- [<include> and <exclude> precedence examples](#PrecExamples)
|
||||
|
||||
**File collisions**
|
||||
|
||||
- [What is the default behavior when there are file collisions?](#Collisions)
|
||||
|
||||
- [How does the <merge> rule work when there are file collisions?](#BKMK11)
|
||||
|
||||
## General
|
||||
|
||||
|
||||
### What is the relationship between rules that are located within different components?
|
||||
|
||||
Only rules inside the same component can affect each other, depending on specificity, except for the <unconditionalExclude> rule. Rules that are in different components do not affect each other. If there is an <include> rule in one component and an identical <exclude> rule in another component, the data will be migrated because the two rules are independent of each other.
|
||||
|
||||
If you have an <include> rule in one component and a <locationModify> rule in another component for the same file, the file will be migrated in both places. That is, it will be included based on the <include> rule, and it will be migrated based on the <locationModify> rule.
|
||||
|
||||
The following .xml file migrates all files from C:\\Userdocs, including .mp3 files, because the <exclude> rule is specified in a separate component.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/UserDocs">
|
||||
<component type="Documents" context="System">
|
||||
<displayName>User Documents</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File">C:\Userdocs\* [*.mp3]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
|
||||
<component type="Documents" context="System">
|
||||
<displayName> User documents to include </displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\Userdocs\ [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### How does precedence work with the Config.xml file?
|
||||
|
||||
Specifying `migrate="no"` in the Config.xml file is the same as deleting the corresponding component from the migration .xml file. However, if you set `migrate="no"` for My Documents, but you have a rule similar to the one shown below in a migration .xml file (which includes all of the .doc files from My Documents), then only the .doc files will be migrated, and all other files will be excluded.
|
||||
|
||||
``` syntax
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
```
|
||||
|
||||
### How does USMT process each component in an .xml file with multiple components?
|
||||
|
||||
The ordering of components does not matter. Each component is processed independently of other components. For example, if you have an <include> rule in one component and a <locationModify> rule in another component for the same file, the file will be migrated in both places. That is, it will be included based on the <include> rule, and it will be migrated based on the <locationModify> rule.
|
||||
|
||||
### How are rules processed?
|
||||
|
||||
There are two broad categories of rules.
|
||||
|
||||
- **Rules that affect the behavior of both the ScanState and LoadState tools**. For example, the <include>, <exclude>, and <unconditionalExclude> rules are processed for each component in the .xml files. For each component, USMT creates an include list and an exclude list. Some of the rules in the component might be discarded due to specificity, but all of the remaining rules are processed. For each <include> rule, USMT iterates through the elements to see if any of the locations need to be excluded. USMT enumerates all of the objects and creates a list of objects it is going to collect for each user. Once the list is complete, each of the objects is stored or migrated to the destination computer.
|
||||
|
||||
- **Rules that affect the behavior of only the LoadState tool**. For example, the <locationModify>, <contentModify>, and <destinationCleanup> rules do not affect ScanState. They are processed only with LoadState. First, the LoadState tool determines the content and location of each component based on the <locationModify>and <contentModify> rules. Then, LoadState processes all of the <destinationCleanup> rules and deletes data from the destination computer. Lastly, LoadState applies the components to the computer.
|
||||
|
||||
### How does USMT combine all of the .xml files that I specify on the command line?
|
||||
|
||||
USMT does not distinguish the .xml files based on their name or content. It processes each component within the files separately. USMT supports multiple .xml files only to make it easier to maintain and organize the components within them. Because USMT uses a urlid to distinguish each component from the others, be sure that each .xml file that you specify on the command line has a unique migration urlid.
|
||||
|
||||
## The <include> and <exclude> rules
|
||||
|
||||
|
||||
### What happens when there are conflicting <include> and <exclude> rules?
|
||||
|
||||
If there are conflicting rules within a component, the most specific rule is applied, except with the <unconditionalExclude> rule, which takes precedence over all other rules. If the rules are equally specific, then the data will be not be migrated. For example if you exclude a file, and include the same file, the file will not be migrated. If there are conflicting rules within different components, the rules do not affect each other because each component is processed independently.
|
||||
|
||||
In the following example, mp3 files will not be excluded from the migration. This is because directory names take precedence over the file extensions.
|
||||
|
||||
``` syntax
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File">C:\Data\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\* [*.mp3]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
```
|
||||
|
||||
### <include> and <exclude> rules precedence examples
|
||||
|
||||
These examples explain how USMT deals with <include> and <exclude> rules. When the rules are in different components, the resulting behavior will be the same regardless of whether the components are in the same or in different migration .xml files.
|
||||
|
||||
- [Including and excluding files](#FilesEx)
|
||||
|
||||
- [Including and excluding registry objects](#RegEx)
|
||||
|
||||
### Including and excluding files
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">If you have the following code in the same component</th>
|
||||
<th align="left">Resulting behavior</th>
|
||||
<th align="left">Explanation</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\* [*.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders in Dir1 (including all .txt files in C:).</p></td>
|
||||
<td align="left"><p>The <exclude> rule does not affect the migration because the <include> rule is more specific.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\ * [*.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Nothing will be migrated.</p></td>
|
||||
<td align="left"><p>The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: C:\Dir1\* [*.txt]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2.</p>
|
||||
<p>No files are migrated from Dir2 or its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
<li><p>Exclude rule: C:\Dir1\* [*.txt]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2).</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">If you have the following code in different components</th>
|
||||
<th align="left">Resulting behavior</th>
|
||||
<th align="left">Explanation</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: <pattern type="File">C:\Dir1\Dir2\* [*.txt]</pattern></p></li>
|
||||
<li><p>Exclude rule: <pattern type="File">C:\Dir1\* [*]</pattern></p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2).</p></td>
|
||||
<td align="left"><p>Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Exclude rule: C:\Dir1\* [*.txt]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Exclude rule: C:\Dir1\Dir2\* [*]</p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: C:\Dir1\* [*.txt]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all .txt files in Dir1 and any subfolders.</p></td>
|
||||
<td align="left"><p>Component 1 does not contain an <include> rule, so the <exclude> rule is not processed.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
### Including and excluding registry objects
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">If you have the following code in the same component</th>
|
||||
<th align="left">Resulting behavior</th>
|
||||
<th align="left">Explanation</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor.</p></td>
|
||||
<td align="left"><p>Both rules are processed as intended.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor.</p></td>
|
||||
<td align="left"><p>DefaultColor is migrated because the <include> rule is more specific than the <exclude> rule.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Does not migrate DefaultColor.</p></td>
|
||||
<td align="left"><p>The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
<col width="33%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">If you have the following code in different components</th>
|
||||
<th align="left">Resulting behavior</th>
|
||||
<th align="left">Explanation</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>Component 1:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
</ul>
|
||||
<p>Component 2:</p>
|
||||
<ul>
|
||||
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor\* [*]</p></li>
|
||||
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
|
||||
</ul></td>
|
||||
<td align="left"><p>Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor.</p></td>
|
||||
<td align="left"><p>Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## File collisions
|
||||
|
||||
|
||||
### What is the default behavior when there are file collisions?
|
||||
|
||||
If there is not a <merge> rule, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally: for example, OriginalFileName(1).OriginalExtension, OriginalFileName(2).OriginalExtension, and so on.
|
||||
|
||||
### How does the <merge> rule work when there are file collisions?
|
||||
|
||||
When a collision is detected, USMT will select the most specific <merge> rule and apply it to resolve the conflict. For example, if you have a <merge> rule for C:\\\* \[\*\] set to **sourcePriority()** and another <merge> rule for C:\\subfolder\\\* \[\*\] set to **destinationPriority()** , then USMT uses the destinationPriority() rule because it is the most specific.
|
||||
|
||||
### Example scenario
|
||||
|
||||
The source computer contains the following files:
|
||||
|
||||
- C:\\Data\\SampleA.txt
|
||||
|
||||
- C:\\Data\\SampleB.txt
|
||||
|
||||
- C:\\Data\\Folder\\SampleB.txt
|
||||
|
||||
The destination computer contains the following files:
|
||||
|
||||
- C:\\Data\\SampleB.txt
|
||||
|
||||
- C:\\Data\\Folder\\SampleB.txt
|
||||
|
||||
You have a custom .xml file that contains the following code:
|
||||
|
||||
``` syntax
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File">c:\data\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
```
|
||||
|
||||
For this example, the following table describes the resulting behavior if you add the code in the first column to your custom .xml file.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">If you specify the following code</th>
|
||||
<th align="left">Resulting behavior</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><merge script="MigXmlHelper.DestinationPriority()">
|
||||
<objectSet>
|
||||
<pattern type="File">c:\data\* [*]</pattern>
|
||||
</objectSet>
|
||||
</merge></code></pre></td>
|
||||
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
|
||||
<p>During LoadState, only C:\Data\SampleA.txt will be restored.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><merge script="MigXmlHelper.SourcePriority()">
|
||||
<objectSet>
|
||||
<pattern type="File">c:\data\* [*]</pattern>
|
||||
</objectSet>
|
||||
</merge> </code></pre></td>
|
||||
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
|
||||
<p>During LoadState, all the files will be restored, overwriting the existing files on the destination computer.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><merge script="MigXmlHelper.SourcePriority()">
|
||||
<objectSet>
|
||||
<pattern type="File">c:\data\ [*]</pattern>
|
||||
</objectSet>
|
||||
</merge> </code></pre></td>
|
||||
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
|
||||
<p>During LoadState, the following will occur:</p>
|
||||
<ul>
|
||||
<li><p>C:\Data\SampleA.txt will be restored.</p></li>
|
||||
<li><p>C:\Data\SampleB.txt will be restored, overwriting the existing file on the destination computer.</p></li>
|
||||
<li><p>C:\Data\Folder\SampleB.txt will not be restored.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,123 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Create a custom Windows PE boot image with Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Add DaRT 10 files and prepare to brand the boot image](#sec01)
|
||||
- [Create a boot image for Configuration Manager using the MDT wizard](#sec02)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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) 2013 Update 1 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-81-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
## 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**.
|
||||
|
||||
## 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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-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-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,204 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Create a task sequence with Configuration Manager and MDT
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Create a task sequence using the MDT Integration Wizard](#sec01)
|
||||
- [Edit the task sequence](#sec02)
|
||||
- [Move the packages](#sec03)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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-81-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
## Create a task sequence using the MDT Integration Wizard
|
||||
|
||||
|
||||
This section will walk 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**:
|
||||
|
||||
1. Task sequence name: Windows 10 Enterprise x64 RTM
|
||||
|
||||
2. Task sequence comments: Production image with Office 2013
|
||||
|
||||
4. On the **Details** page, assign the following settings and then click **Next**:
|
||||
|
||||
1. Join a Domain
|
||||
|
||||
2. Domain: contoso.com
|
||||
|
||||
1. Account: CONTOSO\\CM\_JD
|
||||
|
||||
2. Password: Passw0rd!
|
||||
|
||||
3. Windows Settings
|
||||
|
||||
1. User name: Contoso
|
||||
|
||||
2. Organization name: Contoso
|
||||
|
||||
3. 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 2013**. Then click **Next**.
|
||||
|
||||
8. On the **MDT Details** page, assign the name **MDT 2013** 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**.
|
||||
|
||||
## 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:
|
||||
|
||||
1. Name: HP EliteBook 8560w
|
||||
|
||||
2. Driver Package: Windows 10 x64 - HP EliteBook 8560w
|
||||
|
||||
3. 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:
|
||||
|
||||
1. Restore state from another computer
|
||||
|
||||
2. If computer account fails to connect to state store, use the Network Access account
|
||||
|
||||
3. Options: Continue on error
|
||||
|
||||
4. Options / Condition:
|
||||
|
||||
1. Task Sequence Variable
|
||||
|
||||
2. 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:
|
||||
|
||||
1. Options: Continue on error
|
||||
|
||||
2. Options / Condition:
|
||||
|
||||
1. Task Sequence Variable
|
||||
|
||||
2. 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.
|
||||
|
||||
|
||||
|
||||
## 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 2013** 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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-deployment-with-windows-pe-using-configuration-manager.md)
|
||||
|
||||
[Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
868
windows/deploy/create-a-windows-81-reference-image.md
Normal file
868
windows/deploy/create-a-windows-81-reference-image.md
Normal file
@ -0,0 +1,868 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Create a Windows 10 reference image
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [The reference image](#the_reference_image)
|
||||
- [Set up the MDT build lab deployment share](#sec01)
|
||||
- [Add the setup files](#sec02)
|
||||
- [Add applications](#sec03)
|
||||
- [Create the reference image task sequence](#sec04)
|
||||
- [Configure the MDT deployment share rules](#sec05)
|
||||
- [Build the Windows 10 reference image](#sec06)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
Creating a reference image is important because that image serves as the foundation for the devices in your organization. In this topic, you will learn how to create a Windows 10 reference image using the Microsoft Deployment Toolkit (MDT) 2013 Update 1. 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. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-81-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.
|
||||
|
||||
## 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.
|
||||
|
||||
## Add the setup files
|
||||
|
||||
|
||||
This section will show you how to populate the MDT 2013 Update 1 deployment share with the Windows 10 operating system source files, commonly referred to as setup files, which will be used to create a reference image. Setup files are used during the reference image creation process and are the foundation for the reference image.
|
||||
|
||||
### Add the Windows 10 installation files
|
||||
|
||||
MDT 2013 supports adding both full source Windows 10 DVDs (ISOs) and custom images that you have created. In this case, you create a reference image, so you add the full source setup files from Microsoft.
|
||||
|
||||
**Note**
|
||||
Due to the Windows limits on path length, we are purposely keeping the operating system destination directory short, using the folder name W10EX64RTM rather than a more descriptive name like Windows 10 Enterprise x64 RTM.
|
||||
|
||||
|
||||
|
||||
### Add Windows 10 Enterprise x64 (full source)
|
||||
|
||||
In these steps we assume that you have copied the content of a Windows 10 Enterprise x64 ISO to the **E:\\Downloads\\Windows 10 Enterprise x64** folder.
|
||||
|
||||
1. On MDT01, log on as **CONTOSO\\Administrator**.
|
||||
|
||||
2. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Build Lab**.
|
||||
|
||||
3. Right-click the **Operating Systems** node, and create a new folder named **Windows 10**.
|
||||
|
||||
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.
|
||||
|
||||
## 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](http://go.microsoft.com/fwlink/p/?LinkId=619523).
|
||||
|
||||
|
||||
|
||||
### Create the install: Microsoft Office Professional Plus 2013 x86
|
||||
|
||||
You can customize Office 2013. In the volume license versions of Office 2013, there is an Office Customization Tool you can use to customize the Office installation. In these steps we assume you have copied the Office 2013 installation files to the E:\\Downloads\\Office2013 folder.
|
||||
|
||||
### Add the Microsoft Office Professional Plus 2013 x86 installation files
|
||||
|
||||
After adding the Microsoft Office Professional Plus 2013 x86 application, you then automate its setup by running the Office Customization Tool. In fact, MDT 2013 detects that you added the Office Professional Plus 2013 x86 application and creates a shortcut for doing this.
|
||||
|
||||
You also can customize the Office installation using a Config.xml file. But we recommend that you use the Office Customization Tool as described in the following steps, as it provides a much richer way of controlling Office 2013 settings.
|
||||
|
||||
1. Using the Deployment Workbench in the MDT Build Lab deployment share, expand the **Applications / Microsoft** node, and double-click **Install - Microsoft Office 2013 Pro Plus x86**.
|
||||
|
||||
2. In the **Office Products** tab, click **Office Customization Tool**, and click **OK** in the **Information** dialog box.
|
||||
|
||||
|
||||
|
||||
Figure 5. 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-Topic "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"
|
||||
|
||||
New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "E:\MDTBuildLab"
|
||||
```
|
||||
|
||||
### Create the install: Microsoft Visual C++ 2005 SP1 x86
|
||||
|
||||
In these steps we assume that you have downloaded Microsoft Visual C++ 2005 SP1 x86. You might need to modify the path to the source folder to reflect your current environment. In this example, the source path is set to E:\\Downloads\\VC++2005SP1x86.
|
||||
|
||||
1. On MDT01, log on as **CONTOSO\\Administrator**.
|
||||
|
||||
2. Create the application by running the following commands in an elevated PowerShell prompt:
|
||||
|
||||
``` 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
|
||||
```
|
||||
|
||||
## 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.
|
||||
|
||||
## 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.
|
||||
|
||||
## 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--mdt-.md)
|
||||
|
||||
[Deploy a Windows 10 image using MDT 2013 Update 1](deploy-a-windows-81-image-using-mdt-2013.md)
|
||||
|
||||
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-81-deployment.md)
|
||||
|
||||
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
|
||||
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
|
||||
[Configure MDT settings](configure-mdt-2013-settings.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,102 @@
|
||||
---
|
||||
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
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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-81-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 steps below 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:
|
||||
|
||||
1. Automatically detect information about this application from installation files
|
||||
|
||||
2. Type: Windows Installer (\*.msi file)
|
||||
|
||||
3. Location: \\\\CM01\\Sources$\\Software\\Adobe\\Adobe Reader XI
|
||||
|
||||
4. \\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**
|
||||
Since 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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-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-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
313
windows/deploy/custom-xml-examples-usmt-win7-usmt-win8.md
Normal file
313
windows/deploy/custom-xml-examples-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,313 @@
|
||||
---
|
||||
title: Custom XML Examples (Windows 10)
|
||||
description: Custom XML Examples
|
||||
ms.assetid: 48f441d9-6c66-43ef-91e9-7c78cde6fcc0
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Custom XML Examples
|
||||
|
||||
|
||||
**Note**
|
||||
Because the tables in this topic are wide, you may need to adjust the width of its window.
|
||||
|
||||
|
||||
|
||||
## In This Topic:
|
||||
|
||||
|
||||
- [Example 1: Migrating an Unsupported Application](#Example)
|
||||
|
||||
- [Example 2: Migrating the My Videos Folder](#Example2)
|
||||
|
||||
- [Example 3: Migrating Files and Registry Keys](#Example3)
|
||||
|
||||
- [Example 4: Migrating Specific Folders from Various Locations](#Example4)
|
||||
|
||||
## Example 1: Migrating an Unsupported Application
|
||||
|
||||
|
||||
The following is a template for the sections that you need to migrate your application. The template is not functional on its own, but you can use it to write your own .xml file.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migtestapp">
|
||||
<component type="Application">
|
||||
<!-- Name of the application -->
|
||||
<displayName>Some Application</displayName>
|
||||
<!-- Specify whether the environment variables exist in the context of user or system or both -->
|
||||
<environment context="System">
|
||||
<!-- Create the environment variables -->
|
||||
<variable name="myVar1">
|
||||
<!-- Simple text value assignment to a variable -->
|
||||
<text>value</text>
|
||||
</variable>
|
||||
<variable name="myAppExePath">
|
||||
<!-- Make a call to in-built helper function to get a value from a reg key and assign that value to the variable -->
|
||||
<script>MigXMLHelper.GetStringContent("Registry","HKLM\Software\MyApp\Installer [EXEPATH]")</script>
|
||||
</variable>
|
||||
</environment>
|
||||
<role role="Settings">
|
||||
<detects>
|
||||
<!-- All of these checks must be true for the component to be detected -->
|
||||
<detect>
|
||||
<!-- Make a call to in-built helper function to check if an object exists or not -->
|
||||
<condition>MigXMLHelper.DoesObjectExist("Registry","HKLM\Software\MyApp [win32_version]")</condition>
|
||||
</detect>
|
||||
<detect>
|
||||
<!-- Either of these checks must be true for the component to be detected -->
|
||||
<!-- Make a call to in-built helper function to check if a file version matches or not -->
|
||||
<condition>MigXMLHelper.DoesFileVersionMatch("%MyAppExePath%","ProductVersion","8.*")</condition>
|
||||
<condition>MigXMLHelper.DoesFileVersionMatch("%MyAppExePath%","ProductVersion","9.*")</condition>
|
||||
</detect>
|
||||
</detects>
|
||||
<!-- Describe the rules that will be executed during migration of this component and the context, whether user, system or both -->
|
||||
<rules context="User">
|
||||
<!-- Delete objects specified in the object set on the destination computer before applying source objects -->
|
||||
<destinationCleanup>
|
||||
<!-- Describe the pattern for the list of objects to be deleted -->
|
||||
<objectSet>
|
||||
<pattern type="Registry">HKCU\Software\MyApp\Toolbar\* [*]</pattern>
|
||||
<pattern type="Registry">HKCU\Software\MyApp\ListView\* [*]</pattern>
|
||||
<pattern type="Registry">HKCU\Software\MyApp [ShowTips]</pattern>
|
||||
</objectSet>
|
||||
</destinationCleanup>
|
||||
<!-- Specify which set of objects should be migrated -->
|
||||
<include>
|
||||
<!-- Describe the pattern for the list of objects to be included -->
|
||||
<objectSet>
|
||||
<pattern type="Registry">HKCU\Software\MyApp\Toolbar\* [*]</pattern>
|
||||
<pattern type="Registry">HKCU\Software\MyApp\ListView\* [*]</pattern>
|
||||
<pattern type="Registry">HKCU\Software\MyApp [ShowTips]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<!-- Specify which set of objects should not be migrated -->
|
||||
<exclude>
|
||||
<!-- Describe the pattern for the list of objects to be excluded from migration -->
|
||||
<objectSet>
|
||||
<pattern type="Registry">HKCU\Software\MyApp [Display]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
## Example 2: Migrating the My Videos Folder
|
||||
|
||||
|
||||
The following is a custom .xml file named CustomFile.xml that migrates My Videos for all users, if the folder exists on the source computer.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Code</th>
|
||||
<th align="left">Behavior</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition></code></pre></td>
|
||||
<td align="left"><p>Verifies that My Videos exists on the source computer.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><include filter='MigXmlHelper.IgnoreIrrelevantLinks()'></code></pre></td>
|
||||
<td align="left"><p>Filters out the shortcuts in My Videos that do not resolve on the destination computer. This has no effect on files that are not shortcuts. For example, if there is a shortcut in My Videos on the source computer that points to C:\Folder1, that shortcut will be migrated only if C:\Folder1 exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates My Videos for all users.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
``` syntax
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/CustomFile">
|
||||
<component type="Documents" context="User">
|
||||
<displayName>My Video</displayName>
|
||||
<role role="Data">
|
||||
<detects>
|
||||
<detect>
|
||||
<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>
|
||||
</detect>
|
||||
</detects>
|
||||
<rules>
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
## Example 3: Migrating Files and Registry Keys
|
||||
|
||||
|
||||
This table describes the behavior in the following example .xml file.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Code</th>
|
||||
<th align="left">Behavior</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%ProgramFiles%\USMTTestFolder\* [USMTTestFile.txt]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates all instances of the file Usmttestfile.txt from all sub-directories under %ProgramFiles%\USMTTestFolder.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="File">%ProgramFiles%\USMTDIRTestFolder\* [*]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates the whole directory under %ProgramFiles%\USMTDIRTestFolder.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="Registry">HKCU\Software\USMTTESTKEY\* [MyKey]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates all instances of MyKey under HKCU\Software\USMTTESTKEY.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><pre class="syntax" space="preserve"><code><pattern type="Registry">HKLM\Software\USMTTESTKEY\* [*]</pattern></code></pre></td>
|
||||
<td align="left"><p>Migrates the entire registry hive under HKLM\Software\USMTTESTKEY.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/testfilemig">
|
||||
<component type="Application" context="System">
|
||||
<displayName>File Migration Test</displayName>
|
||||
<role role="Data">
|
||||
<rules context="System">
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File">%ProgramFiles%\USMTTestFolder\* [USMTTestFile.txt]</pattern>
|
||||
<pattern type="File">%ProgramFiles%\USMTDIRTestFolder\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
<component type="System">
|
||||
<displayName>Registry Migration Test</displayName>
|
||||
<role role="Settings">
|
||||
<rules context="UserAndSystem">
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="Registry">HKCU\Software\USMTTESTKEY\* [MyKey]</pattern>
|
||||
<pattern type="Registry">HKLM\Software\USMTTESTKEY\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
## Example 4: Migrating Specific Folders from Various Locations
|
||||
|
||||
|
||||
The behavior for this custom .xml file is described within the <`displayName`> tags in the code.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
|
||||
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Component to migrate all Engineering Drafts subfolders without documents in this folder </displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\EngineeringDrafts\ [*]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Component to migrate all user documents except Sample.doc</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\UserDocuments\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\UserDocuments\ [Sample.doc]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Component to migrate all Requests folders on any drive on the computer </displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("\Requests\* [*] ", "Fixed")</script>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("*\Requests\* [*] ", "Fixed")</script>
|
||||
</objectSet>
|
||||
</include>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Component to migrate all Presentations folder from any location on the C: drive </displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\*\Presentations\* [*]</pattern>
|
||||
<pattern type="File"> C:\Presentations\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
|
||||
[Customize USMT XML Files](customize-usmt-xml-files-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
133
windows/deploy/customize-usmt-xml-files-usmt-win7-usmt-win8.md
Normal file
133
windows/deploy/customize-usmt-xml-files-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,133 @@
|
||||
---
|
||||
title: Customize USMT XML Files (Windows 10)
|
||||
description: Customize USMT XML Files
|
||||
ms.assetid: d58363c1-fd13-4f65-8b91-9986659dc93e
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Customize USMT XML Files
|
||||
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
[Overview](#BKMK_Overview)
|
||||
|
||||
[Migration .xml Files](#BKMK_MigXML)
|
||||
|
||||
[Custom .xml Files](#BKMK_CustomXMLFiles)
|
||||
|
||||
[The Config.xml File](#BKMK_ConfigXML)
|
||||
|
||||
[Examples](#BKMK_Examples)
|
||||
|
||||
[Additional Information](#BKMK_AddlInfo)
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
If you want the **ScanState** and **LoadState** tools to use any of the migration .xml files, specify these files at the command line using the **/i** option. Because the **ScanState** and **LoadState** tools need the .xml files to control the migration, specify the same set of .xml files for both the **ScanState** and **LoadState** commands. However, you do not have to specify the Config.xml file with the **/config** option, 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 with the **LoadState** command. Then the **LoadState** command will migrate only the files and settings that you want to migrate.
|
||||
|
||||
If you leave out an .xml file from the **LoadState** command, all of the data in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified with the **ScanState** command will not apply. For example, if you leave out an .xml file, and it contains a rerouting rule such as: `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files, and they will be migrated to C:\\data.
|
||||
|
||||
To modify the migration, do one or more of the following.
|
||||
|
||||
- **Modify the migration .xml files.** If you want to exclude a portion of a component—for example, you want to migrate C:\\ but exclude all of the .mp3 files—or if you want to move data to a new location on the destination computer, modify the .xml files. To modify these files, you must be familiar with the migration rules and syntax. If you want **ScanState** and **LoadState** to use these files, specify them at the command line when each command is entered.
|
||||
|
||||
- **Create a custom .xml file.** You can also create a custom .xml file to migrate settings for another application, or to change the migration behavior to suit your needs. For **ScanState** and **LoadState** to use this file, specify them on both command lines.
|
||||
|
||||
- **Create and modify a Config.xml file.** Do this if you want to exclude an entire component from the migration. For example, you can use a Config.xml file to exclude the entire My Documents folder, or exclude the settings for an application. Excluding components using a Config.xml file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. In addition, using a Config.xml file is the only way to exclude the operating system settings from being migrated.
|
||||
|
||||
For more information about excluding data, see the [Exclude Files and Settings](exclude-files-and-settings-usmt.md) topic.
|
||||
|
||||
## Migration .xml Files
|
||||
|
||||
|
||||
This section describes the migration .xml files that are included with USMT. Each file contains migration rules that control which components are migrated and where they are migrated to on the destination computer.
|
||||
|
||||
**Note**
|
||||
You can use the asterisk (\*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard character.
|
||||
|
||||
|
||||
|
||||
- **The MigApp.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate application settings.
|
||||
|
||||
- **The MigDocs.xml file.** Specify this file with both the **ScanState** and **LoadState** tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it does not find and migrate any application data, program files, or any files in the Windows directory. You can modify the MigDocs.xml file.
|
||||
|
||||
- **The MigUser.xml file.** Specify this file with both the **ScanState** and **LoadState** commands to migrate user folders, files, and file types. You can modify the MigUser.xml file. This file does not contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the **ScanState** and the **LoadState** user options.
|
||||
|
||||
**Note**
|
||||
Do not use the MigUser.xml and MigDocs.xml files together. For more information, see the [Identify File Types, Files, and Folders](identify-file-types-files-and-folders-usmt-win8.md) and [USMT Best Practices](usmt-best-practices-usmt-win7-usmt-win8.md) topics.
|
||||
|
||||
|
||||
|
||||
## Custom .xml Files
|
||||
|
||||
|
||||
You can create custom .xml files to customize the migration for your unique needs. For example, you may want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want **ScanState** and **LoadState** to use this file, specify it with both commands. For more information, see the How to Create a Custom .xml File topic.
|
||||
|
||||
## The Config.xml File
|
||||
|
||||
|
||||
The Config.xml file is an optional file that you create using the **/genconfig** option with the **ScanState** command. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings from being migrated. The Config.xml file format is different from that of the migration .xml files because it does not contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](configxml-file-usmt-win7-usmt-win8.md) topic. For this reason, excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. However, you cannot use wildcard characters in a Config.xml file.
|
||||
|
||||
If you want to include all of the default components, you do not need to create the Config.xml file. Alternatively, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigDocs.xml, and MigUser.xml files, and you want to exclude only some components, you can create and modify a Config.xml file and leave the other .xml files in their original state.
|
||||
|
||||
When you run the **ScanState** command with the **/genconfig** option, **ScanState** reads the other .xml files that you specify using the **/i** option to create a custom list of components that can be migrated from the computer. This file will contain only operating system components, applications, and the user document sections that are in both of the .xml files and that are installed on the computer when you run the **ScanState** command with the **/genconfig** option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that will be present on the destination computers. This will ensure that this file contains every component that can be migrated. The components are organized into sections: <Applications>, <WindowsComponents>, and <Documents>. To choose not to migrate a component, change its entry to `migrate="no"`.
|
||||
|
||||
After you create this file, you need to specify it only with the **ScanState** command using the **/Config** option for it to affect the migration. However, if you want to exclude additional data that you migrated to the store, modify the Config.xml file and specify the updated file with the **LoadState** command. For example, if you collected the My Documents folder in the store, but you decide that you do not want to migrate the My Documents folder to a destination computer, you can modify the Config.xml file to indicate `migrate="no"` before you run the **LoadState** command, and the file will not be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude Files and Settings](exclude-files-and-settings-usmt.md) topic.
|
||||
|
||||
In addition, note the following functionality with the Config.xml file:
|
||||
|
||||
- If a parent component is removed from the migration in the Config.xml file by specifying `migrate="no"`, all of its child components will automatically be removed from the migration, even if the child component is set to `migrate="yes"`.
|
||||
|
||||
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no" `and the other line specifies `migrate="yes"`, the component will be migrated.
|
||||
|
||||
- In USMT there are several migration policies that can be configured in the Config.xml file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. For more information, see the [Config.xml File](configxml-file-usmt-win7-usmt-win8.md) topic.
|
||||
|
||||
**Note**
|
||||
To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration.
|
||||
|
||||
|
||||
|
||||
### Examples
|
||||
|
||||
- The following command creates a Config.xml file in the current directory, but it does not create a store:
|
||||
|
||||
`scanstate /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:5`
|
||||
|
||||
- The following command creates an encrypted store using the Config.xml file and the default migration .xml files:
|
||||
|
||||
`scanstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:5 /encrypt /key:"mykey"`
|
||||
|
||||
- The following command decrypts the store and migrates the files and settings:
|
||||
|
||||
`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:5 /decrypt /key:"mykey"`
|
||||
|
||||
## Additional Information
|
||||
|
||||
|
||||
- For more information about how to change the files and settings that are migrated, see the [User State Migration Tool (USMT) How-to topics](user-state-migration-tool--usmt--how-to-topics.md).
|
||||
|
||||
- For more information about each .xml element, see the [XML Elements Library](xml-elements-library-usmt-win7-usmt-win8.md) topic.
|
||||
|
||||
- For answers to common questions, see ".xml files" in the [Frequently Asked Questions](frequently-asked-questions-usmt-win7-usmt-win8.md) topic.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[User State Migration Tool (USMT) Command-line Syntax](user-state-migration-tool--usmt--command-line-syntax.md)
|
||||
|
||||
[USMT Resources](usmt-resources-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
927
windows/deploy/deploy-a-windows-81-image-using-mdt-2013.md
Normal file
927
windows/deploy/deploy-a-windows-81-image-using-mdt-2013.md
Normal file
@ -0,0 +1,927 @@
|
||||
---
|
||||
title: Deploy a Windows 10 image using MDT 2013 Update 1 (Windows 10)
|
||||
description: This topic will show you how to take your reference image for Windows 10, and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 specifically.
|
||||
ms.assetid: 1d70a3d8-1b1d-4051-b656-c0393a93f83c
|
||||
keywords: ["deployment, automate, tools, configure"]
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Deploy a Windows 10 image using MDT 2013 Update 1
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Step 1: Configure Active Directory permissions](#sec01)
|
||||
- [Step 2: Set up the MDT production deployment share](#sec02)
|
||||
- [Step 3: Add a custom image](#sec03)
|
||||
- [Step 4: Add an application](#sec04)
|
||||
- [Step 5: Prepare the drivers repository](#sec05)
|
||||
- [Step 6: Create the deployment task sequence](#sec06)
|
||||
- [Step 7: Configure the MDT production deployment share](#sec07)
|
||||
- [Step 8: Deploy the Windows 10 client image](#sec08)
|
||||
- [Multicast deployments](#sec09)
|
||||
- [Use offline media to deploy Windows 10](#sec10)
|
||||
- [Unified Extensible Firmware Interface (UEFI)-based deployments](#sec11)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
This topic will show you how to take your reference image for Windows 10, and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 specifically. You will prepare for this by creating a MDT deployment share that is used solely for image deployment. Separating the processes of creating reference images from the processes used to deploy them in production allows greater control of on both processes. You will then configure the deployment share, create a new task sequence, add applications, add drivers, add rules, and configure Active Directory permissions for deployment.
|
||||
|
||||
For the purposes of this topic, we will use three machines: DC01, MDT01, and PC0005. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 standard server, and PC0005 is a blank machine to which you deploy Windows 10. MDT01 and PC0005 are members of the domain contoso.com for the fictitious Contoso Corporation. For more details on the setup for this topic, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-81-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
## Step 1: Configure Active Directory permissions
|
||||
|
||||
|
||||
These steps will show you how to configure an Active Directory account with the permissions required to deploy a Windows 10 machine to the domain using MDT. These steps assume you have downloaded the sample [Set-OUPermissions.ps1 script](http://go.microsoft.com/fwlink/p/?LinkId=619362) and copied it to C:\\Setup\\Scripts on DC01. The account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01. In order for MDT to join machines into the contoso.com domain you need to create an account and configure permissions in Active Directory.
|
||||
|
||||
1. On DC01, using Active Directory User and Computers, browse to **contoso.com / Contoso / Service Accounts**.
|
||||
|
||||
2. Select the **Service Accounts** organizational unit (OU) and create the MDT\_JD account using the following settings:
|
||||
|
||||
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
|
||||
|
||||
## 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-81-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.
|
||||
|
||||
## 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-81-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.
|
||||
|
||||
## 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.
|
||||
|
||||
## Step 5: Prepare the drivers repository
|
||||
|
||||
|
||||
In order to deploy Windows 10 with MDT 2013 Update 1 successfully, you need drivers for the boot images and for the actual operating system. This section will show you how to add drivers for the boot image and operating system, using the following hardware models as examples:
|
||||
|
||||
- Lenovo ThinkPad T420
|
||||
|
||||
- Dell Latitude E6440
|
||||
|
||||
- HP EliteBook 8560w
|
||||
|
||||
- Microsoft Surface Pro
|
||||
|
||||
For boot images, you need to have storage and network drivers; for the operating system, you need to have the full suite of drivers.
|
||||
|
||||
**Note**
|
||||
You should only add drivers to the Windows PE images if the default drivers don't work. Adding drivers that are not necessary will only make the boot image larger and potentially delay the download time.
|
||||
|
||||
|
||||
|
||||
### Create the driver source structure in the file system
|
||||
|
||||
The key to successful management of drivers for MDT 2013 Update 1, 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
|
||||
|
||||
- Surface Pro 3
|
||||
|
||||
**Note**
|
||||
Even if you are not going to use both x86 and x64 boot images, we still recommend that you add the support structure for future use.
|
||||
|
||||
|
||||
|
||||
### Create the logical driver structure in MDT 2013 Update 1
|
||||
|
||||
When you import drivers to the MDT 2013 Update 1 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
|
||||
|
||||
- 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](http://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](http://go.microsoft.com/fwlink/p/?LinkId=619543).
|
||||
|
||||
In these steps, we assume you have downloaded and extracted the drivers using ThinkVantage Update Retriever v5.0 to the E:\\Drivers\\Lenovo\\ThinkPad T420 (4178) folder.
|
||||
|
||||
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Lenovo** node.
|
||||
|
||||
2. Right-click the **4178** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
|
||||
|
||||
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Lenovo\\ThinkPad T420 (4178)**
|
||||
|
||||
### For the Latitude E6440
|
||||
|
||||
For the Dell Latitude E6440 model, you use the Dell Driver CAB file, which is accessible via the [Dell TechCenter website](http://go.microsoft.com/fwlink/p/?LinkId=619544).
|
||||
|
||||
In these steps, we assume you have downloaded and extracted the CAB file for the Latitude E6440 model to the E:\\Drivers\\Dell\\Latitude E6440 folder.
|
||||
|
||||
1. On **MDT01**, using the **Deployment Workbench**, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Dell** node.
|
||||
|
||||
2. Right-click the **Latitude E6440** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
|
||||
|
||||
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Dell\\Latitude E6440**
|
||||
|
||||
### For the HP EliteBook 8560w
|
||||
|
||||
For the HP EliteBook 8560w, you use HP SoftPaq Download Manager to get the drivers. The HP SoftPaq Download Manager can be accessed on the [HP Support site](http://go.microsoft.com/fwlink/p/?LinkId=619545).
|
||||
|
||||
In these steps, we assume you have downloaded and extracted the drivers for the HP EliteBook 8650w model to the E:\\Drivers\\Windows 10 x64\\HP\\HP EliteBook 8560w folder.
|
||||
|
||||
1. On **MDT01**, using the **Deployment Workbench**, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Hewlett-Packard** node.
|
||||
|
||||
2. Right-click the **HP EliteBook 8560w** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
|
||||
|
||||
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\HP\\HP EliteBook 8560w**
|
||||
|
||||
### For the Microsoft Surface Pro 3
|
||||
|
||||
For the Microsoft Surface Pro model, you find the drivers on the Microsoft website. In these steps we assume you have downloaded and extracted the Surface Pro 3 drivers to the E:\\Drivers\\Windows 10 x64\\Microsoft\\Surface Pro 3 folder.
|
||||
|
||||
1. On MDT01, using the Deployment Workbench, in the **MDT Production** node, expand the **Out-Of-Box Drivers** node, and expand the **Microsoft** node.
|
||||
|
||||
2. Right-click the **Surface Pro 3** folder and select **Import Drivers**; use the following setting for the Import Drivers Wizard:
|
||||
|
||||
- Driver source directory: **E:\\Drivers\\Windows 10 x64\\Microsoft\\Surface Pro 3**
|
||||
|
||||
## 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.
|
||||
|
||||
## 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 2013 Update 1, 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**.
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
## 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 2013 monitoring feature
|
||||
|
||||
Now that you have enabled the monitoring on the MDT Production deployment share, you can follow your deployment of PC0005 via the monitoring node.
|
||||
|
||||
1. On MDT01, using Deployment Workbench, expand the **MDT Production** deployment share folder.
|
||||
|
||||
2. Select the **Monitoring** node, and wait until you see PC0005.
|
||||
|
||||
3. Double-click PC0005, and review the information.
|
||||
|
||||
|
||||
|
||||
Figure 11. 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.
|
||||
|
||||
## Multicast deployments
|
||||
|
||||
|
||||
Multicast deployment allows for image deployment with reduced network load during simultaneous deployments. Multicast is a useful operating system deployment feature in MDT deployments, however it is important to ensure that your network supports it and is designed for it.
|
||||
|
||||
### Requirements
|
||||
|
||||
Multicast requires that Windows Deployment Services (WDS) is running on Windows Server 2008 or later. In addition to the core MDT 2013 setup for multicast, the network needs to be configured to support multicast. In general, this means involving the organization networking team to make sure that Internet Group Management Protocol (IGMP) snooping is turned on and that the network is designed for multicast traffic. The multicast solution uses IGMPv3.
|
||||
|
||||
### 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.
|
||||
|
||||
## 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**.
|
||||
|
||||
## Unified Extensible Firmware Interface (UEFI)-based deployments
|
||||
|
||||
|
||||
As referenced in [Windows 10 deployment tools](http://go.microsoft.com/fwlink/p/?LinkId=619546), Unified Extensible Firmware Interface (UEFI)-based deployments are becoming more common. In fact, when you create a generation 2 virtual machine in Hyper-V, you get a UEFI-based computer. During deployment, MDT automatically detects that you have an UEFI-based machine and creates the partitions UEFI requires. You do not need to update or change your task sequences in any way to accommodate UFEI.
|
||||
|
||||
|
||||
|
||||
Figure 14. 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--mdt-.md)
|
||||
|
||||
[Create a Windows 10 reference image](create-a-windows-81-reference-image.md)
|
||||
|
||||
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-81-deployment.md)
|
||||
|
||||
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
|
||||
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
|
||||
[Configure MDT settings](configure-mdt-2013-settings.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
91
windows/deploy/deploy-windows-10.md
Normal file
91
windows/deploy/deploy-windows-10.md
Normal file
@ -0,0 +1,91 @@
|
||||
---
|
||||
title: Deploy Windows 10 (Windows 10)
|
||||
description: Learn about deploying Windows 10 for IT professionals.
|
||||
ms.assetid: E9E2DED5-DBA7-4300-B411-BA0FD39BE18C
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Deploy Windows 10
|
||||
|
||||
|
||||
Learn about deploying Windows 10 for IT professionals.
|
||||
|
||||
## In this section
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<thead>
|
||||
<tr class="header">
|
||||
<th align="left">Topic</th>
|
||||
<th align="left">Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Change history for Deploy Windows 10](change-history-for-deploy-windows-10.md)</p></td>
|
||||
<td align="left"><p>This topic lists new and updated topics in the Deploy Windows 10 documentation for [Windows 10 and Windows 10 Mobile](../index.md).</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)</p></td>
|
||||
<td align="left"><p>To successfully deploy the Windows 10 operating system in your organization, it is important to understand the different ways that it can be deployed, especially now that there are new scenarios to consider. Choosing among these scenarios, and understanding the key capabilities and limitations of each, is a key task.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-81-with-the-microsoft-deployment-toolkit.md)</p></td>
|
||||
<td align="left"><p>This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 specifically.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Deploy Windows 10 with System Center 2012 R2 Configuration Manager](deploy-windows-81-with-system-center-2012-r2-configuration-manager.md)</p></td>
|
||||
<td align="left"><p>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) or, more specifically, MDT 2013 Update 1.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Upgrade to Windows 10 with the Microsoft Deployment Toolkit](upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md)</p></td>
|
||||
<td align="left"><p>The simplest path to upgrade PCs that are currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade. You can use a Microsoft Deployment Toolkit (MDT) 2013 Update 1 task sequence to completely automate the process.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Upgrade to Windows 10 with System Center Configuration Manager](upgrade-to-windows-10-with-system-center-configuraton-manager.md)</p></td>
|
||||
<td align="left"><p>The simplest path to upgrade PCs currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade. You can use a System Center Configuration Manager task sequence to completely automate the process.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Windows 10 edition upgrade](windows-10-edition-upgrades.md)</p></td>
|
||||
<td align="left"><p>With Windows 10, you can quickly upgrade from one edition of Windows 10 to another, provided the upgrade path is supported.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Deploy Windows To Go in your organization](deploy-windows-to-go-in-your-organization-small-scenario.md)</p></td>
|
||||
<td align="left"><p>This topic helps you to deploy Windows To Go in your organization. Before you begin deployment, make sure that you have reviewed the topics [Windows To Go: feature overview](../plan/windows-to-go-feature-overview-scenario.md) and [Prepare your organization for Windows To Go](../plan/prepare-your-organization-for-windows-to-go.md) to ensure that you have the correct hardware and are prepared to complete the deployment. You can then use the steps in this topic to start your Windows To Go deployment.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Update Windows 10 images with provisioning packages](update-windows-10-images-with-provisioning-packages.md)</p></td>
|
||||
<td align="left"><p>Use a provisioning package to apply settings, profiles, and file assets to a Windows 10 image.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Sideload apps in Windows 10](sideload-apps-in-windows-10.md)</p></td>
|
||||
<td align="left"><p>Sideload line-of-business apps in Windows 10.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Volume Activation [client]](volume-activation-for-windows-81-client.md)</p></td>
|
||||
<td align="left"><p>This guide is designed to help organizations that are planning to use volume activation to deploy and activate Windows 10, including organizations that have used volume activation for earlier versions of Windows.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Windows 10 deployment tools reference](windows-10-deployment-tools-reference.md)</p></td>
|
||||
<td align="left"><p>Learn about the tools available to deploy Windows 10.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,67 @@
|
||||
---
|
||||
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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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-81-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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-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-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,105 @@
|
||||
---
|
||||
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
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# 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) or, more specifically, MDT 2013 Update 1.
|
||||
|
||||
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-81-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
## In this section
|
||||
|
||||
|
||||
- [Integrate Configuration Manager with MDT 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
- [Prepare for Zero Touch Installation of Windows with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
- [Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
- [Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-using-configuration-manager.md)
|
||||
|
||||
- [Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-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-operating-system-configuration-for-windows-81-deployment-with-configuration-manager.md)
|
||||
|
||||
- [Deploy Windows 10 using PXE and Configuration Manager](deploy-windows-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
- [Monitor the Windows 10 deployment with Configuration Manager](monitor-the-windows-81-deployment-with-configuration-manager.md)
|
||||
|
||||
- [Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
- [Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-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 2013 Update 1 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-81-reference-image.md).
|
||||
|
||||
- **Drivers.** Like MDT 2013 Update 1 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 2013 Update 1 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 2013 Update 1 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](http://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-81-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-in-your-organization-small-scenario.md)
|
||||
|
||||
- [Sideload Windows Store apps](http://technet.microsoft.com/library/dn613831.aspx)
|
||||
|
||||
- [Windows ADK for Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=526803)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,130 @@
|
||||
---
|
||||
title: Deploy Windows 10 with the Microsoft Deployment Toolkit (Windows 10)
|
||||
description: This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 specifically.
|
||||
ms.assetid: 837f009c-617e-4b3f-9028-2246067ee0fb
|
||||
keywords: ["deploy", "tools", "configure", "script"]
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Deploy Windows 10 with the Microsoft Deployment Toolkit
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
This guide will walk you through the process of deploying Windows 10 in an enterprise environment using the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 specifically.
|
||||
|
||||
The Microsoft Deployment Toolkit is a unified collection of tools, processes, and guidance for automating desktop and server deployment. In addition to reducing deployment time and standardizing desktop and server images, MDT enables you to more easily manage security and ongoing configurations. MDT builds on top of the core deployment tools in the Windows Assessment and Deployment Kit (Windows ADK) with additional guidance and features designed to reduce the complexity and time required for deployment in an enterprise environment.
|
||||
|
||||
MDT 2013 Update 1 supports the deployment of Windows 10, as well as Windows 7, Windows 8, Windows 8.1, and Windows Server 2012 R2. It also includes support for zero-touch installation (ZTI) with Microsoft System Center 2012 R2 Configuration Manager.
|
||||
|
||||
To download the latest version of MDT, visit the [MDT resource page](http://go.microsoft.com/fwlink/p/?LinkId=618117).
|
||||
|
||||
## In this section
|
||||
|
||||
|
||||
- [Get started with the Microsoft Deployment Toolkit (MDT)](get-started-with-the-microsoft-deployment-toolkit--mdt-.md)
|
||||
|
||||
- [Create a Windows 10 reference image](create-a-windows-81-reference-image.md)
|
||||
|
||||
- [Deploy a Windows 10 image using MDT 2013 Update 1](deploy-a-windows-81-image-using-mdt-2013.md)
|
||||
|
||||
- [Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-81-deployment.md)
|
||||
|
||||
- [Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
|
||||
- [Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
|
||||
- [Configure MDT settings](configure-mdt-2013-settings.md)
|
||||
|
||||
## 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](http://go.microsoft.com/fwlink/p/?LinkId=619361). This sample Windows PowerShell script performs the MDT Gather process in a simulated MDT environment. This allows you to test the MDT gather process and check to see if it is working correctly without performing a full Windows deployment.
|
||||
|
||||
- [Set-OUPermissions.ps1](http://go.microsoft.com/fwlink/p/?LinkId=619362). This sample Windows PowerShell script creates a domain account and then configures OU permissions to allow the account to join machines to the domain in the specified OU.
|
||||
|
||||
- [MDTSample.zip](http://go.microsoft.com/fwlink/p/?LinkId=619363). This sample web service shows you how to configure a computer name dynamically using MDT.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Microsoft Deployment Toolkit downloads and resources](http://go.microsoft.com/fwlink/p/?LinkId=618117)
|
||||
|
||||
[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)
|
||||
|
||||
[Windows 10 deployment tools](windows-deployment-scenarios-and-tools.md)
|
||||
|
||||
[Deploy Windows 10 with System Center 2012 R2 Configuration Manager](deploy-windows-81-with-system-center-2012-r2-configuration-manager.md)
|
||||
|
||||
[Deploy Windows To Go in your organization](deploy-windows-to-go-in-your-organization-small-scenario.md)
|
||||
|
||||
[Sideload apps in Windows 10](sideload-apps-in-windows-10.md)
|
||||
|
||||
[Volume Activation for Windows 10](volume-activation-for-windows-81-client.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Determine What to Migrate (Windows 10)
|
||||
description: Determine What to Migrate
|
||||
ms.assetid: 01ae1d13-c3eb-4618-b39d-ee5d18d55761
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Determine What to Migrate
|
||||
|
||||
|
||||
By default, User State Migration Tool (USMT) 10.0 migrates the items listed in [What Does USMT Migrate?](what-does-usmt-migrate-usmt-win7-usmt-win8.md), depending on the migration .xml files you specify. These default settings are often enough for a basic migration.
|
||||
|
||||
However, when considering what settings to migrate, you should also consider what settings you would like the user to be able to configure, if any, and what settings you would like to standardize. Many organizations use their migration as an opportunity to create and begin enforcing a better-managed environment. Some of the settings that users can configure on unmanaged computers prior to the migration can be locked on the new, managed computers. For example, standard wallpaper, Internet Explorer security settings, and desktop configuration are some of the items you can choose to standardize.
|
||||
|
||||
To reduce complexity and increase standardization, your organization should consider creating a *standard operating environment (SOE)*. An SOE is a combination of hardware and software that you distribute to all users. This means selecting a baseline for all computers, including standard hardware drivers; core operating system features; core productivity applications, especially if they are under volume licensing; and core utilities. This environment should also include a standard set of security features, as outlined in the organization’s corporate policy. Using a standard operating environment can vastly simplify the migration and reduce overall deployment challenges.
|
||||
|
||||
## In This Section
|
||||
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Identify Users](identify-users-usmt-win7-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Use command-line options to specify which users to migrate and how they should be migrated.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Identify Applications Settings](identify-applications-settings-usmt-win7-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Determine which applications you want to migrate and prepare a list of application settings to be migrated.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p>[Identify Operating System Settings](identify-operating-system-settings-usmt-win7-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Use migration to create a new standard environment on each of the destination computers.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>[Identify File Types, Files, and Folders](identify-file-types-files-and-folders-usmt-win8.md)</p></td>
|
||||
<td align="left"><p>Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[What Does USMT Migrate?](what-does-usmt-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,134 @@
|
||||
---
|
||||
title: Estimate Migration Store Size (Windows 10)
|
||||
description: Estimate Migration Store Size
|
||||
ms.assetid: cfb9062b-7a2a-467a-a24e-0b31ce830093
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Estimate Migration Store Size
|
||||
|
||||
|
||||
The disk space requirements for a migration are dependent on the size of the migration store and the type of migration. You can estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure. You can also calculate the disk space requirements using the ScanState tool.
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
- [Hard Disk Space Requirements](#BKMK_SpaceReqs). Describes the disk space requirements for the migration store and other considerations on the source and destination computers.
|
||||
|
||||
- [Calculate Disk Space Requirements Using the ScanState Tool](#BKMK_calcDiskSpace). Describes how to use the ScanState tool to determine how big the migration store will be on a particular computer.
|
||||
|
||||
- [Estimate Migration Store Size](#BKMK_EstMigStoreSize). Describes how to estimate the average size of migration stores for the computers in your organization, based on your infrastructure.
|
||||
|
||||
## Hard Disk Space Requirements
|
||||
|
||||
|
||||
- **Store.** For non-hard-link migrations, you should ensure that there is enough available disk space at the location where you will save your store to contain the data being migrated. You can save your store to another partition, an external storage device such as a USB flash drive or a server. For more information, see [Choose a Migration Store Type](choose-a-migration-store-type-usmt-win7-usmt-win8.md).
|
||||
|
||||
- **Source Computer.** The source computer needs enough available space for the following:
|
||||
|
||||
- [E250 megabytes (MB) minimum of hard disk space.](#BKMK_EstMigStoreSize) Space is needed to support the User State Migration Tool (USMT) 10.0 operations, for example, growth in the page file. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tools will not create the migration store if 250 MB of disk space is not available.
|
||||
|
||||
- [Temporary space for USMT to run.](#BKMK_EstMigStoreSize) Additional disk space for the USMT tools to operate is required. This does not include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
|
||||
|
||||
- [Hard-link migration store.](#BKMK_EstMigStoreSize) It is not necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated.
|
||||
|
||||
- [Destination computer.](#BKMK_EstMigStoreSize) The destination computer needs enough available space for the following:
|
||||
|
||||
- [Operating system.](#BKMK_EstMigStoreSize)
|
||||
|
||||
- [Applications.](#BKMK_EstMigStoreSize)
|
||||
|
||||
- [Data being migrated.](#BKMK_EstMigStoreSize) It is important to consider that in addition to the files being migrated, registry information will also require hard disk space for storage.
|
||||
|
||||
- [Temporary space for USMT to run.](#BKMK_EstMigStoreSize) Additional disk space for the USMT tools to operate is required. The amount of temporary space required can be calculated using the ScanState tool.
|
||||
|
||||
## Calculate Disk Space Requirements using the ScanState Tool
|
||||
|
||||
|
||||
You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It is not necessary to estimate the migration store size for a hard-link migration since this method does not create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer may change during day to day use so it is recommended that you use the calculations as an estimate when planning your migration.
|
||||
|
||||
**To run the ScanState tool on the source computer with USMT installed,**
|
||||
|
||||
1. Open a command prompt with administrator privileges.
|
||||
|
||||
2. Navigate to the USMT tools. For example, type
|
||||
|
||||
``` syntax
|
||||
cd /d "C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\User State Migration Tool\<architecture>"
|
||||
```
|
||||
|
||||
Where *<architecture>* is x86 or amd64.
|
||||
|
||||
3. Run the **ScanState** tool to generate an XML report of the space requirements. At the command prompt, type
|
||||
|
||||
``` syntax
|
||||
ScanState.exe <StorePath> /p:<path to a file>
|
||||
```
|
||||
|
||||
Where *<StorePath>* is a path to a directory where the migration store will be saved and *<path to a file>* is the path and filename where the XML report for space requirements will be saved. For example,
|
||||
|
||||
``` syntax
|
||||
ScanState.exe c:\store /p:c:\spaceRequirements.xml
|
||||
```
|
||||
|
||||
The migration store will not be created by running this command, but `StorePath` is a required parameter.
|
||||
|
||||
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML Files](customize-usmt-xml-files-usmt-win7-usmt-win8.md).
|
||||
|
||||
**Note**
|
||||
To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the **/p** option, without specifying *<path to a file>* is still available in USMT.
|
||||
|
||||
|
||||
|
||||
The space requirements report provides two elements, <**storeSize**> and <**temporarySpace**>. The <**temporarySpace**> value shows the disk space, in bytes, that USMT uses to operate during the migration—this does not include the minimum 250 MB needed to support USMT. The <**storeSize**> value shows the disk space, in bytes, required to host the migration store contents on both the source and destination computers. The following example shows a report generated using **/p:***<path to a file>*.
|
||||
|
||||
``` syntax
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<PreMigration>
|
||||
<storeSize>
|
||||
<size clusterSize="4096">11010592768</size>
|
||||
</storeSize>
|
||||
<temporarySpace>
|
||||
<size>58189144</size>
|
||||
</temporarySpace>
|
||||
</PreMigration>
|
||||
```
|
||||
|
||||
Additionally, USMT performs a compliance check for a required minimum of 250 MB of available disk space and will not create a store if the compliance check fails.
|
||||
|
||||
## Estimate Migration Store Size
|
||||
|
||||
|
||||
Determine how much space you will need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate these is to survey several computers to arrive at an average for the size of the store that you will need.
|
||||
|
||||
The amount of space that is required in the store will vary, depending on the local storage strategies your organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets will be smaller. If e-mail is stored locally, such as offline-storage files, data sets will be larger. Mobile users will typically have larger data sets than workstation users. You should perform tests and inventory the network to determine the average data set size in your organization.
|
||||
|
||||
**Note**
|
||||
You can create a space-estimate file (Usmtsize.txt), by using the legacy **/p** command-line option to estimate the size of the store.
|
||||
|
||||
|
||||
|
||||
When trying to determine how much disk space you will need, consider the following issues:
|
||||
|
||||
- **E-mail** : If users deal with a large volume of e-mail or keep e-mail on their local computers instead of on a mail server, the e-mail can take up as much disk space as all other user files combined. Prior to migrating user data, make sure that users who store e-mail locally synchronize their inboxes with their mail server.
|
||||
|
||||
- **User documents**: Frequently, all of a user's documents fit into less than 50 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary substantially based on the types of documents that your organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs much more space than a law firm that primarily uses word-processing documents. You do not need to migrate the documents that users store on file servers through mechanisms such as Folder Redirection, as long as users will have access to these locations after the migration.
|
||||
|
||||
- **User system settings** Five megabytes is usually adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that have been installed. It is rare, however, for the user-specific portion of the registry to exceed 5 MB.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Common Migration Scenarios](common-migration-scenarios-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
304
windows/deploy/exclude-files-and-settings-usmt.md
Normal file
304
windows/deploy/exclude-files-and-settings-usmt.md
Normal file
@ -0,0 +1,304 @@
|
||||
---
|
||||
title: Exclude Files and Settings (Windows 10)
|
||||
description: Exclude Files and Settings
|
||||
ms.assetid: df85baf1-6e29-4995-a4bb-ba3f8f7fed0b
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Exclude Files and Settings
|
||||
|
||||
|
||||
When you specify the migration .xml files, MigApp.xml, Migdocs, and MigUser.xml, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What Does USMT Migrate?](what-does-usmt-migrate-usmt-win7-usmt-win8.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a Config.xml file to exclude an entire component from a migration. You cannot, however, exclude users by using the migration .xml files or the Config.xml file. The only way to specify which users to include and exclude is by using the User options on the command line in the ScanState tool. For more information, see [ScanState Syntax](scanstate-syntax-usmt-win7-usmt-win8.md).
|
||||
|
||||
In this topic:
|
||||
|
||||
- [Create a custom .xml file](#Options). You can use the following elements to specify what to exclude:
|
||||
|
||||
- [include and exclude](#BKMK_IncludeExclude): You can use the <include> and <exclude> elements to exclude objects with conditions. For example, you can migrate all files located in the C:\\ drive, except any .mp3 files. It is important to remember that [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md) apply to these elements.
|
||||
|
||||
- [unconditionalExclude](#ExOne): You can use the <unconditionalExclude> element to globally exclude data. This element takes precedence over all other include and exclude rules in the .xml files. Therefore, this element excludes objects regardless of any other <include> rules that are in the .xml files. For example, you can exclude all .mp3 files on the computer, or you can exclude all files from C:\\UserData.
|
||||
|
||||
- [Create a Config.xml file](#Co): You can create and modify a Config.xml file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying a Config.xml file is the only way to exclude the operating-system settings that are migrated to computers running Windows. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax.
|
||||
|
||||
## Create a custom .xml file
|
||||
|
||||
|
||||
We recommend that you create a custom .xml file instead of modifying the default migration .xml files. When you use a custom .xml file, you can keep your changes separate from the default .xml files, which makes it easier to track your modifications.
|
||||
|
||||
### <include> and <exclude>
|
||||
|
||||
The migration .xml files, MigApp.xml, MigDocs, and MigUser.xml, contain the <component> element, which typically represents a self-contained component or an application such as Microsoft® Office Outlook® and Word. To exclude the files and registry settings that are associated with these components, use the <include> and <exclude> elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md).
|
||||
|
||||
**Note**
|
||||
If you specify an <exclude> rule, always specify a corresponding <include> rule. Otherwise, if you do not specify an <include> rule, the specific files or settings will not be included. They will already be excluded from the migration. Thus, an unaccompanied <exclude> rule is unnecessary.
|
||||
|
||||
|
||||
|
||||
- [Example 1: How to migrate all files from C:\\ except .mp3 files](#Ex1)
|
||||
|
||||
- [Example 2: How to migrate all files located in C:\\Data except files in C:\\Data\\tmp](#Ex2)
|
||||
|
||||
- [Example 3: How to exclude the files in a folder but include all subfolders](#Ex3)
|
||||
|
||||
- [Example 4: How to exclude a file from a specific folder](#Ex4)
|
||||
|
||||
- [Example 5: How to exclude a file from any location](#Ex5)
|
||||
|
||||
### Example 1: How to migrate all files from C:\\ except .mp3 files
|
||||
|
||||
The following .xml file migrates all files located on the C: drive, except any .mp3 files.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/mp3files">
|
||||
<!-- This component migrates all files except those with .mp3 extension-->
|
||||
<component type="Documents" context="UserAndSystem">
|
||||
<displayName _locID="miguser.sharedvideo">MP3 Files</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
<objectSet>
|
||||
<pattern type="File">C:\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File">C:\* [*.mp3]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 2: How to migrate all files located in C:\\Data except files in C:\\Data\\tmp
|
||||
|
||||
The following .xml file migrates all files and subfolders in C:\\Data, except the files and subfolders in C:\\Data\\tmp.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
|
||||
<component type="Documents" context="System">
|
||||
<displayName _locID="miguser.sharedvideo">Test component</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File">C:\Data\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\Data\temp\* [*]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 3: How to exclude the files in a folder but include all subfolders
|
||||
|
||||
The following .xml file migrates any subfolders in C:\\EngineeringDrafts, but excludes all files that are in C:\\EngineeringDrafts.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Component to migrate all Engineering Drafts Documents without subfolders</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\EngineeringDrafts\ [*]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 4: How to exclude a file from a specific folder
|
||||
|
||||
The following .xml file migrates all files and subfolders in C:\\EngineeringDrafts, except for the Sample.doc file in C:\\EngineeringDrafts.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Component to migrate all Engineering Drafts Documents except Sample.doc</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\EngineeringDrafts\* [*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<exclude>
|
||||
<objectSet>
|
||||
<pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>
|
||||
</objectSet>
|
||||
</exclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 5: How to exclude a file from any location
|
||||
|
||||
To exclude a Sample.doc file from any location on the C: drive, use the <pattern> element. If multiple files exist with the same name on the C: drive, all of these files will be excluded.
|
||||
|
||||
``` syntax
|
||||
<pattern type="File"> C:\* [Sample.doc] </pattern>
|
||||
```
|
||||
|
||||
To exclude a Sample.doc file from any drive on the computer, use the <script> element. If multiple files exist with the same name, all of these files will be excluded.
|
||||
|
||||
``` syntax
|
||||
<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script>
|
||||
```
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
|
||||
### Example 1: How to exclude all .mp3 files
|
||||
|
||||
The following .xml file excludes all .mp3 files from the migration:
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/excludefiles">
|
||||
<component context="System" type="Documents">
|
||||
<displayName>Test</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 2: How to exclude all of the files on a specific drive
|
||||
|
||||
The following .xml file excludes only the files located on the C: drive.
|
||||
|
||||
``` syntax
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/allfiles">
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Test</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<pattern type="File">c:\*[*]</pattern>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 3: How to exclude registry keys
|
||||
|
||||
The following .xml file unconditionally excludes the HKey\_Current\_User registry key and all of its subkeys.
|
||||
|
||||
``` syntax
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
|
||||
<component type="Documents" context="User">
|
||||
<displayName>Test</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<pattern type="Registry">HKCU\testReg[*]</pattern>
|
||||
</objectSet>
|
||||
</include>
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<pattern type="Registry">HKCU\*[*]</pattern>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
### Example 4: How to Exclude C:\\Windows and C:\\Program Files
|
||||
|
||||
The following .xml file unconditionally excludes the system folders of C:\\Windows and C:\\Program Files. Note that all \*.docx, \*.xls and \*.ppt files will not be migrated because the <unconditionalExclude> element takes precedence over the <include> element.
|
||||
|
||||
``` syntax
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
|
||||
<component type="Documents" context="System">
|
||||
<displayName>Test</displayName>
|
||||
<role role="Data">
|
||||
<rules>
|
||||
<include>
|
||||
<objectSet>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.xls]", "Fixed")</script>
|
||||
<script>MigXmlHelper.GenerateDrivePatterns ("* [*.ppt]", "Fixed")</script>
|
||||
</objectSet>
|
||||
</include>
|
||||
<unconditionalExclude>
|
||||
<objectSet>
|
||||
<pattern type="File">C:\Program Files\* [*]</pattern>
|
||||
<pattern type="File">C:\Windows\* [*]</pattern>
|
||||
</objectSet>
|
||||
</unconditionalExclude>
|
||||
</rules>
|
||||
</role>
|
||||
</component>
|
||||
</migration>
|
||||
```
|
||||
|
||||
## Create a Config.xml File
|
||||
|
||||
|
||||
You can create and modify a Config.xml file if you want to exclude components from the migration. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. Config.xml is an optional file that you can create using the **/genconfig** command-line option with the ScanState tool. For example, you can use the Config.xml file to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
|
||||
|
||||
- **To exclude the settings for a default application:** Specify `migrate="no"` for the application under the <Applications> section of the Config.xml file.
|
||||
|
||||
- **To exclude an operating system setting:** Specify `migrate="no"` for the setting under the <WindowsComponents> section.
|
||||
|
||||
- **To exclude My Documents:** Specify `migrate="no"` for My Documents under the <Documents> section. Note that any <include> rules in the .xml files will still apply. For example, if you have a rule that includes all the .docx files in My Documents, then only the .docx files will be migrated, but the rest of the files will not.
|
||||
|
||||
See [Config.xml File](configxml-file-usmt-win7-usmt-win8.md) for more information.
|
||||
|
||||
**Note**
|
||||
To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration.
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Customize USMT XML Files](customize-usmt-xml-files-usmt-win7-usmt-win8.md)
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
|
||||
[Config.xml File](configxml-file-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,117 @@
|
||||
---
|
||||
title: Extract Files from a Compressed USMT Migration Store (Windows 10)
|
||||
description: Extract Files from a Compressed USMT Migration Store
|
||||
ms.assetid: ad9fbd6e-f89e-4444-8538-9b11566b1f33
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Extract Files from a Compressed USMT Migration Store
|
||||
|
||||
|
||||
When you migrate files and settings during a typical PC-refresh migration, you usually create a compressed migration store file on the intermediate store. This migration store is a single image file that contains all files being migrated as well as a catalog file. To protect the compressed file, you can encrypt it by using different encryption algorithms. When you migrate the file back to the source computer after the operating system is installed, you can run the **Usmtutils** command with the **/extract** option to recover the files from the compressed migration store. You can also use the **Usmtutils** command with the **/extract** option any time you need to recover data from a migration store.
|
||||
|
||||
Options used with the **/extract** option can specify:
|
||||
|
||||
- The cryptographic algorithm that was used to create the migration store.
|
||||
|
||||
- The encryption key or the text file that contains the encryption key.
|
||||
|
||||
- Include and exclude patterns for selective data extraction.
|
||||
|
||||
In addition, you can specify the file patterns that you want to extract by using the **/i** option to include file patterns or the **/e** option to exclude file patterns. When both the **/i** option and the **/e** option are used in the same command, include patterns take precedence over exclude patterns. Note that this is different from the include and exclude rules used in the ScanState and LoadState tools.
|
||||
|
||||
## In this topic
|
||||
|
||||
|
||||
- [To run the USMTutils tool with the /extract option](#BKMK_extractSyntax)
|
||||
|
||||
- [To extract all files from a compressed migration store](#BKMK_extractAllFiles)
|
||||
|
||||
- [To extract specific file types from an encrypted compressed migration store](#BKMK_extractSpecificFiles)
|
||||
|
||||
- [To extract all but one, or more, file types from an encrypted compressed migration store](#BKMK_excludeFilePattern)
|
||||
|
||||
- [To extract file types using the include pattern and the exclude pattern](#BKMK_includeExcludeFiles)
|
||||
|
||||
### To run the USMTutils tool with the /extract option
|
||||
|
||||
To extract files from the compressed migration store onto the destination computer, use the following USMTutils syntax:
|
||||
|
||||
Cd /d <USMTpath> usmtutils /extract <filePath> <destinationPath> \[/i:<includePattern>\] \[/e:<excludePattern>\] \[/l:<logfile>\] \[/decrypt\[:<AlgID>\] {/key:<keystring> | /keyfile:<filename>}\] \[/o\]
|
||||
|
||||
Where the placeholders have the following values:
|
||||
|
||||
- *<USMTpath>* is the location where you have saved the USMT files and tools.
|
||||
|
||||
- *<filePath>* is the location of the migration store.
|
||||
|
||||
- *<destination path>* is the location of the file where you want the **/extract** option to put the extracted migration store contents.
|
||||
|
||||
- *<includePattern>* specifies the pattern for the files to include in the extraction.
|
||||
|
||||
- *<excludePattern>* specifies the pattern for the files to omit from the extraction.
|
||||
|
||||
- *<AlgID>* is the cryptographic algorithm that was used to create the migration store on the **ScanState** command line.
|
||||
|
||||
- *<logfile>* is the location and name of the log file.
|
||||
|
||||
- *<keystring>* is the encryption key that was used to encrypt the migration store.
|
||||
|
||||
- *<filename>* is the location and name of the text file that contains the encryption key.
|
||||
|
||||
### To extract all files from a compressed migration store
|
||||
|
||||
To extract everything from a compressed migration store to a file on the C:\\ drive, type:
|
||||
|
||||
``` syntax
|
||||
usmtutils /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore
|
||||
```
|
||||
|
||||
### To extract specific file types from an encrypted compressed migration store
|
||||
|
||||
To extract specific files, such as .txt and .pdf files, from an encrypted compressed migration store, type:
|
||||
|
||||
``` syntax
|
||||
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt,*.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt
|
||||
```
|
||||
|
||||
In this example, the file is encrypted and the encryption key is located in a text file called encryptionKey.
|
||||
|
||||
### To extract all but one, or more, file types from an encrypted compressed migration store
|
||||
|
||||
To extract all files except for one file type, such as .exe files, from an encrypted compressed migration store, type:
|
||||
|
||||
``` syntax
|
||||
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtutilslog.txt
|
||||
```
|
||||
|
||||
### To extract file types using the include pattern and the exclude pattern
|
||||
|
||||
To extract files from a compressed migration store, and to exclude files of one type (such as .exe files) while including only specific files, use both the include pattern and the exclude pattern, as in this example:
|
||||
|
||||
``` syntax
|
||||
usmtutils /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o
|
||||
```
|
||||
|
||||
In this example, if there is a myProject.exe file, it will also be extracted because the include pattern option takes precedence over the exclude pattern option.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[UsmtUtils Syntax](usmtutils-syntax-usmt-win8.md)
|
||||
|
||||
[Return Codes](return-codes-usmt-win8.md)
|
||||
|
||||
[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,203 @@
|
||||
---
|
||||
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
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Finalize the operating system configuration for Windows 10 deployment with Configuration Manager
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
**In this article**
|
||||
|
||||
- [Enable MDT monitoring](#sec01)
|
||||
- [Create and share the Logs folder](#sec02)
|
||||
- [Configure the rules (Windows 10 x64 Settings package)](#sec03)
|
||||
- [Distribute content to the CM01 distribution portal](#sec04)
|
||||
- [Create a deployment for the task sequence](#sec05)
|
||||
- [Configure Configuration Manager to prompt for the computer name during deployment (optional)](#sec06)
|
||||
- [Related topics](#related_topics)
|
||||
|
||||
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-81-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
## 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:
|
||||
|
||||
1. Deployment share path: E:\\MDTProduction
|
||||
|
||||
2. Share name: MDTProduction$
|
||||
|
||||
3. Deployment share description: MDT Production
|
||||
|
||||
4. 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. Enabling MDT monitoring for Configuration Manager.
|
||||
|
||||
## 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)'
|
||||
```
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
## 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**:
|
||||
|
||||
1. Purpose: Available
|
||||
|
||||
2. 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.
|
||||
|
||||
## 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-2013-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:
|
||||
|
||||
1. Name: OSDComputerName
|
||||
|
||||
2. 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 2013 Update 1](integrate-configuration-manager-with-mdt-2013.md)
|
||||
|
||||
[Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](prepare-for-zero-touch-installation-of-windows-81-with-configuration-manager.md)
|
||||
|
||||
[Create a custom Windows PE boot image with Configuration Manager](create-a-custom-windows-pe-50-boot-image-with-configuration-manager.md)
|
||||
|
||||
[Add a Windows 10 operating system image using Configuration Manager](add-a-windows-81-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-81-using-configuration-manager.md)
|
||||
|
||||
[Add drivers to a Windows 10 deployment with Windows PE using Configuration Manager](add-drivers-to-a-windows-81-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-81-using-pxe-and-configuration-manager.md)
|
||||
|
||||
[Refresh a Windows 7 SP1 client with Windows 10 using Configuration Manager](refresh-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
[Replace a Windows 7 SP1 client with Windows 10 using Configuration Manager](replace-a-windows-7-sp1-client-with-windows-81-using-configuration-manager.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
132
windows/deploy/frequently-asked-questions-usmt-win7-usmt-win8.md
Normal file
132
windows/deploy/frequently-asked-questions-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,132 @@
|
||||
---
|
||||
title: Frequently Asked Questions (Windows 10)
|
||||
description: Frequently Asked Questions
|
||||
ms.assetid: 813c13a7-6818-4e6e-9284-7ee49493241b
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Frequently Asked Questions
|
||||
|
||||
|
||||
The following sections provide frequently asked questions and recommended solutions for migrations using User State Migration Tool (USMT) 10.0.
|
||||
|
||||
## General
|
||||
|
||||
|
||||
### How much space is needed on the destination computer?
|
||||
|
||||
The destination computer needs enough available space for the following:
|
||||
|
||||
- Operating system
|
||||
|
||||
- Applications
|
||||
|
||||
- Uncompressed store
|
||||
|
||||
### Can I store the files and settings directly on the destination computer or do I need a server?
|
||||
|
||||
You do not need to save the files to a server. If you are moving the user state to a new computer, you can create the store on a shared folder, on media that you can remove, such as a USB flash drive (UFD), or you can store it directly on the destination computer, as in the following steps:
|
||||
|
||||
1. Create and share the directory C:\\store on the destination computer.
|
||||
|
||||
2. Run the ScanState tool on the source computer and save the files and settings to \\\\*DestinationComputerName*\\store
|
||||
|
||||
3. Run the LoadState tool on the destination computer and specify C:\\store as the store location.
|
||||
|
||||
### Can I migrate data between operating systems with different languages?
|
||||
|
||||
No. USMT does not support migrating data between operating systems with different languages; the source computer's operating-system language must match the destination computer's operating-system language.
|
||||
|
||||
### Can I change the location of the temporary directory on the destination computer?
|
||||
|
||||
Yes. The environment variable USMT\_WORKING\_DIR can be changed to an alternative temporary directory. There are some offline migration scenarios where this is necessary, for example, when the USMT binaries are located on read-only Windows Preinstallation Environment (WinPE) boot media.
|
||||
|
||||
### How do I install USMT?
|
||||
|
||||
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in your environment. However, the USMT binaries are designed to be deployed using xcopy. This means that they are installed on a computer simply by recursively copying the USMT directory from the computer containing the Windows ADK to each client computer.
|
||||
|
||||
### How do I uninstall USMT?
|
||||
|
||||
If you have installed the Windows ADK on the computer, uninstalling Windows ADK will uninstall USMT. For client computers that do not have the Windows ADK installed, you can simply delete the USMT directory to uninstall USMT.
|
||||
|
||||
## Files and Settings
|
||||
|
||||
|
||||
### How can I exclude a folder or a certain type of file from the migration?
|
||||
|
||||
You can use the **<unconditionalExclude>** element to globally exclude data from the migration. For example, you can use this element to exclude all MP3 files on the computer or to exclude all files from C:\\UserData. This element excludes objects regardless of any other <include> rules that are in the .xml files. For an example, see <unconditionalExclude> in the [Exclude Files and Settings](exclude-files-and-settings-usmt.md) topic. For the syntax of this element, see [XML Elements Library](xml-elements-library-usmt-win7-usmt-win8.md).
|
||||
|
||||
### What happens to files that were located on a drive that does not exist on the destination computer?
|
||||
|
||||
USMT migrates the files to the %SystemDrive% while maintaining the correct folder hierarchy. For example, if E:\\data\\File.pst is on the source computer, but the destination computer does not have an E:\\ drive, the file will be migrated to C:\\data\\File.pst, if C:\\ is the system drive. This holds true even when <locationModify> rules attempt to move data to a drive that does not exist on the destination computer.
|
||||
|
||||
## USMT .xml Files
|
||||
|
||||
|
||||
### Where can I get examples of USMT .xml files?
|
||||
|
||||
The following topics include examples of USMT .xml files:
|
||||
|
||||
- [Exclude Files and Settings](exclude-files-and-settings-usmt.md)
|
||||
|
||||
- [Reroute Files and Settings](reroute-files-and-settings-usmt.md)
|
||||
|
||||
- [Include Files and Settings](include-files-and-settings-usmt.md)
|
||||
|
||||
- [Custom XML Examples](custom-xml-examples-usmt-win7-usmt-win8.md)
|
||||
|
||||
### Can I use custom .xml files that were written for USMT 5.0?
|
||||
|
||||
Yes. You can use custom .xml files that were written for USMT 5.0 with USMT for Windows 10. However, in order to use new USMT functionality, you must revisit your custom USMT files and refresh them to include the new command-line options and XML elements.
|
||||
|
||||
### How can I validate the .xml files?
|
||||
|
||||
You can use the USMT XML Schema (MigXML.xsd) to write and validate migration .xml files.
|
||||
|
||||
### Why must I list the .xml files with both the ScanState and LoadState commands?
|
||||
|
||||
The .xml files are not copied to the store as in previous versions of USMT. Because the ScanState and LoadState tools need the .xml files to control the migration, you must specify the same set of .xml files for the **ScanState** and **LoadState** commands. If you used a particular set of mig\*.xml files in the ScanState tool, either called through the "/auto" option, or individually through the "/i" option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool. 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 with the **LoadState** command. **LoadState** will migrate only the files and settings that you want to migrate.
|
||||
|
||||
If you exclude an .xml file from the **LoadState** command, then all of the data that is in the store that was migrated with the missing .xml files will be migrated. However, the migration rules that were specified for the **ScanState** command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files. Instead, it will migrate them to C:\\data.
|
||||
|
||||
### Which files can I modify and specify on the command line?
|
||||
|
||||
You can specify the MigUser.xml and MigApp.xml files on the command line. You can modify each of these files. The migration of operating system settings is controlled by the manifests, which you cannot modify. If you want to exclude certain operating-system settings or any other components, create and modify the Config.xml file.
|
||||
|
||||
### What happens if I do not specify the .xml files on the command line?
|
||||
|
||||
- **ScanState**
|
||||
|
||||
If you do not specify any files with the **ScanState** command, all user accounts and default operating system components are migrated.
|
||||
|
||||
- **LoadState**
|
||||
|
||||
If you do not specify any files with the **LoadState** command, all data that is in the store is migrated. However, any target-specific migration rules that were specified in .xml files with the **ScanState** command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT will not reroute the files. Instead, it will migrate them to C:\\data.
|
||||
|
||||
## Conflicts and Precedence
|
||||
|
||||
|
||||
### What happens when there are conflicting XML rules or conflicting objects on the destination computer?
|
||||
|
||||
For more information, see [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md).
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[User State Migration Tool (USMT) Troubleshooting](user-state-migration-tool--usmt--troubleshooting.md)
|
||||
|
||||
[Extract Files from a Compressed USMT Migration Store](extract-files-from-a-compressed-usmt-migration-store.md)
|
||||
|
||||
[Verify the Condition of a Compressed Migration Store](verify-the-condition-of-a-compressed-migration-store.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
101
windows/deploy/general-conventions-usmt-win7-usmt-win8.md
Normal file
101
windows/deploy/general-conventions-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,101 @@
|
||||
---
|
||||
title: General Conventions (Windows 10)
|
||||
description: General Conventions
|
||||
ms.assetid: 5761986e-a847-41bd-bf8e-7c1bd01acbc6
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# General Conventions
|
||||
|
||||
|
||||
This topic describes the XML helper functions.
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
[General XML Guidelines](#BKMK_General)
|
||||
|
||||
[Helper Functions](#BKMK_HelperFunctions)
|
||||
|
||||
## General XML Guidelines
|
||||
|
||||
|
||||
Before you modify the .xml files, become familiar with the following guidelines:
|
||||
|
||||
- **XML schema**
|
||||
|
||||
You can use the User State Migration Tool (USMT) 10.0 XML schema, MigXML.xsd, to write and validate migration .xml files.
|
||||
|
||||
- **Conflits**
|
||||
|
||||
In general, when there are conflicts within the XML schema, the most specific pattern takes precedence. For more information, see [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md).
|
||||
|
||||
- **Required elements**
|
||||
|
||||
The required elements for a migration .xml file are **<migration>**, **<component>**, **<role>**, and **<rules>**.
|
||||
|
||||
- **Required child elements**
|
||||
|
||||
- USMT does not fail with an error if you do not specify the required child elements. However, you must specify the required child elements for the parent element to affect the migration.
|
||||
|
||||
- The required child elements apply only to the first definition of the element. If these elements are defined and then referred to using their name, the required child elements do not apply. For example, if you define `<detects name="Example">` in **<namedElements>**, and you specify `<detects name="Example"/>` in **<component>** to refer to this element, the definition inside **<namedElements>** must have the required child elements, but the **<component>** element does not need to have the required child elements.
|
||||
|
||||
- **File names with brackets**
|
||||
|
||||
If you are migrating a file that has a bracket character (\[ or \]) in the file name, you must insert a carat (^) character directly before the bracket for the bracket character to be valid. For example, if there is a file named File.txt, you must specify `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern> `instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
|
||||
|
||||
- **Using quotation marks**
|
||||
|
||||
When you surround code in quotation marks, you can use either double ("") or single (') quotation marks.
|
||||
|
||||
## Helper Functions
|
||||
|
||||
|
||||
You can use the XML helper functions in the [XML Elements Library](xml-elements-library-usmt-win7-usmt-win8.md) to change migration behavior. Before you use these functions in an .xml file, note the following:
|
||||
|
||||
- **All of the parameters are strings**
|
||||
|
||||
- **You can leave NULL parameters blank**
|
||||
|
||||
As with parameters with a default value convention, if you have a NULL parameter at the end of a list, you can leave it out. For example, the following function:
|
||||
|
||||
``` syntax
|
||||
SomeFunction("My String argument",NULL,NULL)
|
||||
```
|
||||
|
||||
is equivalent to:
|
||||
|
||||
``` syntax
|
||||
SomeFunction("My String argument")
|
||||
```
|
||||
|
||||
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object**
|
||||
|
||||
It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This makes a clear distinction between nodes and leaves.
|
||||
|
||||
For example, specify the file C:\\Windows\\Notepad.exe: **c:\\Windows\[Notepad.exe\]**. Similarly, specify the directory C:\\Windows\\System32 like this: **c:\\Windows\\System32**; note the absence of the \[\] characters.
|
||||
|
||||
The registry is represented in a similar way. The default value of a registry key is represented as an empty \[\] construct. For example, the default value for the HKLM\\SOFTWARE\\MyKey registry key is **HKLM\\SOFTWARE\\MyKey\[\]**.
|
||||
|
||||
- **You specify a location pattern in a way that is similar to how you specify an actual location**
|
||||
|
||||
The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.
|
||||
|
||||
For example, the pattern **c:\\Windows\\\*** will match the \\Windows directory and all subdirectories, but it will not match any of the files in those directories. To match the files as well, you must specify **c:\\Windows\\\*\[\*\]**.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Get started with the Microsoft Deployment Toolkit (MDT) (Windows 10)
|
||||
description: This topic will help you gain a better understanding of how to use the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 in particular, 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
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Get started with the Microsoft Deployment Toolkit (MDT)
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
This topic will help you gain a better understanding of how to use the Microsoft Deployment Toolkit (MDT), and MDT 2013 Update 1 in particular, as part of a Windows operating system deployment. MDT is one of the most important tools available to IT professionals today. You can use it to create reference images or as a complete deployment solution. MDT 2013 Update 1 also can be used to extend the operating system deployment features available in Microsoft System Center 2012 R2 Configuration Manager.
|
||||
|
||||
In addition to familiarizing you with the features and options available in MDT 2013 Update 1, 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-81-with-the-microsoft-deployment-toolkit.md#proof).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
## In this section
|
||||
|
||||
|
||||
- [Key features in MDT 2013 Update 1](key-features-in-mdt-2013.md)
|
||||
|
||||
- [MDT 2013 Update 1 Lite Touch components](mdt-2013-lite-touch-components.md)
|
||||
|
||||
- [Prepare for deployment with MDT 2013 Update 1](prepare-for-deployment-with-mdt-2013.md)
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Microsoft Deployment Toolkit downloads and documentation](http://go.microsoft.com/fwlink/p/?LinkId=618117)
|
||||
|
||||
[Create a Windows 10 reference image](create-a-windows-81-reference-image.md)
|
||||
|
||||
[Deploy a Windows 10 image using MDT 2013 Update 1](deploy-a-windows-81-image-using-mdt-2013.md)
|
||||
|
||||
[Build a distributed environment for Windows 10 deployment](build-a-distributed-environment-for-windows-81-deployment.md)
|
||||
|
||||
[Refresh a Windows 7 computer with Windows 10](refresh-a-windows-7-computer-with-windows-81.md)
|
||||
|
||||
[Replace a Windows 7 computer with a Windows 10 computer](replace-a-windows-7-computer-with-a-windows-81-computer.md)
|
||||
|
||||
[Configure MDT settings](configure-mdt-2013-settings.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,113 @@
|
||||
---
|
||||
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: brianlic-msft
|
||||
---
|
||||
|
||||
# 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 One: Plan Your Migration](#BKMK_PlanMig)
|
||||
|
||||
- [Step Two: Collect Files and Settings from the Source Computer](#BKMK_CollectFiles)
|
||||
|
||||
- [Step Three: Prepare the Destination Computer and Restore Files and Settings](#BKMK_PrepareDestination)
|
||||
|
||||
## Step One: Plan Your Migration
|
||||
|
||||
|
||||
1. [Plan Your Migration](plan-your-migration-usmt-win7-usmt-win8.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](common-migration-scenarios-usmt-win7-usmt-win8.md).
|
||||
|
||||
2. [Determine What to Migrate](determine-what-to-migrate-usmt-win7-usmt-win8.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](choose-a-migration-store-type-usmt-win7-usmt-win8.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](scanstate-syntax-usmt-win7-usmt-win8.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-usmt-win7-usmt-win8.md).
|
||||
|
||||
6. Create a [Config.xml File](configxml-file-usmt-win7-usmt-win8.md) if you want to exclude any components from the migration. To create this file, use the [ScanState Syntax](scanstate-syntax-usmt-win7-usmt-win8.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 Two: 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](how-usmt-works-usmt-win7-usmt-win8.md).
|
||||
|
||||
|
||||
|
||||
4. Run the **USMTUtils** command with the **/Verify** option to ensure that the store you created is not corrupted.
|
||||
|
||||
## Step Three: 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](how-usmt-works-usmt-win7-usmt-win8.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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
230
windows/deploy/hard-link-migration-store-usmt-win8.md
Normal file
230
windows/deploy/hard-link-migration-store-usmt-win8.md
Normal file
@ -0,0 +1,230 @@
|
||||
---
|
||||
title: Hard-Link Migration Store (Windows 10)
|
||||
description: Hard-Link Migration Store
|
||||
ms.assetid: b0598418-4607-4952-bfa3-b6e4aaa2c574
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Hard-Link Migration Store
|
||||
|
||||
|
||||
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this is why it is best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs and enables entirely new migration scenarios.
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
[When to Use a Hard-Link Migration](#BKMK_When)
|
||||
|
||||
[Understanding a Hard-Link Migration](#BKMK_UnderstandHardlinkMig)
|
||||
|
||||
[Scenario](#BKMK_Scenario)
|
||||
|
||||
[Hard-Link Migration Store Details](#BKMK_HardLinkStoreDetails)
|
||||
|
||||
[Hard Disk Space](#BKMK_HardDiskSpace)
|
||||
|
||||
[Hard-Link Store Size Estimation](#BKMK_HardLinkStoreSizeEst)
|
||||
|
||||
[Migration Store Path on Multiple Volumes](#BKMK_MigStoreMultVolumes)
|
||||
|
||||
[Location Modifications](#BKMK_LocationModify)
|
||||
|
||||
[Migrating Encrypting File System (EFS) Certificates and Files](#BKMK_EFS)
|
||||
|
||||
[Migrating Locked Files With the Hard-Link Migration Store](#BKMK_MigLockedFiles)
|
||||
|
||||
[XML Elements in the Config.xml File](#BKMK_XMLElementsinConfig)
|
||||
|
||||
## When to Use a Hard-Link Migration
|
||||
|
||||
|
||||
You can use a hard-link migration store when your planned migration meets both of the following criteria:
|
||||
|
||||
- You are upgrading the operating system on existing hardware rather than migrating to new computers.
|
||||
|
||||
- You are upgrading the operating system on the same volume of the computer.
|
||||
|
||||
You cannot use a hard-link migration store if your planned migration includes any of the following:
|
||||
|
||||
- You are migrating data from one computer to a second computer.
|
||||
|
||||
- You are migrating data from one volume on a computer to another volume, for example from C: to D:.
|
||||
|
||||
- You are formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store.
|
||||
|
||||
## Understanding a Hard-Link Migration
|
||||
|
||||
|
||||
The hard-link migration store is created using the command-line option, **/hardlink**, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.
|
||||
|
||||
When you create a hard link, you give an existing file an additional path. For instance, you could create a hard link to c:\\file1.txt called c:\\hard link\\myFile.txt. These are two paths to the same file. If you open c:\\file1.txt, make changes, and save the file, you will see those changes when you open c:\\hard link\\myFile.txt. If you delete c:\\file1.txt, the file still exists on your computer as c:\\hardlink\\myFile.txt. You must delete both references to the file in order to delete the file.
|
||||
|
||||
**Note**
|
||||
A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario.
|
||||
|
||||
|
||||
|
||||
For more information about hard links, please see [Hard Links and Junctions](http://go.microsoft.com/fwlink/p/?LinkId=132934)
|
||||
|
||||
In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows® Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.
|
||||
|
||||
As a best practice, we recommend that you delete the hard-link migration store after you confirm that the Loadstate tool has successfully migrated the files. Since Loadstate has created new paths to the files on your new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files and will not delete the actual files or the paths to them from your new operating system.
|
||||
|
||||
**Important**
|
||||
Using the **/c** option will force the Loadstate tool to continue applying files when non-fatal errors occur. If you use the **/c** option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.
|
||||
|
||||
|
||||
|
||||
Keeping the hard-link migration store can result in additional disk space being consumed or problems with some applications for the following reasons:
|
||||
|
||||
- Applications reporting file-system statistics, for example, space used and free space, might incorrectly report these statistics while the hard-link migration store is present. The file may be reported twice because of the two paths that reference that file.
|
||||
|
||||
- A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that was not used to open the file in this application will continue to refer to the unmodified file. The unmodified file that is not in use is taking up additional disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you are migrating the latest versions of all files.
|
||||
|
||||
- Editing the file by using different paths simultaneously may result in data corruption.
|
||||
|
||||
**Important**
|
||||
The read-only file attribute on migrated files is lost when the hard-link migration store is deleted. This is due to a limitation in NTFS file system hard links.
|
||||
|
||||
|
||||
|
||||
## Hard-Link Migration Scenario
|
||||
|
||||
|
||||
For example, a company has decided to deploy Windows 10 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.
|
||||
|
||||
1. An administrator runs the ScanState command-line tool on each computer, specifying the **/hardlink** command-line option. The ScanState tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.
|
||||
|
||||
**Note**
|
||||
As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with Loadstate.
|
||||
|
||||
|
||||
|
||||
2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7 and other applications the company currently uses.
|
||||
|
||||
3. An administrator runs the LoadState command-line tool on each computer. The LoadState tool restores user state back on each computer.
|
||||
|
||||
## Hard-Link Migration Store Details
|
||||
|
||||
|
||||
This section provides details about hard-link migration stores.
|
||||
|
||||
### Hard Disk Space
|
||||
|
||||
The **/hardlink** command-line option proceeds with creating the migration store only if there is 250 megabytes (MB) of free space on the hard disk. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless on the size of the migration.
|
||||
|
||||
### Hard-Link Store Size Estimation
|
||||
|
||||
It is not necessary to estimate the size of a hard-link migration store. Estimating the size of a migration store is only useful in scenarios where the migration store is very large, and on NTFS volumes the hard-link migration store will require much less incremental space than other store options. The only case where the local store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows XP and newer operating systems, this situation is unusual.
|
||||
|
||||
### Migration Store Path on Multiple Volumes
|
||||
|
||||
Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location will be specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names will be created on every volume containing data being migrated. For example:
|
||||
|
||||
`Scanstate /hardlink c:\USMTMIG […]`
|
||||
|
||||
Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive will generate migration stores in the following locations, assuming that both drives are NTFS:
|
||||
|
||||
C:\\USMTMIG\\
|
||||
|
||||
D:\\USMTMIG\\
|
||||
|
||||
The drive you specify on the command line for the hard-link migration store is important, because it defines where the *master migration store* should be placed. The *master migration store* is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the **/o** option must be used to overwrite the existing data in the store.
|
||||
|
||||
### Location Modifications
|
||||
|
||||
Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This is because the migrating data that must cross system volumes cannot remain in the hard-link migration store, and must be copied across the system volumes.
|
||||
|
||||
### Migrating Encrypting File System (EFS) Certificates and Files
|
||||
|
||||
To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the **/efs:hardlink** option in the Scanstate command-line syntax.
|
||||
|
||||
If the EFS files are being restored to a different partition, you should use the **/efs:copyraw** option instead of the **/efs:hardlink** option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The **/efs:copyraw** option will copy the files to the new partition in encrypted format.
|
||||
|
||||
For more information, see [Migrate EFS Files and Certificates](migrate-efs-files-and-certificates-umst.md) and the Encrypted File Options in [ScanState Syntax](scanstate-syntax-usmt-win7-usmt-win8.md).
|
||||
|
||||
### Migrating Locked Files with the Hard-Link Migration Store
|
||||
|
||||
Files that are locked by an application or the operating system are handled differently when using a hard-link migration store.
|
||||
|
||||
Files that are locked by the operating system cannot remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you do not migrate any files out of the \\Windows directory, which minimizes performance-related issues.
|
||||
|
||||
Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service is not being utilized. The volume shadow-copy service cannot be used in conjunction with hard-link migrations. However, by modifying the new **<HardLinkStoreControl>** section in the Config.xml file, it is possible to enable the migration of files locked by an application.
|
||||
|
||||
**Important**
|
||||
There are some scenarios in which modifying the **<HardLinkStoreControl>** section in the Config.xml file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use USMTutils.exe to schedule the migration store for deletion on the next restart.
|
||||
|
||||
|
||||
|
||||
## XML Elements in the Config.xml File
|
||||
|
||||
|
||||
A new section in the Config.xml file allows optional configuration of some of the hard-link migration behavior introduced with the **/HardLink** option.
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
<col width="50%" />
|
||||
<col width="50%" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong><Policies></strong></p></td>
|
||||
<td align="left"><p>This element contains elements that describe the policies that USMT follows while creating a migration store.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong><HardLinkStoreControl></strong></p></td>
|
||||
<td align="left"><p>This element contains elements that describe how to handle files during the creation of a hard link migration store.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong><fileLocked></strong></p></td>
|
||||
<td align="left"><p>This element contains elements that describe how to handle files that are locked for editing.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong><createHardLink></strong></p></td>
|
||||
<td align="left"><p>This element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.</p>
|
||||
<p>Syntax: <createHardLink> [pattern] </createHardLink></p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong><errorHardLink></strong></p></td>
|
||||
<td align="left"><p>This element defines a standard MigXML pattern that describes file paths where hard links should not be created, if the file is locked for editing by another application.</p>
|
||||
<p><errorHardLink> [pattern] </errorHardLink></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
**Important**
|
||||
You must use the **/nocompress** option with the **/HardLink** option.
|
||||
|
||||
|
||||
|
||||
The following XML sample specifies that files locked by an application under the \\Users directory can remain in place during the migration. It also specifies that locked files that are not located in the \\Users directory should result in the **File in Use** error. It is important to exercise caution when specifying the paths using the **File in Use<createhardlink>** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
|
||||
|
||||
``` syntax
|
||||
<Policies>
|
||||
<HardLinkStoreControl>
|
||||
<fileLocked>
|
||||
<createHardLink>c:\Users\* [*]</createHardLink>
|
||||
<errorHardLink>C:\* [*]</errorHardLink>
|
||||
</fileLocked>
|
||||
</HardLinkStoreControl>
|
||||
</Policies>
|
||||
```
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Plan Your Migration](plan-your-migration-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
145
windows/deploy/how-usmt-works-usmt-win7-usmt-win8.md
Normal file
145
windows/deploy/how-usmt-works-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,145 @@
|
||||
---
|
||||
title: How USMT Works (Windows 10)
|
||||
description: How USMT Works
|
||||
ms.assetid: 5c8bd669-9e1e-473d-81e6-652f40b24171
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# How USMT Works
|
||||
|
||||
|
||||
USMT includes two tools that migrate settings and data: ScanState and LoadState. ScanState collects information from the source computer, and LoadState applies that information to the destination computer.
|
||||
|
||||
- [ScanState Process](#BKMK_SSProcess)
|
||||
|
||||
- [LoadState Process](#BKMK_LSProcess)
|
||||
|
||||
**Note**
|
||||
For more information about how USMT processes the rules and the XML files, see [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md).
|
||||
|
||||
|
||||
|
||||
## The ScanState Process
|
||||
|
||||
|
||||
When you run the ScanState tool on the source computer, it goes through the following process:
|
||||
|
||||
1. It parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
|
||||
|
||||
2. It collects information about all of the migration components that need to be migrated. A *migration component* is a logical group of files, registry keys, and values. For example, the set of files, registry keys, and values that store the settings of Adobe Acrobat is grouped into a single migration component.
|
||||
|
||||
There are three types of components:
|
||||
|
||||
- Components that migrate the operating system settings
|
||||
|
||||
- Components that migrate application settings
|
||||
|
||||
- Components that migrate users’ files
|
||||
|
||||
The ScanState tool collects information about the application settings and user data components from the .xml files that are specified on the command line.
|
||||
|
||||
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
|
||||
|
||||
3. ScanState determines which user profiles should be migrated. By default, all user profiles on the source computer are migrated. However, you can include and exclude users using the User Options. The public profile in a source computer running Windows 7, Windows 8, and Windows 10 is always migrated, and you cannot exclude these profiles from the migration.
|
||||
|
||||
4. In the "Scanning" phase, ScanState does the following for each user profile selected for migration:
|
||||
|
||||
1. For each component, ScanState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
|
||||
|
||||
**Note**
|
||||
From this point on, ScanState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. ScanState processes all components in the same way.
|
||||
|
||||
|
||||
|
||||
2. Each component that is selected in the previous step is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile that is being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents, assuming that the user profiles are stored in the C:\\Users directory.
|
||||
|
||||
3. For each selected component, ScanState evaluates the <detects> section. If the condition in the <detects> section evaluates to false, the component is not processed any further. Otherwise, the processing of this component continues.
|
||||
|
||||
4. For each selected component, ScanState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
|
||||
|
||||
5. ScanState creates a list of migration units that need to be migrated by processing the various subsections under this <rules> section. Each unit is collected if it is mentioned in an <include> subsection, as long as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence in the .xml files, see [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md).
|
||||
|
||||
In addition, any migration unit (such as a file, registry key, or set of registry values) that is in an <UnconditionalExclude> section is not migrated.
|
||||
|
||||
**Note**
|
||||
ScanState ignores some subsections such as <destinationCleanup> and <locationModify>. These sections are evaluated only on the destination computer.
|
||||
|
||||
|
||||
|
||||
5. In the "Collecting" phase, ScanState creates a master list of the migration units by combining the lists that were created for each selected user profile.
|
||||
|
||||
6. In the "Saving" phase, ScanState writes the migration units that were collected to the store location.
|
||||
|
||||
**Note**
|
||||
ScanState does not modify the source computer in any way.
|
||||
|
||||
|
||||
|
||||
## The LoadState Process
|
||||
|
||||
|
||||
The LoadState process is very similar to the ScanState process. The ScanState tool collects migration units such as file, registry key, or registry values from the source computer and saves them to the store. Similarly, the LoadState tool collects migration units from the store and applies them to the destination computer.
|
||||
|
||||
1. ScanState parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
|
||||
|
||||
2. LoadState collects information about the migration components that need to be migrated.
|
||||
|
||||
LoadState obtains information for the application-settings components and user-data components from the migration .xml files that are specified by the LoadState command.
|
||||
|
||||
In Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
|
||||
|
||||
3. LoadState determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the User Options. The system profile, the "All users" profile in a source computer running Windows XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated and you cannot exclude these profiles from the migration.
|
||||
|
||||
- If you are migrating local user accounts and if the accounts do not already exist on the destination computer, you must use the**/lac** command-line option. If you do not specify the **/lac** option, any local user accounts that are not already present on the destination computer, are not migrated.
|
||||
|
||||
- The **/md** and **/mu** options are processed to rename the user profile on the destination computer, if they have been included when the LoadState command was specified.
|
||||
|
||||
- For each user profile selected from the store, LoadState creates a corresponding user profile on the destination computer. The destination computer does not need to be connected to the domain for domain user profiles to be created. If USMT cannot determine a domain, it attempts to apply the settings to a local account. For more information, see [Identify Users](identify-users-usmt-win7-usmt-win8.md).
|
||||
|
||||
4. In the "Scanning" phase, LoadState does the following for each user profile:
|
||||
|
||||
1. For each component, LoadState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
|
||||
|
||||
**Note**
|
||||
From this point on, LoadState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. LoadState evaluates all components in the same way.
|
||||
|
||||
|
||||
|
||||
2. Each component that is selected is processed further. Any profile-specific variables (such as CSIDL\_PERSONAL) are evaluated in the context of the current profile. For example, if the profile being processed belongs to “User1”, then CSIDL\_PERSONAL would expand to C:\\Users\\User1\\Documents (assuming that the user profiles are stored in the C:\\Users directory).
|
||||
|
||||
**Note**
|
||||
LoadState ignores the <detects> section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.
|
||||
|
||||
|
||||
|
||||
3. For each selected component, LoadState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
|
||||
|
||||
4. LoadState creates a master list of migration units by processing the various subsections under the <rules> section. Each migration unit that is in an <include> subsection is migrated as long, as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence, see [Conflicts and Precedence](conflicts-and-precedence-usmt-win7-usmt-win8.md).
|
||||
|
||||
5. LoadState evaluates the destination computer-specific subsections; for example, the <destinationCleanup> and <locationModify> subsections.
|
||||
|
||||
6. If the destination computer is running Windows 7 or Windows 8 then the migunits that were collected by ScanState using downlevel manifest files are processed by LoadState using the corresponding Component Manifest for Windows 7. The downlevel manifest files are not used during LoadState.
|
||||
|
||||
**Important**
|
||||
It is important to specify the .xml files with the LoadState command if you want LoadState to use them. Otherwise, any destination-specific rules, such as <locationModify>, in these .xml files are ignored, even if the same .xml files were provided when the ScanState command ran.
|
||||
|
||||
|
||||
|
||||
5. In the "Apply" phase, LoadState writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there is not a <merge> rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally, for example, OriginalFileName(1).OriginalExtension. Some settings, such as fonts, wallpaper, and screen-saver settings, do not take effect until the next time the user logs on. For this reason, you should log off when the LoadState command actions have completed.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[User State Migration Tool (USMT) Command-line Syntax](user-state-migration-tool--usmt--command-line-syntax.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,57 @@
|
||||
---
|
||||
title: Identify Applications Settings (Windows 10)
|
||||
description: Identify Applications Settings
|
||||
ms.assetid: eda68031-9b02-4a5b-a893-3786a6505381
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Identify Applications Settings
|
||||
|
||||
|
||||
When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see [Customize USMT XML Files](customize-usmt-xml-files-usmt-win7-usmt-win8.md).
|
||||
|
||||
## Applications
|
||||
|
||||
|
||||
First, create and prioritize a list of applications that to be migrated. It may be helpful to review the application lists and decide which applications will be redeployed and which applications will be retired. Often, the applications are prioritized based on a combination of how widely the application is used and how complex the application is.
|
||||
|
||||
Next, identify an application owner to be in charge of each application. This is necessary because the developers will not be experts on all of the applications in the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.
|
||||
|
||||
## Application Settings
|
||||
|
||||
|
||||
Next, determine and locate the application settings to be migrated. You can acquire much of the information that you need for this step when you are testing the new applications for compatibility with the new operating system.
|
||||
|
||||
After completing the list of applications to be migrated, review the list and work with each application owner on a list of settings to be migrated. For each setting, determine whether it needs to be migrated or if the default settings are adequate. Then, determine where the setting is located; for example, in the registry or in an .ini file. Next, consider the following questions to determine what needs to be done to migrate the setting successfully:
|
||||
|
||||
- Is the destination version of the application newer than the source version?
|
||||
|
||||
- Do these settings work with the new version?
|
||||
|
||||
- Do the settings need to be moved or altered?
|
||||
|
||||
- Can the first-run process force the application to appear as if it had run already? If so, does this work correctly, or does it break the application?
|
||||
|
||||
After answering these questions, create a custom .xml file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.
|
||||
|
||||
## Locating Where Settings Are Stored
|
||||
|
||||
|
||||
See [Migrate Application Settings](migrate-application-settings.md) and follow the directions.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Determine What to Migrate](determine-what-to-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,46 @@
|
||||
---
|
||||
title: Identify File Types, Files, and Folders (Windows 10)
|
||||
description: Identify File Types, Files, and Folders
|
||||
ms.assetid: 93bb2a33-c126-4f7a-a961-6c89686d54e0
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Identify File Types, Files, and Folders
|
||||
|
||||
|
||||
When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as **My Documents.** , **C:\\Data** , and company-specified locations, such as **\\EngineeringDrafts**. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following:
|
||||
|
||||
- **File types**. Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses .doc, .docx and .dotx file name extension. However, it also uses other file types, such as templates (.dot files), on a less frequent basis.
|
||||
|
||||
- **Excluded locations**. Consider the locations on the computer that should be excluded from the migration (for example, %WINDIR% and Program Files).
|
||||
|
||||
- **New locations**. Decide where files should be migrated to on the destination computer for example, \\My Documents, a designated folder, or a folder matching the files' name and location on the source computer. For example, you might have shared data on source machine or you might wish to clean up documents outside the user profiles on the source system. Identify any data that needs to be redirected to a new location in the apply phase. This can be accomplished with location modify rules.
|
||||
|
||||
Once you have verified which files and file types that the end users work with regularly, you will need to locate them. Files may be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer.
|
||||
|
||||
**To find the registered file types on a computer running Windows 7 or Windows 8**
|
||||
|
||||
1. Click **Start**. Open **Control Panel**, click **Control Panel Home**, and click **Programs**.
|
||||
|
||||
2. Click **Default Programs**, and click **Associate a file type or protocol with a program**.
|
||||
|
||||
3. On this screen, the registered file types are displayed.
|
||||
|
||||
For more information about how to change the file types, files, and folders that are migrated when you specify the MigUser.xml file, see [User State Migration Tool (USMT) How-to topics](user-state-migration-tool--usmt--how-to-topics.md).
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Determine What to Migrate](determine-what-to-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Identify Operating System Settings (Windows 10)
|
||||
description: Identify Operating System Settings
|
||||
ms.assetid: 1704ab18-1765-41fb-a27c-3aa3128fa242
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Identify Operating System Settings
|
||||
|
||||
|
||||
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) 10.0 enables you to migrate select settings and keep the default values for all others. The operating system settings include the following:
|
||||
|
||||
- **Apperance.**
|
||||
|
||||
This includes items such as wallpaper, colors, sounds, and the location of the taskbar.
|
||||
|
||||
- **Action.**
|
||||
|
||||
This includes items such as the key-repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to single-click or double-click an item to open it.
|
||||
|
||||
- **Internet.**
|
||||
|
||||
These are the settings that let you connect to the Internet and control how your browser operates. This includes items such as your home page URL, favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
|
||||
|
||||
- **Mail.**
|
||||
|
||||
This includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
|
||||
|
||||
To help you decide which settings to migrate, you should consider any previous migration experiences as well as the results of any surveys and tests that you have conducted. You should also consider the number of help-desk calls related to operating-system settings that you have had in the past, and are able to handle in the future. Also decide how much of the new operating-system functionality you want to take advantage of.
|
||||
|
||||
You should migrate any settings that users need to get their jobs done, those that make the work environment comfortable, and those that will reduce help-desk calls after the migration. Although it is easy to dismiss migrating user preferences, you should consider that users can spend a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users do not remember how these settings were applied. Although these items are not critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
|
||||
|
||||
**Note**
|
||||
For more information about how to change the operating-system settings that are migrated, see [User State Migration Tool (USMT) How-to topics](user-state-migration-tool--usmt--how-to-topics.md).
|
||||
|
||||
For information about the operating-system settings that USMT migrates, see [What Does USMT Migrate?](what-does-usmt-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Determine What to Migrate](determine-what-to-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
85
windows/deploy/identify-users-usmt-win7-usmt-win8.md
Normal file
85
windows/deploy/identify-users-usmt-win7-usmt-win8.md
Normal file
@ -0,0 +1,85 @@
|
||||
---
|
||||
title: Identify Users (Windows 10)
|
||||
description: Identify Users
|
||||
ms.assetid: 957a4fe9-79fd-44a2-8c26-33e50f71f9de
|
||||
ms.prod: W10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
author: brianlic-msft
|
||||
---
|
||||
|
||||
# Identify Users
|
||||
|
||||
|
||||
It is important to carefully consider how you plan to migrate users. By default, all users are migrated by User State Migration Tool (USMT) 5.0. You must specify which users to include by using the command line. You cannot specify users in the .xml files. For instructions on how to migrate users, see [Migrate User Accounts](migrate-user-accounts-usmt.md).
|
||||
|
||||
## In This Topic
|
||||
|
||||
|
||||
- [Migrating Local Accounts](#BKMK_8)
|
||||
|
||||
- [Migrating Domain Accounts](#BKMK_9)
|
||||
|
||||
- [Command-Line Options](#BKMK_7)
|
||||
|
||||
## Migrating Local Accounts
|
||||
|
||||
|
||||
Before migrating local accounts, note the following:
|
||||
|
||||
- [You must explicitly specify that local accounts that are not on the destination computer should be migrated.](#BKMK_8) If you are migrating local accounts and the local account does not exist on the destination computer, you must use the**/lac** option when using the LoadState command. If the **/lac** option is not specified, no local user accounts will be migrated.
|
||||
|
||||
- [Consider whether to enable user accounts that are new to the destination computer.](#BKMK_8) The **/lae** option enables the account that was created with the **/lac** option. However, if you create a disabled local account by using only the **/lac** option, a local administrator must enable the account on the destination computer.
|
||||
|
||||
- [Be careful when specifying a password for local accounts.](#BKMK_8) If you create the local account with a blank password, anyone could log on to that account on the destination computer. If you create the local account with a password, the password is available to anyone with access to the USMT command-line tools.
|
||||
|
||||
**Note**
|
||||
If there are multiple users on a computer, and you specify a password with the **/lac** option, all migrated users will have the same password.
|
||||
|
||||
|
||||
|
||||
## Migrating Domain Accounts
|
||||
|
||||
|
||||
The source and destination computers do not need to be connected to the domain for domain user profiles to be migrated.
|
||||
|
||||
## Command-Line Options
|
||||
|
||||
|
||||
USMT provides several options to migrate multiple users on a single computer. The following command-line options specify which users to migrate.
|
||||
|
||||
- [Specifying users.](#BKMK_8) You can specify which users to migrate with the **/all**, **/ui**, **/uel**, and **/ue** options with both the ScanState and LoadState command-line tools.
|
||||
|
||||
**Important**
|
||||
The **/uel** option excludes users based on the **LastModified** date of the Ntuser.dat file. The **/uel** option is not valid in offline migrations.
|
||||
|
||||
|
||||
|
||||
- [Moving users to another domain.](#BKMK_8) You can move user accounts to another domain using the **/md** option with the LoadState command-line tool.
|
||||
|
||||
- [Creating local accounts.](#BKMK_8) You can create and enable local accounts using the **/lac** and **/lae** options with the LoadState command-line tool.
|
||||
|
||||
- [Renaming user accounts.](#BKMK_8) You can rename user accounts using the **/mu** option.
|
||||
|
||||
**Note**
|
||||
By default, if a user name is not specified in any of the command-line options, the user will be migrated.
|
||||
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
[Determine What to Migrate](determine-what-to-migrate-usmt-win7-usmt-win8.md)
|
||||
|
||||
[ScanState Syntax](scanstate-syntax-usmt-win7-usmt-win8.md)
|
||||
|
||||
[LoadState Syntax](loadstate-syntax-usmt-win7-usmt-win8.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
windows/deploy/images/checkmark.png
Normal file
BIN
windows/deploy/images/checkmark.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.2 KiB |
BIN
windows/deploy/images/crossmark.png
Normal file
BIN
windows/deploy/images/crossmark.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
windows/deploy/images/dep-win8-l-usmt-pcrefresh.jpg
Normal file
BIN
windows/deploy/images/dep-win8-l-usmt-pcrefresh.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
BIN
windows/deploy/images/dep-win8-l-usmt-pcreplace.jpg
Normal file
BIN
windows/deploy/images/dep-win8-l-usmt-pcreplace.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
BIN
windows/deploy/images/dep-win8-l-vamt-findingcomputerdialog.gif
Normal file
BIN
windows/deploy/images/dep-win8-l-vamt-findingcomputerdialog.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
BIN
windows/deploy/images/dep-win8-l-vamt-image001-enterprise.jpg
Normal file
BIN
windows/deploy/images/dep-win8-l-vamt-image001-enterprise.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
BIN
windows/deploy/images/fig10-contosoinstall.png
Normal file
BIN
windows/deploy/images/fig10-contosoinstall.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
BIN
windows/deploy/images/fig10-unattend.png
Normal file
BIN
windows/deploy/images/fig10-unattend.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
BIN
windows/deploy/images/fig13-captureimage.png
Normal file
BIN
windows/deploy/images/fig13-captureimage.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
BIN
windows/deploy/images/fig16-contentstatus.png
Normal file
BIN
windows/deploy/images/fig16-contentstatus.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
BIN
windows/deploy/images/fig17-win10image.png
Normal file
BIN
windows/deploy/images/fig17-win10image.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
BIN
windows/deploy/images/fig18-distwindows.png
Normal file
BIN
windows/deploy/images/fig18-distwindows.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 121 KiB |
BIN
windows/deploy/images/fig2-gather.png
Normal file
BIN
windows/deploy/images/fig2-gather.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
windows/deploy/images/fig2-importedos.png
Normal file
BIN
windows/deploy/images/fig2-importedos.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
BIN
windows/deploy/images/fig2-taskseq.png
Normal file
BIN
windows/deploy/images/fig2-taskseq.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 188 KiB |
BIN
windows/deploy/images/fig21-add-drivers.png
Normal file
BIN
windows/deploy/images/fig21-add-drivers.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
BIN
windows/deploy/images/fig22-createcategories.png
Normal file
BIN
windows/deploy/images/fig22-createcategories.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.4 KiB |
BIN
windows/deploy/images/fig27-driverpackage.png
Normal file
BIN
windows/deploy/images/fig27-driverpackage.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
windows/deploy/images/fig28-addapp.png
Normal file
BIN
windows/deploy/images/fig28-addapp.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
BIN
windows/deploy/images/fig30-settingspack.png
Normal file
BIN
windows/deploy/images/fig30-settingspack.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
windows/deploy/images/fig32-deploywiz.png
Normal file
BIN
windows/deploy/images/fig32-deploywiz.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 140 KiB |
BIN
windows/deploy/images/fig4-oob-drivers.png
Normal file
BIN
windows/deploy/images/fig4-oob-drivers.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 95 KiB |
BIN
windows/deploy/images/fig5-selectprofile.png
Normal file
BIN
windows/deploy/images/fig5-selectprofile.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
BIN
windows/deploy/images/fig6-taskseq.png
Normal file
BIN
windows/deploy/images/fig6-taskseq.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
windows/deploy/images/fig8-cust-tasks.png
Normal file
BIN
windows/deploy/images/fig8-cust-tasks.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
windows/deploy/images/fig8-suspend.png
Normal file
BIN
windows/deploy/images/fig8-suspend.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
BIN
windows/deploy/images/fig9-resumetaskseq.png
Normal file
BIN
windows/deploy/images/fig9-resumetaskseq.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 238 KiB |
BIN
windows/deploy/images/figure4-deployment-workbench.png
Normal file
BIN
windows/deploy/images/figure4-deployment-workbench.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 77 KiB |
BIN
windows/deploy/images/mdt-01-fig01.png
Normal file
BIN
windows/deploy/images/mdt-01-fig01.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
BIN
windows/deploy/images/mdt-01-fig02.jpg
Normal file
BIN
windows/deploy/images/mdt-01-fig02.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
BIN
windows/deploy/images/mdt-03-fig01.png
Normal file
BIN
windows/deploy/images/mdt-03-fig01.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9.4 KiB |
BIN
windows/deploy/images/mdt-03-fig02.png
Normal file
BIN
windows/deploy/images/mdt-03-fig02.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 87 KiB |
BIN
windows/deploy/images/mdt-03-fig03.png
Normal file
BIN
windows/deploy/images/mdt-03-fig03.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 252 KiB |
BIN
windows/deploy/images/mdt-03-fig04.png
Normal file
BIN
windows/deploy/images/mdt-03-fig04.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
BIN
windows/deploy/images/mdt-03-fig05.png
Normal file
BIN
windows/deploy/images/mdt-03-fig05.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
windows/deploy/images/mdt-04-fig01.png
Normal file
BIN
windows/deploy/images/mdt-04-fig01.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.3 KiB |
BIN
windows/deploy/images/mdt-05-fig01.png
Normal file
BIN
windows/deploy/images/mdt-05-fig01.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.2 KiB |
BIN
windows/deploy/images/mdt-05-fig02.png
Normal file
BIN
windows/deploy/images/mdt-05-fig02.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
windows/deploy/images/mdt-05-fig03.png
Normal file
BIN
windows/deploy/images/mdt-05-fig03.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 232 KiB |
BIN
windows/deploy/images/mdt-05-fig04.png
Normal file
BIN
windows/deploy/images/mdt-05-fig04.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
BIN
windows/deploy/images/mdt-05-fig05.png
Normal file
BIN
windows/deploy/images/mdt-05-fig05.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
BIN
windows/deploy/images/mdt-05-fig07.png
Normal file
BIN
windows/deploy/images/mdt-05-fig07.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 77 KiB |
BIN
windows/deploy/images/mdt-05-fig08.png
Normal file
BIN
windows/deploy/images/mdt-05-fig08.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
windows/deploy/images/mdt-05-fig09.png
Normal file
BIN
windows/deploy/images/mdt-05-fig09.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 115 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user