Client-4.2-5.1.docx

**User State Migration Tool Overview** The User State Migration Tool (USMT) is an advanced tool used to migrate user profiles and data from one computer to another. Although it was designed for large environments, it can also be used for single-computer migrations. The two programs used to migrate...

**User State Migration Tool Overview** The User State Migration Tool (USMT) is an advanced tool used to migrate user profiles and data from one computer to another. Although it was designed for large environments, it can also be used for single-computer migrations. The two programs used to migrate data are ScanState and LoadState. ScanState collects the data to be migrated from the source computer. LoadState deploys the data to the destination computer. The User State Migration Tool (USMT): - Is part of the Windows Assessment and Deployment Kit (Windows ADK). - Is a command line tool that saves settings for transfers to new systems. - Saves user data to an external location that can be imported to the destination computer (for example, a USB device or a network share). USMT cannot be used to migrate a user profile directly from the source to the destination across a network connection. - Does not migrate mapped drives, local printers, drivers, passwords, or shared folder settings. - Can create three types of migration stores: - Uncompressed migration store: saves data using a hierarchy of folders that mirrors the original user profile structure. This option allows you to browse the migration store using File Explorer and make changes. - Compressed migration store: saves data into a single image file in a separate directory structure. The data can be password protected and encrypted. - Hard-link migration store: saves links to profile information on the local computer. The stored information is not changed when the old operating system is removed and the new one is installed. A hard-link migration is primarily used when performing an in-place migration on a system with an existing operating system. **User State Migration Tool Prompts** Once installed, USMT includes the following command line tools that can be run from an administrator Command Prompt window: **ScanState.exe** Scans and collects the user profiles, data, and settings as specified in the XML configuration files. The collected information is saved to a file (typically on a remote location) such as an external USB drive or network share. ------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **LoadState.exe** Migrates the information contained in the migration file created by ScanState to the destination computer. **USMTUtils.exe** Used to verify a compressed migration file. It can also be used to recover files from a compressed USMT migration file. **Using USMT** Use the following steps to use USMT to transfer settings to a network share: 1. Create a network share to hold the transfer files. 2. After downloading the Windows Assessment and Deployment Kit (Windows ADK), run the installer and install the User State Migration Tool (USMT) feature. 3. Copy the USMT files to the network share.\ These files can be found in C:\\Program Files (x86)\\Windows Kits\\10\\Assessment and Deployment Kit\\User State Migration Tool. You must run the 32-bit version of USMT (located in the x86 folder) on 32-bit clients and the 64-bit version of USMT (located in the amd64 folder) on 64-bit clients. 4. Decide what you want to migrate from the source computer to the destination computer. - Use the **/GenMigXML** option with ScanState to see which files will be included in the migration.\ When used with ScanState, a simulated capture is run and the results are exported to an.xml file. Viewing the exported file can help you determine whether any modifications to the other.xml files are necessary to capture what needs to be migrated.\ Example: **ScanState /GenMigXML:C:\\test.xml** - If necessary, customize the MigApp.xml, MigUser.xml, MigDocs.xml, and Config.xml files to configure what you want included in the migration. A best practice is to make changes to copied versions of these files. 5. On the source computer, complete the following tasks: - Close all running applications and files. - Open Command Prompt as the administrator, run **ScanState.exe** , and save the migration data to the network share.\ The following is an example of the command format if your network share was mapped to the F: drive:\ \ **ScanState f:\\Cathys\_Profile /i:migapp.xml /i:miguser.xml /ui:cathy /ue:\*\ \ **In this example: - **Cathys\_Profile** is the folder that will be created and contain the migrated information. - **/i:migapp.xml /i:miguser.xml** are the two.xml files that determine what will be collected. - **/ui** tells ScanState what user to migrate. In this case, the user is named Cathy. - **/ue** tells ScanState to ignore all other users. 6. On the target computer, complete the following tasks: - Install the desired operating system. - Install all applications that were installed on the source system. The application versions on the source and destination systems must match. - Shut down any running applications and close all files. - Open a Command Prompt window as the administrator and run **LoadState.exe** using the path to the network share.\ \ Example: **LoadState f:\\Cathys\_Profile /i:migapp.xml /i:miguser.xml /ui:cathy /ue:\* /lac:P\@ssw0rd /lae\ \ **In this example: - **/lac:P\@ssw0rd** indicates that a local account will be created and then assigned a password of P\@ssw0rd. - **/lae** indicates that the local account should be enabled. - Log in as a migrated user and verify that all profile data was migrated correctly. n the past, organizations would replace the version of Windows included on a new device with their own custom Windows image. This was often faster and easier than reconfiguring the pre-installed version on the device. This added expense due to the time and effort required to create and deploy the custom Windows images. Using the dynamic provisioning capabilities and tools provided with Windows, it is now possible to avoid this. With dynamic provisioning, the goal is to allow users to take a new PC out of the box, turn it on, and have it be configured with minimal time and effort by an IT administrator. This lesson covers the following topics: - Windows Subscription Activation - Azure Active Directory Join - Provisioning package configuration - Piloting a deployment **Windows Subscription Activation** Devices running Windows 10 version 1703 or later can take advantage of online subscription services that allow a device to step up to a higher version of Windows. Subscription Activation eliminates the need for IT administrators to manually deploy Enterprise or Education edition images on individual devices and does so without keys or rebooting. Examples: - Devices with a current Windows Pro license can be seamlessly upgraded to Windows Enterprise if they are subscribed to Windows Enterprise E3 or E5. - Product key-based Windows Enterprise software licenses can be transitioned to Windows Enterprise subscriptions. **Azure Active Directory Join** Azure Active Directory (AD) Join is intended for organizations that want to be cloud first or cloud only, meaning joined only to Azure AD. Azure AD Join is primarily intended for organizations that do not have an on-premises, Windows Server-based Active Directory infrastructure. The goal of Azure AD Join is to simplify: - Windows deployments of work-owned devices. - Access to organizational apps and resources from any Windows device. - Cloud-based management of work-owned devices. - User sign-in to devices with Azure AD or synced Active Directory work or school accounts. For example, with Azure AD Join, an organization user needs to provide only the work or school user ID and password. The device is then automatically joined to Azure AD and enrolled in a mobile device management (MDM) solution that requires no additional user interaction. From that point, the MDM solution finishes configuring the device settings when needed. **Provisioning Package Configuration** Provisioning packages are created by using the Windows Configuration Designer. They can send one or several configurations to apps and settings on a device. This method works best for small- to medium-sized businesses with deployments that range from 10 to a few hundred computers. Provisioning packages let you: - Quickly configure a new device without going through the process of installing a new image. - Save time by configuring multiple devices using one provisioning package. - Quickly configure employee-owned devices in an organization without a mobile device management (MDM) infrastructure. - Set up a device without requiring network connectivity. Provisioning packages can be: - Installed using removable media, such as an SD card or USB flash drive. - Attached to an email. - Downloaded from a network share. - Deployed in Near Field Communication (NFC) tags or barcodes. **Piloting a Deployment** Piloting a deployment consists of rolling out devices and software to a select group of users in the organization. Often, the devices and software have not been previously run in the production environment. During the pilot deployment, it\'s important to identify any issues and find solutions to them. IT administrators should document the feedback they receive from users and other stakeholders. When piloting a deployment, consider the following: - Test deployments with small groups. - Make sure that all production hardware, PCs, notebooks, and tablets meet the minimum specifications for the new Windows version. - Test all peripheral devices such as printers, scanners, and other devices. Make sure required drivers are available. - Check all third-party encryption tools and switch to BitLocker if needed. - Test all the apps that the organization uses. - Make sure that the IT staff has all the skills and training needed to support the organization and the Windows deployment. Windows Autopilot is a type of technology designed to make the deployment and management of new Windows devices easier. Autopilot allows IT professionals to configure the Out-of-Box-Experience (OOBE) for Windows and to provide the end user with a fully configured Windows device with minimal effort. This lesson covers the following topics: - Autopilot deployment process - Autopilot features - Autopilot requirements and licensing **Autopilot Deployment Process** With Autopilot, there is no image deployment, no injecting drivers, and very little infrastructure to manage. The Autopilot deployment process is as follows: - Devices are purchased from the vendor with Windows pre-installed. - The IT administrator pre-configures the autopilot deployment profiles and assigns them to the proper devices, based on the hardware IDs. Vendors can send the IT administrator a list of the hardware IDs for all the devices. - The device is sent to the end user. The end user connects the device to the internet. Based on the user\'s credentials and the device, the correct deployment profile and settings are downloaded on the device. **Autopilot Features** Once deployed, Windows devices can be managed by tools such as Microsoft Intune, Windows Update for Business, Microsoft Endpoint Configuration Manager, and others. Windows Autopilot can also be used to re-purpose a device by leveraging Windows Autopilot Reset to quickly prepare a device for a new user. In break or fix scenarios, Windows Autopilot can quickly bring a device back to a business-ready state. Windows Autopilot enables you to: - Join devices automatically to Azure Active Directory (Azure AD) or Active Directory (via Hybrid Azure AD Join). See Introduction to device management in Azure Active Directory for more information about the differences between these two join options. - Auto-enroll devices into MDM services, such as Microsoft Intune. This configuration requires an Azure AD Premium subscription. - Restrict the Administrator account creation. - Create and auto-assign devices to configuration groups based on a device\'s profile. - Customize OOBE content specific to the organization. **Autopilot Requirements and Licensing** The following table describes the requirements for Windows Autopilot: +-----------------------------------+-----------------------------------+ | **Requirement** | **Description** | +===================================+===================================+ | **Software and device | A supported version of Windows | | requirements** | Semi-Annual Channel is required. | | | Windows Enterprise Long-Term | | | Servicing Channel (LTSC) is also | | | supported. The following Windows | | | 10 or later editions are | | | supported: | | | | | | - Windows Pro | | | | | | - Windows Pro Education | | | | | | - Windows Pro for Workstations | | | | | | - Windows Enterprise | | | | | | - Windows Education | | | | | | - Windows Enterprise LTSC | +-----------------------------------+-----------------------------------+ | **Network requirements** | Windows Autopilot depends on a | | | variety of internet-based | | | services. Access to these | | | services must be provided for | | | Autopilot to function properly. | | | In the simplest case, enabling | | | proper functionality can be | | | achieved by ensuring the | | | following: | | | | | | - Using DNS name resolution for | | | internet DNS names | | | | | | - Allowing access to all hosts | | | via port 80 (HTTP), 443 | | | (HTTPS), and 123 (UDP/NTP) | +-----------------------------------+-----------------------------------+ Before you can use Windows Autopilot, configuration is required to support common Autopilot scenarios. - Configure Azure Active Directory automatic enrollment. - Configure Azure Active Directory custom branding (in order to display an organization-specific logon page during the Autopilot process). - Enable Windows Subscription Activation to automatically step up from Windows Pro to Windows Enterprise. Windows Autopilot depends on specific capabilities available in Windows and Azure AD. It also requires an MDM service such as Microsoft Intune. These capabilities can be obtained through various editions and subscription programs. To provide the needed Azure Active Directory and MDM functionality, one of the following is required: - Microsoft 365 Business subscription. - Microsoft 365 F1 subscription. - Microsoft 365 Academic A1, A3, or A5 subscription. - Microsoft 365 Enterprise E3 or E5 subscription, which include all Windows 10 or later editions, so Office 365 and EM+S features (Azure AD and Intune). - Enterprise Mobility + Security E3 or E5 subscription, which include all needed Azure AD and Intune features. - Intune for Education subscription, which includes all needed Azure AD and Intune features. - Azure Active Directory Premium P1 or P2 and Microsoft Intune subscriptions or an alternative MDM service. Additionally, the following are also recommended, but not required: - Office 365 ProPlus, which can be deployed easily via Intune or other MDM services. - Windows Subscription Activation to automatically step up devices from Windows Pro to Windows Enterprise. **Active Directory Overview** Active Directory is a centralized database that contains user accounts, group objects, workstation objects, security information, and much more. Active Directory provides the following benefits: - Centralized resources and security administration - the ability of an administrator to manage and secure the network resources and associated security objects from a single point (the Active Directory database). - Single login for access to global resources - a user created on a domain controller can access (from any computer on the network) any resource the user has been granted access to. - Simplified resource location - Active Directory simplifies access to files and print resources by allowing files and print resources to be published on the network. Once published, a user can search the Active Directory database for the desired resource and securely access it. A domain is an administratively defined collection of network resources that share a common directory database and common security policies. The domain is the basic administrative unit of an Active Directory structure. - Database information is replicated (shared or copied) within a domain. - Security settings are not shared between domains. - Each domain maintains its own set of relationships with other domains. - Domains are identified using Domain Name System (DNS) names. - The common name is the domain name itself (for example, CorpNet). - The distinguished name includes the common domain name along with the top-level DNS domain name (for example, CorpNet.xyz). Depending on the network structure and requirements, the entire network might be represented by a single domain with millions of objects. It is also possible that the network might require multiple domains. An organizational unit is like a folder that subdivides and organizes network resources within a domain. An organizational unit: - Is a container object. - Can contain other OUs or any type of leaf object (such as users, computers, and printers). - Can logically organize network resources. - Simplifies security administration. Like OUs, generic built-in containers are used to organize Active Directory objects. Built-in container objects differ from other containers in that they: - Are created by default. - Cannot be created, moved, renamed, or deleted. - Have very few editable properties. Within Active Directory, each resource is identified as an object. Common objects include: - Users - Groups - Computers You should know the following about objects: - Each object contains attributes that include information about the object, such as a user\'s name, phone number, and email address. This information is used for locating and securing resources. - Active Directory uses DNS for locating and naming objects. - Container objects hold other objects. These can be either other containers or leaf objects. A domain controller is a Windows server that holds a copy of the Active Directory database. - A domain controller is a member of only one domain. - A domain can contain multiple domain controllers. Each domain controller holds a copy of the Active Directory database. - Any domain controller can make changes to the Active Directory database. - Replication is the process of copying changes made to the Active Directory database between all domain controllers in the domain.