Upgrading roles and features

Table 22-2 lists which server roles and features can be directly upgraded and which server roles and features, if migrated, require the role or feature be taken offline for a period of time.

Upgrades are constrained by the following additional limitations:

• Upgrades from one language to another are not supported. For example, you can’t upgrade a French edition of Windows Server 2012 R2 to a German edition of Windows Server 2019.

• You cannot upgrade a Server Core installation to a Server with a Desktop installation. If the source operating system is running Windows Server 2012 R2, you can get around this by changing from Server Core to Server with a Desktop prior to performing the upgrade.

• You cannot upgrade a Server with a Desktop installation to a Server Core installation. If the source operating system is running Windows Server 2012 R2, you can get around this by converting to Server Core prior to performing the deployment.

• You cannot upgrade from a licensed version of a Windows Server operating system to an evaluation edition. Microsoft recommends that you only install evaluation editions as clean installations.

Converting evaluation version to licensed version

Although it is far from best practice, many organizations that deploy the 180-day evaluation version of Windows Server as part of a project prototype find, several months later, that the prototype has morphed into a critical component in the organization’s workflow. Rather than reinstall Windows Server and migrate the prototype deployment to a properly licensed, long-term production platform, it is instead possible to convert an evaluation version of Windows Server 2019 to a properly licensed version by performing the following steps:

1. From an elevated command prompt, run the command slmgr.vbs /dlv. This will display the current computer’s licensing information as shown in Figure 22-1.

   

2. Determine the current edition by running the command DISM /online /Get-CurrentEdition. This will display the edition ID, such as ServerStandard or ServerStandardCore. You will need this edition ID for the next step.

3. Once you’ve determined the edition, run the command DISM /online /Set-Edition:<editionID> /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula.

Upgrading editions

You can also use DISM to upgrade from one edition of Windows Server 2019 to another. For example, if you want to upgrade from the Standard edition of Windows Server 2019 to the Datacenter edition, specify the ServerDatacenter or ServerDatacenterCore product edition and enter the appropriate product key using the DISM /online /Set-Edition:<editionID> /ProductKey:<productkey> command.

You can use slmgr.vbs to switch between a retail license and a volume-license. To do this from an elevated prompt use the command slmgr.vbs /ipk <key> where <key> is the volume license key. If you are trying to convert an evaluation version of Windows Server 2019 to a volume licensed version, you must switch to a retail version, as described earlier.

Windows Server Migration Tools

The Windows Server Migration Tools (WSMT) is a Windows Server 2019 feature that you can use to migrate a specific set of server roles, features, shared folders, operating system settings, and data from a source computer running the Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 operating systems to a computer running Windows Server 2019.

You can use the WSMT to migrate the following roles and features:

• Active Directory Certificate Services

• Active Directory Federation Services

• Active Directory Rights Management Services

• File and storage services

• Hyper-V

• Network Policy Server

• Remote Desktop Services

• Windows Server Update Services

• Cluster Roles

• DHCP Server

• Web Server (IIS)

The WSMT supports:

• Migration from physically deployed operating systems to virtually deployed operating systems.

• Server Core and Server with a GUI installation option on Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, or Windows Server 2019 as the source operating system.

• Server Core and Server are supported with a GUI installation option for Windows Server 2019 as the destination operating system.

• You can’t use WSMT with Server Core on Windows Server 2008 because the .NET framework is not available on the Server Core installation option of Windows Server 2008.

• WSMT can only be used if the source and destination operating system are using the same UI language. The system UI language is the one used when setting up the operating system.

The WSMT has the following requirements:

• Must be deployed using an account that has local administrator privileges on the source and destination server.

• The source server must have at least 23 MB of free space to store the WSMT deployment folder.

• The source server must have the .NET Framework 3.51 installed.

• Windows PowerShell must be present on the source server. By default, PowerShell is included with Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. By default, PowerShell is not included on servers running the Windows Server 2008 operating system, though it’s likely that it has been installed at some point prior to the deployment of that operating system in your environment.

• You should always use the most recent version of the WSMT.

Installing the WSMT

You can install the WSMT on the destination server using the Install-WindowsFeature Migration PowerShell command or by installing the role using the Add Roles And Features Wizard, as shown in Figure 22-2. When you do this, the WSMT is deployed in the %WinDir%System32ServerMigrationTools folder on the destination server.

Once you’ve installed the WSMT, you need to configure a deployment folder from which you will deploy the appropriate version of the WSMT. Rather than deploying a generic version of the tools, deploy a version tailored for the source operating system. For example, to create a set of tools for a source computer running Windows Server 2012 R2, issue the command as shown in Figure 22-3:

Click here to view code image

Smigdeploy.exe /package /architecture amd64 /os WS12R2 /path <path to share>

You can either copy the contents of the deployment folder to the source computer or enact the tools remotely over a network connection by running smigdeploy.exe from an elevated command prompt. Installing the tools on a source server running the GUI option will give you a special migration tools PowerShell session, as shown in Figure 22-4.

If you are running the tools on a computer that is configured with the Server Core installation option, open an elevated PowerShell session, and run the following command to add the WSMT cmdlets:

Click here to view code image

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

FRS to DFSR migration

Depending on the age of your organization’s Active Directory deployment—especially if a domain once functioned at the Windows Server 2003 functional level—and how diligently Active Directory upgrades were performed, it’s possible that SYSVOL replication is configured to use the older inefficient File Replication Service, rather than the more efficient Distributed File System.

You can check whether SYSVOL replication is configured to use FRS or DFS using the dfsrmig.exe utility with the /globalstate parameter. If the output state of the command shows Eliminated, as in Figure 22-7, then SYSVOL already uses DFS for replication.

If the output of dfsrmig.exe instead shows that migration has yet to be initialized, you should update the SYSVOL replication. You should only use FSR for SYSVOL replication if your organization still has domain controllers running the Windows Server 2003 or Windows Server 2003 R2 operating systems. At this stage, it really shouldn’t be running those OS versions, should it?

To upgrade SYSVOL replication to DFS from FRS, perform the following steps:

1. Sign in to a domain controller with credentials that are a member of the Domain Admin or Enterprise Admin groups.

2. Start PowerShell and then run the command dfsrmig /setglobalstate 1. Depending on the number of domain controllers in the domain, it can take more than an hour to reach the prepared state. You can verify that the prepared state has been reached by running the command dfsrmig /getmigrationstate. When preparation is completed, the utility will report that the global state is Prepared.

3. Next, set the DFSR state to Redirected. You do this using the command dfsrmig /setglobalstate 2. You use dfsrmig /getmigraitonstate to verify that the DFSR state is set to Redirected.

4. Once the DFSR state is set to Redirected, run the command dfsrmig /setglobalstate 3. This will finalize the transition of SYSVOL to the Eliminated state, and DFS will be used for replication instead of FRS.

Migrating to a new forest

Many organizations have had their current Active Directory environment for more than a decade. The older an Active Directory environment is, the more likely it is to have an inefficient domain and OU structure, derelict user and computer accounts, unutilized sites, and forgotten group policy objects and groups. Just as Microsoft recommends performing fresh installations rather than in-place upgrades for individual computers, it may make more sense to migrate to a new forest than it does to remain with an existing Active Directory forest. This is especially true if an organization is considering moving toward a secure administrative model where the privileged accounts in a production forest are unprivileged standard accounts in the secure administrative forest.

The Active Directory Migration Tool (ADMT) is a special tool that you can use to migrate Active Directory objects to and from any Active Directory environments, from moving accounts within a forest, to migrating accounts to a new Active Directory forest.

You can use ADMT to perform an interforest restructure or an intraforest restructure. An intraforest restructure allows you to modify your current domain and forest structure to reduce complexity. An interforest restructure involves creating a brand new, simplified forest structure using Active Directory objects from your existing forest.

Table 22-3 lists the differences between each restructure type.

The Active Directory Migration Tool requires that you have access to a SQL Server instance. This can be a full SQL Server deployment, or a local SQL Server express instance. The ADMT includes the following wizards, shown in Figure 22-8.

• User Account Migration Wizard. Allows you to perform an intraforest or interforest migration of user account objects.

• Group Account Migration Wizard. Allows you to perform an intraforest or interforest migration of group account objects, including group membership information.

• Computer Migration Wizard. Allows you to perform an intraforest or interforest migration of computer account objects.

• Security Translation Wizard. Wizard that allows you to transfer security permissions during object migration.

• Reporting Wizard. Generates the following reports:

  • Migrated Users, Groups And Managed Service Accounts report. Summarizes result of the migration of user, group, and managed service accounts.

  • Expired Computers Report. List of computers found that have expired computer account passwords.

  • Account References Report. List of accounts that have been assigned permissions for resources on a specific computer.

  • Name Conflicts Report. A list of user accounts and groups that are present in both the source and target domains.

• Service Account Migration Wizard. Allows you to perform intraforest or interforest service account migration.

• Managed Service Account Migration Wizard. Allows you to perform intraforest or interforest managed service account migration.

• Password Migration Wizard. Allows you to perform intraforest or interforest password migration.

Preparation

To prepare the source server, perform the following steps:

1. Export the CA templates list. This is the list of templates that the CA is configured to issue. The master list of templates is stored within Active Directory. You can export this list from the Certificate Services console by right-clicking the Certificate Templates node and selecting Export. You can also do this using the command certutil.exe -catemplates > catemplates.txt command.

2. Make a note of the CA’s Cryptographic Service Provider (CSP) and which signature algorithm is used. This is visible on the CA’s Properties dialog box, as shown in Figure 22-9. You can also do this using the command certutil.exe -getreg cacsp* > csp.txt.

   

3. Back up the source server CA, including the private key, CA certificate, Certificate Database, and Certificate Database Log. You can do this using the Certification Authority Backup Wizard, as shown in Figure 22-10. Copy the contents of the backup folder to a location that will be accessible to the destination server.

   

4. Stop the Certificate Services service. You can do this using the Services console, as shown in Figure 22-11, or by using the Stop-Service certsvc Windows PowerShell command. This will block the current certificate server from issuing additional certificates.

   

5. Back up the registry settings of the CA using the following command, and place it in a location that is accessible to the destination server:

   Click here to view code image

   reg export HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration
   <output file>.reg

6. If the source CA uses a custom CAPolicy.inf file, you should copy this file to a location that is accessible to the destination server.

Migration

Once you have performed the necessary preparation steps, you should perform the following steps to complete the migration of the CA:

1. Once you have backed up the source CA and its registry settings, remove the CA role service from the source server. This is important because removing the role service from the server will also clean up data stored in Active Directory associated with the CA. If you don’t perform this clean up, you will encounter problems when introducing the migrated CA that shares the original CA’s name.

2. Removing the role service from the CA does not delete the CA database, private key, or CA certificate. This means that if the migration fails, you will be able to restore the CA by reinstalling the certificate services role on the server.

3. Microsoft also recommends manually removing the source server from the domain prior to deploying the destination server. This is especially important if the source and destination server share the same computer name.

4. Change the name of the destination server to match the name of the source server.

5. Join the destination server to the domain.

6. Import the CA certificates into the local computer’s Personal certificate store.

7. Once the computer is domain joined, add the CA role service to the destination server. Ensure that you install the server in the same manner, such as installing an Enterprise Root or Standalone Subordinate CA, depending on the properties of the original source CA. During the installation routine on the Set Up Private Key page, utilize the Use Existing Private Key option, and select the existing private key. Complete the setup wizard.

8. Use the Certification Authority snap-in to restore both the certificate database and the certificate database log from the backup taken on the source server. You will need to restart the certificate services server.

9. Import the registry settings exported from the source CA. If the source CA and the destination CA share the same name and the same file paths, then this can be done without modification. If the source CA has a different name from the destination CA or uses different file paths, you’ll need to manually alter these registry settings. Prior to importing the registry, stop the certificate services service. Use the command reg import backup.reg to import the registry file. Restart the certificate service.

10. Import the list of CA templates that are issued from the CA using the command certutil -setcatemplates, and then provide a list of templates that you backed up from the source server in comma-separated format.

Verification and post migration tasks

To verify that the CA has migrated successfully, verify that you can successfully request and enroll a new certificate. You should also verify that you can successfully publish a CRL. Performing these tasks is covered in Chapter 12, “Active Directory Certificate Services.”

Preparing to migrate DHCP

Before you start the process of migrating a DHCP server and its associated scopes and settings to Windows Server 2019, you’ll need to perform several preparation steps.

1. Determine which current DHCP servers you wish to migrate and which servers running Windows Server 2019 will host the migrated DHCP server roles, associated scopes, and settings.

2. Ensure that all critical updates, update rollups, and service packs have been installed on the source and destination servers.

3. Deploy the Windows Server Migration Tools (WSMT) on the source and destination servers.

4. Install the DHCP role service on the destination server. This service must be present on the destination server prior to beginning the migration.

5. Ensure that the source and destination servers have the same number of network adapters. Determine which subnet each network adapter is bound to on the source server and ensure that the destination server has network adapters bound to the same subnets. This will ensure that the migrated DHCP server can service the same subnets as the source DHCP server.

6. Determine the IP address strategy for the destination server. DHCP servers should use static IP addresses on network interfaces that are used by the DHCP server service to manage DHCP traffic. Options include:

   • Assigning the destination server different static IP addresses that are on the same subnets as the static IP addresses assigned to network interfaces on the source server. Doing this will allow you to perform the migration with both the source and destination server online.

   • Assign the destination server the same IP addresses that are used for network interfaces for the source server. While this is possible, it will mean that the source and destination server cannot be online at the same time without causing IP address conflicts, or it would require extensive preparation of network virtualization. Because existing clients will be able to renew their IP address information after migration from a destination server with a new IP address on the same subnet, you should only keep the same IP addresses on the source and destination server if there are substantive reasons for doing so.

7. If the source server does not use the default path for the DHCP server database, such as having the database stored on a separate volume, the destination server will need to have a volume configuration that matches that of the source server. For example, if the DHCP database is stored on volume H: of the source server, the destination server will need a properly formatted volume H: for migration to be successful.

8. Ensure that the migration store location is accessible to both the source and destination servers.

9. Ensure that both the source and destination servers have network access to the AD DS environment.

10. Perform a backup of the DHCP server from the DHCP console, rather than the Windows Server Backup, as shown in Figure 22-14. You can do this by right-clicking the DHCP server node, selecting Backup, and specifying a location for the backup.

    

11. Once the backup is complete, stop the DHCP service on the source and the destination server, either by using the Services console as shown in Figure 22-15, or by running the Stop-Service DHCPserver Windows PowerShell cmdlet.

    

Migration

Once the source and destination servers are prepared, the next step is to open the Windows Server Migration Tools PowerShell session. You perform the migration using the Export-SmigServerSetting PowerShell cmdlet. Specific parameters of the Export-SmigServerSetting cmdlet that are relevant to DHCP server migration include:

• Use the FeatureID DHCP to specify that the DHCP server role is what you want to migrate.

• Use the Users parameter if the DHCP administrators group includes local user accounts. Use the Group parameter to migrate all members of the DHCP administrators group that don’t include local user, but does include domain users and groups.

• You can use the IPConfig parameter if you want to export the IP address configuration of the source server to the destination server.

• Use the Path parameter to specify the location of the svrmig.mig file. If you don’t specify a network location, you’ll need to manually transfer this file to a location that is accessible to the destination server.

Considerations for using the Import-SmigServerSetting cmdlet on the destination server include:

• Use the FeatureID DHCP to specify that the DHCP server role is what you are importing. While the Import-SmigServerSetting cmdlet will install the DHCP server role if it is not already present on the destination server, Microsoft recommends installing the service and then placing it in a stopped state before importing data using the WSMT.

• Use the Users parameter if the DHCP Administrators group on the destination server will include local users. Use the Group parameter if the DHCP administrators group contains domain users and groups.

• Use the Path parameter to specify the location of the svrmig.mig file. This file can be stored on an accessible network share or stored locally.

• Once migration is complete, start the DHCP server service using the Start-Service DHCPServer cmdlet.

• If you haven’t done so already, you’ll need to authorize the DHCP server in Active Directory before it will function.

Verification and post migration tasks

Once the migration has occurred, ensure that the DHCP server service on the source server remains in a stopped state, as well as on a client release, and then renew an IP address to verify that the DHCP server service on the destination server is functioning properly. You should also manually check that the scopes and settings that were present on the source server are also present on the destination server. Once you have verified that the migration has completed successfully, remove the DHCP server service from the source computer.

Migrate file servers using Storage Migration Service

Storage Migration Service is a new service included in Windows Server 2019 that leverages Windows Admin Center to allow you to inventory the settings and data of a source file server, transfer the files and settings to a destination server, and then configure the destination server with the settings and identity that were present on the source server. The advantage of Storage Migration Service over WSMT is that it can:

• Inventory multiple servers and the data they store

• Quickly transfer files, file shares, and security settings from source servers

• Apply the identity of the source server to the destination server, including name and IP address settings so that users and applications do not have to alter their existing behavior and configuration

While copying files and their permissions has always been something that most administrators could generally figure out how to do fairly quickly, it was often a bit more challenging to copy the settings of the shared folders that hosted those files. Storage Migration Service allows you to migrate all the flags, settings, and security settings of SMB file shares. The flags that Storage Migration Service migrates include:

• Share State

• Availability Type

• Share Type

• Folder Enumeration Mode (also known as Access-Based Enumeration or ABE)

• Caching Mode

• Leasing Mode

• SMB Instance

• CA Timeout

• Concurrent User Limit

• Continuously Available

• Description

• Encrypt Data

• Identity Remoting

• Infrastructure

• Name

• Path

• Scoped

• Scope Name

• Security Descriptor

• Shadow Copy

• Special

• Temporary

There are some limitations to what you can transfer using Storage Migration Service. These include not allowing you to migrate the following folders and files:

• Windows, Program Files, Program Files (x86), Program Data, Users, $Recycle.bin, Recycler, Recycled, System Volume Information, $UpgDrv$, $SysReset, $Windows.~BT, $Windows.~LS, Windows.old, boot, Recovery, Documents and Settings, pagefile.sys, hiberfil.sys, swapfile.sys, winpepge.sys, config.sys, bootsect.bak, bootmgr, and bootnxt

• Any file or folder on the source server that conflicts with folders assigned the exclusion designation folders on the destination server

You can’t use Storage Migration Service to migrate file servers that are members of separate domains. You also can’t use Storage Migration Service to migrate file servers between workgroups.

Deploy Storage Migration Service

Storage Migration Service Orchestrator servers manage the migration process. It’s important to note, especially if you are building your own test lab, that you can’t deploy the Storage Migration Service Orchestrator from a host installed using the Evaluation version of Windows Server 2019. To install the Orchestrator service on a computer, Open Windows Admin center and click on Storage Migration Service as shown in Figure 22-16.

Storage Migration Service requires that the following rules are enabled within Windows Firewall:

• File and Printer Sharing (SMB-In)

• Netlogon Service (NP-In)

• Windows Management Instrumentation (DCOM-In)

• Windows Management Instrumentation (WMI-In)

If you are using a third-party firewall product, ensure that you open TCP ports 135, 445, and 1025–65535. The service ports are TCP 28940 for the Orchestrator and TCP 28941 for the Proxy.

To perform a migration, you need access to the credentials of accounts with the following permissions:

• Administrator permission on the source and destination computer

• Administrator permissions on the computer that hosts the Storage Migration Service Orchestrator role

Inside OUT

Local users, local groups, Samba, and failover clusters

The version of Storage Migration Services that ships with Windows Server 2019 can only be used to migrate file shares from source servers that run Windows Server 2003 and later operating systems. If you are running Windows Server Semi Annual Channel 1903 or later, or if you have applied the cumulative update that was released in August 2019, you can also use Storage Migration Services to migrate file shares from source servers that use Samba versions 3.6.x and 4.x on RedHat 7.6, CentOS 7, Debian 8, Ubuntu 16.04, and SUSE Linux Enterprise Server (SLES) 11 SP4. Similarly, if you are running Windows Server Semi Annual Channel 1903 or later or have installed the cumulative update available in August 2019, the migration process will also allow you to migrate local users and groups from a source server to a destination server.

Migrate file and storage servers using WSMT

While you should use Storage Migration Service to migrate file servers to Windows Server 2019, should you really want to, you can use the WSMT to migrate the following file and storage services information from a computer running Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 to Windows Server 2019:

• Server identity information

• Local users and groups

• Data and shared folders

• Shadow copies of Shared Folders

• Data Deduplication

• DFS Namespaces

• DFS Replication

• File Server Resource Manager (FSRM)

• Group Policy settings related to SMB

• Group Policy settings for Offline Files

• iSCSI Software Target settings

• Network File System (NFS) shares

• Remote Volume Shadow Copy Service

The following migration scenarios are supported for file and storage services:

• The file server is a member of a domain.

• The file server is a member of a workgroup.

• File server data and shares are located on an external storage location, such as a SAN or on direct attached storage, as long as either storage medium preserves data permissions and file-share permissions.

It is important to note that file migration using the WSMT is aimed at moving data sets smaller than 100 GB, because only one file at a time is copied over a HTTPS connection. When moving larger data sets, Microsoft recommends using the robocopy.exe utility included with Windows Server 2019.

Send-SmigServerData -ComputerName MEL-FS-2K16 -SourcePath e:fileshare -DestinationPath
f:fileshare -Recurse -Include All -Force