mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-22 05:43:41 +00:00
Merge branch 'master' of https://github.com/MicrosoftDocs/windows-docs-pr into tocideas
This commit is contained in:
Greg Lindsay
@ -118,7 +118,7 @@ When Microsoft officially releases a feature update for Windows 10, it is made a
|
||||
Organizations are expected to initiate targeted deployment on Semi-Annual Channel releases. All customers, independent software vendors (ISVs), and partners should use this time for testing and piloting within their environments. After 2-4 months, we will transition to broad deployment and encourage customers and partners to expand and accelerate the deployment of the release. For customers using Windows Update for Business, the Semi-Annual Channel provides three months of additional total deployment time before being required to update to the next release.
|
||||
|
||||
> [!NOTE]
|
||||
> All releases of Windows 10 have 18 months of servicing for all editions--these updates provide security and feature updates for the release. Customers running Enterprise and Education editions have an additional 12 months of servicing for specific Windows 10 releases, for a total of 30 months from initial release. These versions include Enterprise and Education editions for Windows 10, versions 1607 and later. Starting in October 2018, all Semi-Annual Channel releases in the September/October timeframe will also have the additional 12 months of servicing for a total of 30 months from the initial release. The Semi-Annual Channel versions released in March/April timeframe will continue to have an 18-month lifecycle.
|
||||
> All releases of Windows 10 have **18 months of servicing for all editions**--these updates provide security and feature updates for the release. However, fall releases of the **Enterprise and Education editions** will have an **additional 12 months of servicing for specific Windows 10 releases, for a total of 30 months from initial release**. This extended servicing window applies to Enterprise and Education editions starting with Windows 10, version 1607.
|
||||
>
|
||||
>
|
||||
> [!NOTE]
|
||||
|
||||
@ -1,65 +1,66 @@
|
||||
---
|
||||
title: Identify Users (Windows 10)
|
||||
description: Identify Users
|
||||
ms.assetid: 957a4fe9-79fd-44a2-8c26-33e50f71f9de
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
ms.author: greglin
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
audience: itpro
|
||||
author: greg-lindsay
|
||||
ms.topic: article
|
||||
---
|
||||
|
||||
# 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](usmt-migrate-user-accounts.md).
|
||||
|
||||
## In This Topic
|
||||
|
||||
- [Migrating Local Accounts](#bkmk-8)
|
||||
- [Migrating Domain Accounts](#bkmk-9)
|
||||
- [Command-Line Options](#bkmk-7)
|
||||
|
||||
## <a href="" id="bkmk-8"></a>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.
|
||||
|
||||
## <a href="" id="bkmk-9"></a>Migrating Domain Accounts
|
||||
|
||||
The source and destination computers do not need to be connected to the domain for domain user profiles to be migrated.
|
||||
|
||||
## <a href="" id="bkmk-7"></a>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](usmt-determine-what-to-migrate.md)<br>
|
||||
[ScanState Syntax](usmt-scanstate-syntax.md)<br>
|
||||
[LoadState Syntax](usmt-loadstate-syntax.md)
|
||||
---
|
||||
title: Identify Users (Windows 10)
|
||||
description: Identify Users
|
||||
ms.assetid: 957a4fe9-79fd-44a2-8c26-33e50f71f9de
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
ms.author: greglin
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
audience: itpro
|
||||
author: greg-lindsay
|
||||
ms.topic: article
|
||||
ms.localizationpriority: medium
|
||||
---
|
||||
|
||||
# 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](usmt-migrate-user-accounts.md).
|
||||
|
||||
## In This Topic
|
||||
|
||||
- [Migrating Local Accounts](#bkmk-8)
|
||||
- [Migrating Domain Accounts](#bkmk-9)
|
||||
- [Command-Line Options](#bkmk-7)
|
||||
|
||||
## <a href="" id="bkmk-8"></a>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.
|
||||
|
||||
## <a href="" id="bkmk-9"></a>Migrating Domain Accounts
|
||||
|
||||
The source and destination computers do not need to be connected to the domain for domain user profiles to be migrated.
|
||||
|
||||
## <a href="" id="bkmk-7"></a>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](usmt-determine-what-to-migrate.md)<br>
|
||||
[ScanState Syntax](usmt-scanstate-syntax.md)<br>
|
||||
[LoadState Syntax](usmt-loadstate-syntax.md)
|
||||
|
||||
@ -9,7 +9,8 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: activation
|
||||
audience: itpro
|
||||
audience: itpro
|
||||
author: greg-lindsay
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 03/11/2019
|
||||
ms.topic: article
|
||||
@ -34,8 +35,9 @@ You install VAMT as part of the Windows Assessment and Deployment Kit (ADK) for
|
||||
- [Windows Server with Desktop Experience](https://docs.microsoft.com/windows-server/get-started/getting-started-with-server-with-desktop-experience), with internet access and all updates applied
|
||||
- [Windows 10, version 1809 ADK](https://go.microsoft.com/fwlink/?linkid=2026036)
|
||||
- [SQL Server 2017 Express](https://www.microsoft.com/sql-server/sql-server-editions-express)
|
||||
- alternatively any full SQL instance e.g. SQL Server 2014 or newer incl. CU / SP
|
||||
|
||||
|
||||
### Install SQL Server 2017 Express / alternatively use any Full SQL instance e.g. SQL Server 2014 or newer
|
||||
|
||||
1. Download and open the [SQL Server 2017 Express](https://www.microsoft.com/sql-server/sql-server-editions-express) package.
|
||||
2. Select **Basic**.
|
||||
@ -46,20 +48,23 @@ You install VAMT as part of the Windows Assessment and Deployment Kit (ADK) for
|
||||
|
||||
### Install VAMT using the ADK
|
||||
|
||||
|
||||
1. Download and open the [Windows 10, version 1903 ADK](https://go.microsoft.com/fwlink/?linkid=2086042) package.
|
||||
Reminder: There won't be new ADK release for 1909.
|
||||
2. Enter an install location or use the default path, and then select **Next**.
|
||||
3. Select a privacy setting, and then select **Next**.
|
||||
4. Accept the license terms.
|
||||
5. On the **Select the features you want to install** page, select **Volume Activation Management Tool (VAMT)**, and then select **Install**. (You can select additional features to install as well.)
|
||||
6. On the completion page, select **Close**.
|
||||
|
||||
|
||||
### Configure VAMT to connect to SQL Server 2017 Express or full SQL Server
|
||||
|
||||
1. Open **Volume Active Management Tool 3.1** from the Start menu.
|
||||
1. Open **Volume Active Management Tool 3.1** from the Start menu.
|
||||
2. Enter the server instance name (for a remote SQL use the FQDN) and a name for the database, select **Connect**, and then select **Yes** to create the database. See the following image for an example for SQL.
|
||||
|
||||
|
||||
|
||||
for remote SQL Server use
|
||||
servername.yourdomain.com
|
||||
|
||||
|
||||
|
||||
|
||||
@ -59,7 +59,7 @@ To enable white glove deployment, an additional Autopilot profile setting must b
|
||||
|
||||
|
||||
|
||||
The Windows Autopilot for white glove deployment pre-provisioning process will apply all device-targeted policies from Intune. That includes certificates, security templates, settings, apps, and more – anything targeting the device. Additionally, any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user that has been pre-assigned to the Autopilot device will also be installed.
|
||||
The Windows Autopilot for white glove deployment pre-provisioning process will apply all device-targeted policies from Intune. That includes certificates, security templates, settings, apps, and more – anything targeting the device. Additionally, any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user that has been pre-assigned to the Autopilot device will also be installed. Please make sure not to target both win32 and LOB apps to the same device.
|
||||
|
||||
>[!NOTE]
|
||||
>Other user-targeted policies will not apply until the user signs into the device. To verify these behaviors, be sure to create appropriate apps and policies targeted to devices and users.
|
||||
|
||||
Reference in New Issue
Block a user