Key Management Service
This is a Microsoft Service hosted on a Windows Server. This service is used to activate Microsoft products like Operating Systems, MS Office Suites, Sharepoint suites etc.
This service can be hosted on your Datacenter Infrastructure without the need to contact Microsoft over Internet. Clients can connect to KMS using DNS dynamic or static entries and communicates over RPC port 135

KMS Activation Thresholds
There is a minimum threshold of clients requesting for activation only after which the KMS server starts activating the clients. For Windows Server Operating Systems, the threshold is 5 systems and for Windows Desktop Operating, the threshold is 25 systems. Until this threshold is met, the systems are not activated however the client machines contact KMS server every 2 hours to see if they have exceeded the threshold count.
There are no restrictions whether it is Physical or Virtual Server or Desktops. 
The KMS Server provides each host with Client Machine Identification [CMID] and saves it in a CMID Table. 

KMS Activation Renewal
KMS Activations are valid for 180 days. By default, KMS Clients attempt to renew their activation every 7 days. If activation fails, the client will retry every 2 hours. Once the computer is activated, the validity begins again.

KMS Service Publication
KMS Service uses DNS SRV records to store and communicate the location of KMS hosts. The KMS Service can also be published manually to the client computers. Steps to manually publish KMS host is given later in this article. 
If there are more than 1 KMS Server in the environment, the Clients randomly selects a KMS server unless the DnsDomainPublishList has specific Priority and Weight configured in the registry to prioritize a KMS server for client requests.

Important Port and Communication
KMS uses 1688 TCP ports [unidirectional - from client as source and KMS server as destination] to communicate with the client machines. The client send a packet of 250 bytes for activation requests to which KMS Host responds with the Activation Count. If the Count is equal or above threshold value, the client is activated and the session is closed.

Note: KMS Host does not require a dedicated Host.

Activating KMS Host
KMS Keys are provided by Microsoft to activate the KMS host. Once the Key is configured on KMS Host, It needs to be activated with Microsoft either via Telephone or Online. No further communication with Microsoft is required. The same KMS Key can be used in activating a maximum of 6 KMS Hosts in your environment.
Now the 6 KMS hosts can be re-activated with the same key for 9 more times. If you need more than 6 keys, Contact Microsoft Activation Call Center

As far as the KMS Server is operational with valid KMS keys and dynamic DNS update is completed to create a KMS SRV record in the current domain DNS, the client machines should be able to discover the KMS server and activate itself.

Important Commands to Publish KMS Hosts manually and activate Client Machines
slmgr -ckms -> To clear current KMS Host configured on client machine
slmgr -skms <kmshostname>:1688 -> To set KMS Host on client machine
slmgr -ipk <product key of OS> -> To set the Product key of OS. Refer to this for current Product Keys presented by Microsoft [https://docs.microsoft.com/en-us/windows-server/get-started/kmsclientkeys]
slmgr -ato -> Activate the client machine against the set KMS server
slmgr TargetComputer [username] [password] /parameter [options] -> To perform slmgr commands remotely on the Target Computer
nslookup -type=all _vlmcs._tcp -> This command should show you all the KMS Hosts in your environment having valid SRV records

Related Posts

• The other way to activate Microsoft Operating Systems are through MAK [Multiple Activation Keys] Activation. I will write a different post for MAK activations.- I will share the links shortly

• How to use KMS Service in a Domain to activate Workgroup clients and other domain clients - I will share the links shortly

Reference Documents
https://docs.microsoft.com/en-us/previous-versions/tn-archive/dd979804(v%3dtechnet.10)

Windows Management Instrumentation [WMI] is a Core Infrastructural set developed by Microsoft for management of Windows devices and data. It helps in scripting and fetching Windows component related to the devices and settings.

WMI caters to the requirements through the WBEM repository where it stores the vital information and it may get corrupt denying proper data as required.

Below are few steps to diagnose if WMI repository is corrupt and steps to troubleshoot OR rebuild the WMI repository

To Verify if WMI repository is fine

winmgmt /verifyrepository

If the Results shows Inconsistent, we can run the following command to repair the repository

winmgmt /salvagerepository

Once the repair is completed, try running /verifyrepository to check if it has fixed the WMI corruption issue. If not, follow the below steps to rebuild the repository

1.       Disable and stop the winmgmt service

2.       Remove or Rename C:\Windows\System32\wbem\repository

3.       Enable and start the winmgmt [Windows Management Instrumentation] service

4.       Open a CMD prompt as Administrator

5.       In the CMD prompt Navigate to C:\Windows\System32\wbem\

6.       Run the following command: ‘for /f %s in ('dir /b *.mof') do mofcomp %s’

Note: This will take a minute or so to complete.

7.       Now run the command: ‘for /f %s in ('dir /b en-us\*.mfl') do mofcomp en-us\%s’

8.       Restart the Data Collector service

These steps should fix the issue with WMI repository

Location of vCenter Server Logs on Windows Server and Appliance

The main focus of this post is to mention the location of vCenter Server Logs. These logs are very necessary for Technical Troubleshooting related to vCenter Server. As we know vCenter Server service can be installed on Windows Server as well as on an Appliance. The location of this logs also varies on different Operating Systems. There are more detailed articles on VMware blogs for more indepth logs and their locations for various VMware products. Here I am only focussing on vCenter Server Logs. In the upcoming posts I will also provide locations of various other VMware products.

There are 2 methods to fetch the VMware vCenter logs
1. By Connecting to VMware vsphere client or web client and logging onto the vCenter Server
2. By either taking a RDP session to vCenter Server [Hosted on Windows Server] and accessing the share paths given below OR by connecting to vCenter Server via SSH [Hosted on Appliance]

1. By Connecting to VMware vsphere client or web client and logging onto the vCenter Server
a. Connect to VMware vCenter via vsphere or web client
b. Go to Home screen -> Click on System Logs
c. At the top, click on Export System Logs
d. On the next prompt, select the VCenter Tree and enter the destination where you need the logs to be exported.

2. By either taking a RDP session to vCenter Server [Hosted on Windows Server] and accessing the share paths given below OR by connecting to vCenter Server via SSH [Hosted on Appliance]

A) On Windows Server having vCenter Server Service Installed

> vCenter Server 5.X and earlier version [if installed on Windows XP, 2000 or 2003] -> %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs

> vCenter Server 5.X and earlier version [if installed on Windows Vista, 7 or 2008] -> C:\ProgramData\VMware\VMware Virtualization\Logs\

> vCenter Server 6.0 -> %ALLUSERSPROFILE%\VMWare\vCenterServer\logs

Note: If the vCenter Service is running with a different account, then the logs would be present under that accounts profile instead of %ALLUSERPROFILE%

B) On Appliances having vCenter Server Service Installed
> vCenter Server Appliance 5.X -> /var/log/vmware/vpx

> vCenter Server Appliance 5.X UI -> /var/log/vmware/vami


> vCenter Server Appliance 6.0 -> /var/log/vmware/

>> References:
https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1021804


https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2110014