Extend Windows Server 2019 Trial to longer use

Microsoft allows to extend trial license up to six times for Windows Server 2019. That's 180 days x 6 = 3 years. So if you run into an expired license give this tip a try before loading up your Installation media.

How do you find out your Windows is expired? You probably first notice a message at the lower right corner on your desktop. It tells you your Windows license is expired. Hence your Windows becomes inactivated as you can see from Control Panel -> System. Perhaps you first are greeted with a message popping out saying "shutting down". Thinking that might be a mandatory restart due to Windows security patches and updates, you patiently wait for the server to come back online. You login in again, poking around and again the concerning "shutting down" message shows up in about half an hour. Don't panic. There's nothing wrong with your server. You simply need to extend its lifetime.

Open a Powershell windows or command line, type slmgr -dlv to confirm there are 6 rearm counts in total. And in the screenshot below I have 6 times remaining.

Type slmgr -rearm to extend license by 180 days. This will consume one rearm count. Restart the server.

After restarting your server you can check it out by typing slmgr -dli.

Check counts again with slmgr -dlv. Notice it's now 5 rearm counts.

You can also confirm this by looking at Control Panel -> System that will say Windows is activated. The desktop message also changes to "Windows license valid for 180 days".

Disclaimer: Everything this post describes is for non production use.

Series 7 - How to Clone Jupiter from Mars

No, That's not what you're thinking. No celestial bodies here.

It's my personal adoption of astronomical nomenclature when naming lab computers. When building clusters i hate to go through OS installation and update patches on each node. So making a vm template is very useful. In this post I'll elaborate on how to create a vm template called "Mars" and make clone vms out of it - Jupiter, Saturn, and so forth.

Step 1. Prepare Mars as a template

1. Prep source vm server:
On Windows 2016 server Mars, prepare all stuff that needs to be replicated on other clones -
(a) Activate Windows
(b) Install Windows updates to current
(c) Install cluster service
(d) Start Microsoft iSCSI Initiator Service
(e)  Ensure two NICs exist, one for public and one for private. If you use iSCSI for storage connection you'll need three NICs
(f) Configure IE
(g) Enable remote desktop access

2. Strip SID:
Because no two identical machines can coexist on the same network at the same time, cloned vm and its source template vm must be striped of computer name, domain membership, IP address, etc. There is a Windows built-in program called SysPrep.exe we can use to make sure the internal security identifier does not duplicate. Launch the utility from Mars' C:\Windows\System32\Sysprep. Choose shutdown option to make sure the machine is off when strip operation is completed.

3. In Hyper-V Manager right click Mars and choose "Export". The vm can be in off or running state.

4. Specify the location to store the template then hit Export button. We leave it on the Hyper-V host

5. Minutes later check the file system to verify the completed template.

Step 2. Cloning of Jupiter

1. In Hyper-V Manager click on Actions "Import Virtual Machine...":

2. Choose where Mars template is stored. Note: choose the virtual machine folder

3. Click Next to confirm the source file to import.

4. Next we will select new SID.

5. Next choose the clone destination for Jupiter. 

6. As well as for the vhd file location.

7. Review the summary  and click finish.

Step 3. Cleanup

1. Upon completion of cloning we end up with two identical vms. Which one is the source and which one is the clone? Let's check vm settings to distinguish them by comparing hard disk path.

2. Click on Browse button to go to Mars.vhdx under Jupiter folder and rename it to Jupiter. Click Apply then OK. While the cloned Mars is still in highlight in Hyper-V Manager, rename it to Jupiter.

3. Start Mars and Jupiter from Hyper-V Manager. Login in console as Administrator. Both vms will go through a brief startup processes. Click on Next and Accept license terms.

4. Upon login in to Windows, compare the following items:
- Windows will take a little while to get activated
- Computer names are no longer retained (descriptions are still "Mars")
- Domain name changed to Workgroup
- Both NICs are present but their names are changed: public -> Ethernet. Private -> Ethernet 2
- IPv4 address becomes DHCP enabled
- IPv6 protocol is checked again despite being unchecked before
- On cloned vm Jupiter, Windows updates are current.

5. If you want to make more clones from Mars, then no need to change anything on it. On Jupiter make the following changes to turn it into a functional vm node.
- IP address for public and private NICs
- Subnet mask or public and private NICs
- Default gateway for public NIC only
- DNS for public NIC only
- computer name
- Join domain

6. Repeat most of the above steps to clone more vms (Saturn, Neptune, Uranus, Nibiru, etc). Since Mars can be reused there's no need to prep for template again. You can start straight from Importing vm. Also newly cloned vm is in off state which makes it easier to distinguish from its source vm (running).

Series 5 - Cluster-Aware Updating (CAU)

CAU allows patching Windows cluster nodes with minimum downtime. Below is a self-updating process.


Step 1.   You can get to CAU in both ways:
In FCM right click on the Windows cluster name -> More Action -> Cluster Aware Updating
or In Server Manager -> Tools -> Cluster-Aware Updating

Step 2.   Select the Windows cluster name to connect -> Click Connect -> Configure cluster self-updating options. This step creates CAU role.

Step 3.   Read the details in the wizard.

Step 4.   Add the CAU role by checking the box as shown in the diagram.

Step 5.   Specify a schedule to update. For ease we create a daily schedule at midnight.

Step 6.   In Advanced Options take default values

Step 7.   Check recommendations on updates

Step 8.   Review confirmation summary page before the run

Step 9.   Now CAU role has been successfully created

Step 10.   Before we kick off auto updating, it's recommended to run a readiness test. In the CAU window click on the link in the right pane that says "Analyze cluster updating readiness". Our test went through with only one warning. Since we're not using proxy servers let's safely ignore it.

Step 11.   Also click on "Preview updates for this cluster" to see what updates are going to be applied. We can see all three nodes need a new virus definition file for Windows Defender. Node A requires a Cumulative Update as well.

Step 12.   At our scheduled time the auto updates kicks off.

Step 13.   One hour later there was a failover happening and node A was rebooted.

Step 14.   Finally all three nodes are updated successfully. 

Step 15.   You can click "Generate report on past Updating Runs" to display a report with updating details.

Server Manager crashing - fixed!

All of a sudden Server Manager stopped working on my Windows 2016 Servers. When I launched SM it displays the dashboard that appeared to search some information, then a box popped up. See below. There has been no windows updates within a week. And it was working fine yesterday.

Checking Windows Application Log showed this error message:

Faulting application name: ServerManager.exe, version: 10.0.14393.1737, time stamp: 0x59bafc80
Faulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6
Exception code: 0xe0434352
Fault offset: 0x0000000000033c58
Faulting process id: 0x334
Faulting application start time: 0x01d35fdfbfc29a54
Faulting application path: C:\Windows\system32\ServerManager.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 7f16cc8e-5221-4f10-9ed8-3f9de97760f8
Faulting package full name:
Faulting package-relative application ID:

I first attempted to fix the problem by renaming registry key

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\ServicingStorage\ServerComponentCache
to \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\ServicingStorage\ServerComponentCacheOLD

Upon a server reboot the key was recreated. And I was able to launch SM normally on one of the servers just for one time. The other two server still experienced the same error despite of registry changes. The working server again threw the SM error upon a second try.

I then checked the server role and features I installed lately. I found alongside the MPIO feature I wanted to install for clustering, I accidentally chose Multipath Connector at the same time. So using the registry trick I gained access to SM. Under Manage -> uninstall roles and features I quickly removed Multipath Connector for all servers. After rebooting, all are working fine now!