I’ve been aware of Windows Terminal for a while, I’ve just never felt the need to set it up. Most of my work for the website involves me taking screenshots on Windows Server OS. So, when I decided to take a look at it I had to jump through a few hoops to get it to work, in the words of Juan Sánchez Villalobos Ramírez, Chief metallurgist to King Charles V of Spain, “I would save you that pain”. (If you get that reference, we can be friends).
Solution: Windows Terminal on Server 2022
So, Windows Server OSs cannot access the Windows Store, so you need to manually download the app packages (msibundle) then install them with PowerShell. If you want to install on Server 2022 then don’t download the Windows 11 package, if you do and try and install it you will see something like.
Deployment failed with HRESULT: 0x80073CFD, A Prerequisite for an install could not be satisfied. Windows cannot install package Microsoft.WindowsTerminal_1.16.10262.0_x64__8wekyb3d8bbwe because this package is not compatible with the device. The package requires OS version 10.0.22000.0 or higher on the Windows.Desktop device family. The device is currently running OS version 10.0.20348.1668
I walked back though a few versions before I realised you need to download the Windows 10 versions. go here and check for the latest version.
Previous Windows Server Versions: In some cases you may need to download and install the Preinstall kit (See above page for download link) Simply download it as a Zip file, extract it, and then use Add-AppxPackage to install the msibundle for that first. But for Server 2022 you don’t need to do that.
Firstly, you need to download another package as it’s a pre-requisite, the following commands will download and install it.
“Hi thanks for your video. I have two win 2012 DC DHCP on a failover/load balance config and want to migrate to new Win 2022 VMs. What’s the exact procedure? If it’s a single VM it’s easy but I’m not sure about if it’s on a failover setup.”
Well migrating the domain controller element I’ve covered before.
But what if you have your DHCP servers deployed in HA – be that Load Balanced, or Hot Standby (failover)?
How do you migrate DHCP to a new platform then ?
Solution: Migrate DHCP HA
There was very little information I could find on this subject, you can drop down to one DHCP server and perform a simple migration to Server 2022 then setup HA again of course, but I think the following solution is much more elegant, and there’s NO DOWNTIME to worry about.
Windows Migrate DHCP HA – Step 1 Remove HA
In my example I have some 2012 R2 Servers running DHCP (it does not matter if they are in Load balancing mode or Hot Standby, the approach is the same just the commands will vary.
I’ve got two new Windows Server 2022 servers updated and added to the domain ready to take on the DHCP HA roles.
The first thing I’m going to do is remove the failover partnership. You can do this on either of the legacy DHCP servers but the one you run the command on will be the DHCP server that remains operational after you remove the partnership (in this case 2012-dhcp-1.dingdong.com).
Use the following syntax, the first command gets the failover groups name, you then delete that failover group.
Windows Migrate DHCP Failover – Step 3 Create HA to Server 2022
We will now create a failover partnership to the first of our two new Windows Servers.
Firstly we need to install the DHCP role on BOTH of our new Windows Servers, register them in AD, and change a registry key to stop server manager bugging you about running the DHCP setup wizard.
Windows Migrate DHCP Failover – Step 4 Break Replication
If you are replicating many scopes then wait a while for the servers to be ‘in sync’, the next step seems counter intuitive, as you are going to delete the very thing you have just created, but this procedure is carried out on the NEW DHCP SERVER NOT THE LEGACY ONE, (so the DHCP scope is removed from the last remaining legacy DHCP server.)
On the first new DHCP server execute the following commands. (same commands you used above in step 1).
Windows Migrate DHCP Failover – Step 6 Deploy new DHCP HA Configuration
Lastly, we setup a new failover relationship that is setup the same as the one we setup in step 3, but this time with the last remaining new DHCP server.
To join Windows Server 2022 to a Domain (Local Domain). The end proces is the same as it’s always been, they’ve just made the job of getting to there a little more convoluted, (this is the same with Windows 11).
Solution: Server 2022 Domain Join
Whilst logged in as a (local) administrative user, click the Windows button > Settings.
System.
About.
Advanced system settings.
Computer name > Change.
Select the domain radio button > Type in the domain name (must be resolvable in DNS, if in doubt try ‘pinging‘ the domain name” > OK > Enter a domain credential that has right to add machines to a domain. (Here I’m using the domain admin account, but normally a domain user can add a number (10 by default) of machines to a domain) > OK.
BUG / BAD UI ALERT: Minimise the window (because the popup box you are waiting for will appear behind it (please fix this Microsoft!)) > OK.
Enter a domain credential that has right to add machines to a domain. (Here I’m using the domain admin, but normally a user can add a number (10 by default) of machines to a domain) > OK.
After a few seconds, it should tell you to reboot, you can do so by entering;
[box]
Restart-Computer
[/box]
PowerShell: Remove Windows Server 2022 from a Domain
With Exchange 2013 going end of support (11 Apr 2023) you should be migrating away from it as soon as you can, (as it’s only supported on up to Server 2012 R2), so you should have migrated off it already! It’s been some time since Exchange had any ‘major’ redesigns, 2013 was version 15, 2016 was version 15.1, and 2019 is Version 15.2.
So the Exchange 2013 > 2019 Migration is pretty much the same as it was from 2013 > 2016, or even 2016 > 2019.
There should be NO Exchange 2010 servers in existence before deploying Exchange 2019. You would need to upgrade to 2013 (CU21 minimum)/2016 (CU 11 minimum) first.
There’s no Unified Comms Role with Exchange any more! If you need to upgrade look at Microsoft Teams.
Forest Functional Levels should be, (at least) Server 2012 R2.
WARNING: Memory recommendations are 128GB (Mailbox server) and 64GB (Edge Transport server). Make sure you have enough compute!
Edge Server Role is still supported.
Windows Server Core (2019/2022) is supported with Exchange 2019.
Windows Server Nano is NOT supported.
Windows Server 2019 (Standard or Datacenter) and Windows Server 2022 (Standard or Datacenter) Note: Exchange 2019 CU 12 minimum, are supported host Operating systems.
Outlook 2013 (and newer), and Outlook for mac 2016 (and newer) is supported.
Exchange 2013 to 2019 Upgrade: Solution
As with all Exchange migrations make sure your Active Directory Domain/DNS/Existing Exchange organisation is healthy before you start. Then upgrade the existing Exchange to the latest cumulative update.
Exchange 2013 to 2019 Upgrade Prerequisites
You will need your Server 2019 or Server 2022 server fully updated and added to your domain, then to add the required roles and services use the following Powershell commands;
Exchange 2013 to 2019 Upgrade: Adding Exchange Server Roles
Note: Now Required on Server 2019: You will need to install .Net 4.8 (link)
For Server 2022: You DON’T need to do this, (it’s already installed).
You need to install the Microsoft Unified Communications API 4.0 (link)
You will also need to install Microsoft Visual C++ (link)
You will also now have to install the ‘IIS Rewrite Module’ (link)
Either download the Exchange 2019 install media, or insert the Exchange 2019 DVD, and launch setup.exe > Next > Next > Files will be copied over.
Don’t I need to extend the schema, forest or domain? The setup does all this for you, you don’t need to do this manually anymore, (yes you can manually do this before installing, if you want to, but unless your schema master is in a different root domain, or you’re not a schema admin, then I don’t see the point!)
Introduction Page > Next > At the EULA tick “I Accept…” > Next > Tick “Use Recommended settings” > Next.
Select ‘Mailbox role’, and ‘Automatically install Windows Server roles and features…” > Next > Select the install directory, Note: In production you probably DON’T want this on the Windows System drive > Next > Unless you have a reason to disable Malware scanning then select ‘No’ > Next.
Readiness Checks > Fix any Errors and heed any warnings > Install > The product will install, this will take a long time!
Finish > Reboot the server.
And there’s our new Exchange 2019 Server.
Exchange 2019 EnterProduct Key
Servers > Servers > Select the 2019 Exchange Server > Enter Product Key > Save
At the warning click OK.
Note: You can also enter the product key using the PoweShell ‘Command Shell’, if you prefer.
As directed Restart the ‘Microsoft Exchange Information Store‘ service.
[box]
Restart-Service MSExchangeIS
[/box]
Transfer Exchange Certificate to Exchange 2019
Note: The ability to Export, Import & Renew certificates and creation/completion of certificate requests has been removed from the Exchange Admin Center. These changes will affect all cumulative update (CU) releases of Microsoft Exchange Server 2019 (CU12 and later) and Microsoft Exchange Server 2016 (CU23 and later).
I will leave the older (GUI) method, below for completeness – but all modern Exchange builds will need you to Open the Exchange Management Shell and perform the certificate migration via PowerShell
Transfer Certificates (PowerShell)
On your C: drive create a new folder called CERT > Open an Administrative Exchange Managment Shell window on the SOURCE Exchange server.
[box]
Get-ExchangeCertificate -Server {Server-Name}
[/box]
Identify the certificate you require (by Subject) > Copy the Thumbprint text > Replace the thumbprint in this text with your thumbprint, then execute the following two commands.
Transfer Certificates (ExchangeAdmin Centre {Older build versions only})
I’m using a wildcard certificate so I want to export the cert form my Exchange 2013 server and import it onto my new Exchange 2019 Server. You will want to do the same if you have a certificate with your public domain name on it and this will be your ‘internet facing’ Exchange server. Servers > Certificates > Select the Exchange 2013 Server, in the drop down menu > Select The Certificate > Click the ellipsis (three dots) > Export Exchange Certificate > Supply a UNC path and password > OK.
Change the Dropdown to the Exchange 2019 Server > Click the ellipsis > Import Exchange Certificate > Supply the UNC path and password you used (above) > Next.
Add in the Exchange 2019 Server > Finish.
Exchange 2013 to 2019 Upgrade Exchange 2019 Assign Services to Certificate
Select the newly imported certificate> Edit > Services > Select the services > Save > Note: Here I’m selecting SMTP and IIS. (You can’t use a wildcard cert for IMAP,POP).
Exchange 2019 Changing the Exchange Web Services URLs
Exchange relies heavily on web based services, and it needs the URLs setting accordingly (remember for Outlook Anywhere/OWA etc you might need to change firewall settings or repoint load balancers WAP server etc to the NEW 2019 server (and let it proxy these connections to the older Exchange servers, while they still exist).
Servers > Databases > Exchange always gives databases annoying names > Select the Database on the 2019 Exchange Server > Edit > Rename it > Save.
Note: The path to the Database retains the original name (we will fix that in the next step).
Exchange 2013 to 2019 Upgrade: Move Mailbox Database
I’m pretty old school, I like my Exchange databases on their own drive/partition, and I like the logs on another drive/partition. To move both the Database and the Logs;
Mail Flow > Send Connectors > Select your mail SMTP connector(s) > Edit > Scoping > Source Server section > Add > Add in the new server > OK > Save.
Note: The Exchange server will now need to have TCP port 25 (SMTP) open outbound on your corporate firewall.
Hybrid (On-Prem) Exchange Migration Note
If your on-premise Exchange is part of an Office 365 Hybrid deployment you will need to add the new server to the ‘scope’ for that connector also!
Exchange 2013 to 2019 Upgrade: Decommission Exchange 2013
From this point forward we are going to start getting rid of our Exchange 2013 server, they can of course coexist, (if you wanted to wait a while).
For that reason I change the ‘mail flow’ on the firewall to point to the new Exchange server at this point, and the HTTP access for OWA, Outlook Anywhere, and Phone/Tablet access.
Exchange 2013 to 2019 Upgrade Exchange 2013 Mailbox Migration
Yes you can do this in the Exchange Admin Center (GUI), but I prefer to do this in PowerShell. But if I don’t put this here, I’ll get emails! Recipients > Migration > Add > Move to a different Database > Add in the mailboxes/users > Next.
Give the ‘Batch’ a name > Select to move Archive mailboxes (if you have them) > Select the destination (Exchange 2019) Database > Again if using archive mailboxes, select the target archive mailbox database > Set the bad Item limit to 99 > Next > Select Automatically Start > Select Automatically Finish > New.
From this point, this is where I don’t like the EAC it takes AGES to update with progress! From the Exchange Shell you can get an up to date view of that is going on!
[box]
Get-MoveRequest | Get-MoveRequestStatistics
[/box]
For a better list of commands for moving user mailboxes, monitoring the migration, (and removing the move requests when you are finished). See the following article;
With ALL Mailboxes migraitons, DON’T FORGET that on sucessfull completion, you need to remove the move requests. (If somehting fails, or displays an error, don’t forget to search for that error (above) before going to Google!
Exchange 2013 to 2019 Upgrade: Migrating Exchange System Mailboxes
Before you start issue the following command;
[box]
Set-AdServerSettings -ViewEntireForest $true
[/box]
In addition to the user mailboxes there are a multitude of different ‘System mailboxes’ that might be hanging around, before we can get rid of the Exchange 2013 Database(s) we need to migrate those.
Error seen when attempting to add a new domain controller to an existing domain;
Verification of replica failed. The specified domain {Domain-Name} is still using the File Replication Service (FRS) to replicate the SYSVOL share. FRS is depreciated.
The server being promoted does not support FRS and cannot be promoted as a replica into the specified domain.
You MUST migrate the specified domain to use DFS Replication using the DFSRMIG command before continuing.
Solution: FRS is Depreciated
Before proceeding you MUST ensure all your existing domain controllers are AT LEAST Windows Server 2008. Your domain and forest functional levels should be at Windows Server 2008 (AL LEAST). It would also be a good move, to make sure all your DCs are replicating cleanly.
You need to go to one of your legacy (existing) domain controllers, and carry out the following PowerShell procedure.
First make sure that no one’s messed about with this before, issue the following command and make sure the migration process has not been previously started;
[box]
dfsrmig /getglobalstate
[/box]
Start the process.
[box]
dfsrmig /setglobalstate 1
[/box]
It can take a while, (even if you only have one Domain Controller!) Keep checking the status, with the command ‘dfsrmig /getmigrationstate’ until it says all the domain controllers have migrated to global state ‘Prepared‘.
Change the process to state 2 (Redirected).
[box]
dfsrmig /setglobalstate 2
[/box]
This typically completes a bit faster than the first state. Keep checking the status, with the command you originally used, until it says all the domain controllers have migrated to global state ‘Redirected‘.
Change the process to state 3 (Eliminated).
[box]
dfsrmig /setglobalstate 3
[/box]
As before, keep checking the status, with the command you originally used, until it says all the domain controllers have migrated to global state ‘Suceeded‘.
On the ‘Old‘ domain controllers, you need to disable the NTFRS service and stop it.
If you have a lot of DHCP scopes, options, or reservations, then manually creating them on your new DHCP servers can be a both a time consuming and tedious process. If only there was an easier way?
Migrate DHCP with Netsh
Below you can see an example, where I have many scopes and lot’s of settings that would be painful to have to recreate from scratch. This example is on Server 2008 R2,but your source server could be server 2000, (or newer) the export procedure is the same.
Now on the source DHCP server I’m stopping and disabling the DHCP SERVER service, you might want to wait until, you are about to authorise the new 2022 DHCP server to minimise downtime, before doing this in production.
Copy the exported text file from the old DHCP server, to the new server.
Migrate DHCP: Install DHCP on Windows Server (via PowerShell)
Then import the settings with the following command.
[box]
netsh dhcp server import C:\dhcp-export.txt all
[/box]
Go to Administrative Tools > DHCP > You should see your migrated information in here, the DHCP scopes will be down (because the server has not yet been authorised in AD). Right click the server name, and select Authorise.
Note: At this point ENSURE the old DHCP server has had its DHCP server service stopped and disabled.
Wait a few seconds and then restart the DHCP Server service, (this can be done as shown below).
After a few seconds, the new scopes should be up and getting served.
Related Articles, References, Credits, or External Links
