Windows Server 2019 – KMS Activation with Windows Server 2016

UPDATED – I had noticed that the Windows Server 2019 servers were still showing as unlicensed. Re-running slmgr /ipk <Activation key> from the command prompt resolved the issue. 

 

At a client site the other day we introduced two new Windows Server 2019 servers. There was already a KMS host in place however this server did not have the appropriate keys in place to license Windows Server 2019.

After retrieving the Windows Server 2019 KMS keys from Windows Volume Licensing I went to install the keys in VAMT.  The first error I receive displayed that this is an incorrect license key, searching the web I came across this Microsoft article.

https://blogs.technet.microsoft.com/askpfeplat/2018/10/08/kms-activation-in-windows-server-2019/

In our case Windows Server 2016 is supported but you need to be patched to the latest level. The patch to support Windows Server 2019 on a Windows Server 2016 KMS host came out in November.  I applied the latest patches and made sure everything was up to date but this article forgot to mention one thing. If you are not using ADBA (Active- Directory Based Activation) you need to make sure that VAMT is at least at the following build 10.1.17763.0 otherwise you will run into problems.

Once I upgraded VAMT then I was able to add my Windows Server 2019 volume license an update license the servers.

NetApp – ONTAP 7-Mode – How to initialize a filer

A client had a very old NetApp filer (FAS3020) that has now been completely decommissioned. In order to purge the data you have a number of options. First, all the volumes and aggregates were deleted save the root volume and aggregate where ONTAP resides.

These spare disk were zeroed with the following command – disk zero spares

There is also the following command – disk sanitize, but you need to licensed. In our case we didn’t have a license nor the option to enable. The filer was running very old code. This also only purges data on disks that are spares.

NetApp link to disk sanitize command https://library.netapp.com/ecmdocs/ECMP1196986/html/GUID-BE1AF56B-40DD-4C42-99D6-76EEC9225DC5.html

In order to remove the data on the root volume and aggregate we initialized the SAN.

WARNING – running this will result in data loss!

If you will be reusing the filer be sure to save your license configuration. Once initialized this info will be lost.

To Initialize

  • Connect to your filer via Console cable
  • Reboot filer
  • Enter the Special Boot Menu with Ctrl-C when prompted
  • Select option 42018-12-27_9-13-31

 

Once all the drives have been initialized – ONTAP will create a new aggregate and vol0. You will then be prompted to setup the filer with configuration data.

Exchange Server 2016 – Unable to assign UM extension

At a client site yesterday, the help desk were provisioning new users with phone extension and for one they came across the error below.

2018-12-26_16-40-01

The user was already assigned this extension in Lync and AD had the correct information. Normally when an extension is in use they would not have been able to add the extension in link.

In order to resolve this issue – I ran the Get-UMMailbox command.  I piped the output to a text file and found that the extension above was still in use on a disabled user. Once removed we were able to assign the extension to the new user.

Exchange 2016 – New-MailboxRepairRequest: Fix corputed mailbox or database

Recently had an issue where a user who was a carried over from Exchange Server 2003 way back when had multiple corrupt items. When he was originally migrated to Exchange Server 2010 there were a number of items which so how got corrupt. This inhibited his search abilities. With the New-MailboxRepairRequest command in Exchange 2016 I was able to resolve this issue.

I ran the repair against all options:

  • ProvisionedFolder
  • SearchFolder
  • AggregateCount
  • Folderview

Once complete we recreated the user’s .OST file since he works in cached mode.

You can find more info on this at Technet:

https://docs.microsoft.com/en-us/powershell/module/exchange/mailbox-databases-and-servers/new-mailboxrepairrequest?view=exchange-ps

vSphere 6.5 – ESXi host unable to join HA or is evicted from HA cluster after a failure – Operation timed out

I recently ran into an issue where one of my ESXi hosts reported errors with HA. I attempted to Reconfigure HA on this host which resulted in the following: Operation timed out.

I then attempted to reconfigure HA entirely – all the other hosts joined except for this one, disconnecting and reconnecting the host, and removing the host from inventory did not alter the behavior. For the life of me I couldn’t get this host to join. So I opened a support call.

I had a Dell based ESXi image installed on this host initially and I had applied a VMware based security patch to this host. Apparently mixing and matching is a no no, this was a known issue in their internal KB which was not open to the public. The only resolution was to reinstall the host (which did resolve the issue).

Maybe it is best to strictly stick to the VMware based images since vendor based images  will usually be behind the curve when security flaws are known and a patch is needed to harden your ESXi host.

 

VMware – How to patch your VCSA 6.5 appliance

Again pretty straight forward – log into your vCenter using either the name or IP followed by :5480

Then select the Update tab. On the top right hand corner select Check Updates. Your vCenter appliance will check VMware’s repository if there are any applicable updates it will appear below. From there you can click Install Updates. Pretty simple.

 

2018-12-06_11-19-59

VMware – Reset Root Password on a VCSA 6.5

So I needed to patch our vCenter 6.5 appliance due to a security flaw in our current version. When I tried to log in using the root password I was unable to do so. I know I had the correct password. Turns out I forgot the default expiration period which I had changed myself (should have set up a calendar reminder). The default I believe is 90 days as you can see here I set it to 365.

2018-12-06_11-04-36

So now that my root password was expired, I was forced to change it. Luckily the steps are pretty simple.

  1. Log onto the ESXi box where your vCenter is homed, then console ino your vCenter.
  2. From there hard restart your vCenter box.
  3. When the Photon OS begins to initialize press the e key to enter the GNU GRUB editor
  4.  Append the following to the 3rd line of code – rw init=/bin/bash

2018-12-06_11-10-57

5. Press F10 to reboot

6. At the prompt type passwd – enter the new root password

7. Then unmount the file system umount / or reboot

 

The VMware KB arrticle can be found here for reference –  https://kb.vmware.com/s/article/2147144