Setting up a KMS Server – Windows Server 2012R2

What is a KMS? Microsoft’s KMS allows you to automate license activation for Windows servers and/or applications. In my case, I am using KMS for Windows 2012R2 license activation.  (Oh, KMS stands for Key Management Server) The setup is simple, it took me no more than 15 minutes. Below are the steps I took to set this up. Some pieces of information, I decided to dedicate a server for KMS. Also, when adding the Windows server key, double check and ensure you are using a valid Volume License key, and a KMS key — not MAK! (Yes, there is a difference)

For starters I am going to assume you already made note of the license key from your Microsoft Volume License Servicing Center portal.

As mentioned, I decided to stand up a server dedicated for KMS.

From the Windows Server Manager, install the “Volume Activation Services” role either via the GUI, or via PowerShell. If via PowerShell, here is that command, “Install-WindowsFeature -Name VolumeActivation -IncludeAllSubFeature

Once the role has been installed, launch the Volume Activation Tool console, and essentially next, next, finish!

  • Browse/Select the server that will be hosting the KMS (service):

1

  • Paste in your KMS Host/License Key:

2

3

  • Choose “Active online

4

5

Here, you have some options, how often would you like KMS to check-in, how often would like KMS to apply the key, etc. I left my settings at default, but (assuming) your environment is domain based, check mark Domain for KMS firewall exceptions. Also, by default, KMS listens on TCP port 1688.

6

 

And that is is! Now your existing/new Windows 2012R2 servers will have their licence automatically activated within 2 hours.

(more…)

Advertisements

Creating Easy Tier (Multi-tier) Pool with IBM Storwize

Creating an Easy Tier (aka Multi-tier) pool within IBM’s Storwize is pretty simple, just it cannot be done via its GUI. The GUI definitely lacks this functionality, and thus I had to resort to learning some IBM CLI for the Storwize(V5000). I have been told (from IBM) the command(s) are the same for both the Storwize v7000 and v3700 series as well.

The benefits of IBM’s Easy Tier is rather impressive, and I am sure (please correct me if I am wrong) this exists within other SAN vendors as well. In my pool, there are three types of disk drives, SSD and SAS (both enterprise grade and nearline). The benefits of the multi-tiered (easy tier) pool allows data to be (seamlessly) migrated to higher-IO drives/pools that provide higher performance, ie. SSD pools.

In my case this is great, as I will have heavy-hitting IOPS SQL virtual machines that will probably require the higher performing SAS if not SSD drives. And whereas low-IOPS hitting data such as Quorums on nearline drives.

As IBM states, “Easy Tier can automatically migrate data at the sub-LUN/sub-volume level to the most appropriate storage tier. This includes the ability to automatically and non-disruptively relocate logical volume extents with high activity to storage media with higher performance characteristics, while extents with low activity are migrated to storage media with lower performance characteristics.

So how is this all done?

I am going to assume you have already created your mdisk/RAID groups. In my case my SSD drives are a RAID-5 likewise with my SAS (enterprise) drives. RAID-6 for my SAS nearline drives.

Within the CLI, you will need to get the IDs of all your drives, you can do this by running the following command, “lsdrive“. Now you can see all your drives, and their disk types, IDs, etc.

1

Now you need to create your Easy Tier pool with the mkarray command. (More syntax info can be found HERE)

“mkarray -level <raidType> -drive <IDrangeOfDrivesPerDiskTypeGroupSepeartedByColon(s)> <YourPoolName>”

mkarray -level raid5 -drive 0:1:2:3 EasyTier-Pool
*Do not forget to leave 1 drive behind as a spare within your MDisk pool, otherwise you will have no hot-spare, and will have to rebuild*
4 5

Once you have created your pool, and assoicated all the drives to the Easy Tier pool, you can now see all the mdiskX groups, using the lsmdisk command.

2

For more details, use the lsmdiskgrp command.

3

We can now also confirm the Easy Tier pool within the GUI.

image004

Now we can start building/migrating or whatever it is your SAN was designed for! 🙂

 

For more literature on IBM’s Easy Tier, please visit the LINK.

Hyper-V Network Virtual Switches

So you’ve spun up a Windows 2012R2 machine with Hyper-V installed and ready to go. However, now you’re stuck and not sure which type of  Network Virtual Switch (vSwitch) applies to your environment(s)…

In Windows 2012R2, Hyper-V’s network virtual switch runs at Layer 2 (Data Link layer). If you are unfamiliar with this, or either terms, I suggest good old Wikipedia. 🙂 Layer 2 maintains a MAC address table contains the MAC addresses of all the virtual machines (VMs) connected to it. The switch determines where to direct/redirect the packets to based on MAC addresses. It should be noted, in Hyper-V, you can have an unlimited amount of VMs connected to this vSwitch.

In Hyper-V you have three types of Network Virtual Switches: External, Internal and Private. All have similar functions but are disgustingly different.

  1. External vSwitch allows communication between the VMs running within the Hyper-V hosts, the Hyper-V parent partition, and between all VMs on the remote host server. The External vSwitch does require a network adapter on the host (that is not mapped to any other Hyper-V External vSwitch). You can also tag to a VLAN ID.
  2. Internal vSwitch allows communication between all VMs that are connected to the vSwitch and also allows communication between the Hyper-V parent partition. You can also tag to a VLAN ID.
  3. Private vSwitch allows communication between all VMs that are connected to the vSwitch, and that is it. (Note, no communication between the VMs and its Hyper-V parent partition. Also no VLAN ID tagging can occur on the vSwitch)

Without the use of SCVMM (System Center Virtual Machine Manager), I have found there are two ways to go about creating a vSwitch, one via Hyper-V GUI and second via PowerShell.

Let’s start with the GUI:

Launch the Hyper-V console, and right-click on the Hypervisor’s Virtual Switch Manager. Now selecting New virtual network switch, you can specify your properties here. Name your vSwitch, associate to the correct vNIC, tag to the appropriate VLAN ID, etc.

1 vSwitch HyperV Host

You can now specify which vSwitch for your guest VM to use. Within the VMs properties, you will have the option to chose within the Virtual Switch (you will need to create a Network Adapter if not already done). Once selected you can specify your VLAN ID here. (I am finding you cannot specify the VLAN within the Management vSwitch, but it must be done on the client VM’s end) *Again, this is without the use of SCVMM..yet*

2 vSwitch client OS

 

The same process above can be automated via PowerShell. If you’re like me and need to provision a few dozen Hyper-V hosts, creating vSwitches via the GUI is rather tedious. This can be automated with PowerShell (and SCVMM). Please see the code below:

First you will need to get a list of all the Network Adapters your Hyper-V host has to offer. Hopefully you have named them, if you have not, I highly suggest doing this, and considering this best practice and keeping your sanity.

3 Get Adapter names via PS

Once you have the list of vNICs and their names, you can go ahead and start creating vSwitches.

4 Create vSwitch via PS Code 5 Output Create vSwitch via PS

If the code below worked (note only Line 6 is needed to create the External vSwitch) your Hyper-V host should have the vSwitch, or something similar:

1 vSwitch HyperV Host

 

(more…)

OMS Alerting is Here!

Just a few days ago, Microsoft introduced OMS alerting. For people unaware, this is native alerting for Operations Management Suite. This feature has been requested since OMS’ inception, and Microsoft has listened and finally delivered! Check out their blogpost HERE.

I will be setting up some labs and testing this out in the next few days.

Load Balancing SCOM Agents

So you have multiple SCOM Management Servers, yet you just happen to have all of your SCOM agents reporting to one server, or maybe two if you half tried to load balance your agents. There are several reasons why you would want to have multiple Management Servers, ie. off-load workflows, reduce stress on servers, etc., etc. Well what is the point of having multiple Management Servers yet nearly all of your agents are reporting to one, or maybe two at best Management Servers, while the others are collecting dust. Load balance those agents! You could manually move an agent by right clicking and moving to a new server, or you could let our friend PowerShell automate this for you.

In my experience I have seen many SCOM environments where load balancing is either done manually, or not done at all. And usually manually implies the SCOM administrator takes a look which of the servers has the least agents, and deploys away. That works, but why not deploy to any server then let PowerShell load balance for you.

In the solution below, I am using PowerShell along with Orchestrator 2012R2. The runbook can be setup to run ad-hoc, or run regularly, ie. monthly, weekly, etc. Of course if you do not Orchestrator deployed in your environment, you could very well take the script and schedule it to run via Windows Scheduled tasks.

ce63742c-85d7-402e-b114-c3979b7ce32b

Here I have created a Runbook to execute the script, and then send back a warning notification if the Runbook failed, or an informational notification that the Runbook executed successfully.

See below for the PowerShell script. Please note, you will need to change the Line 5 with a SCOM Management server applicable to your environment, duh. This script can also be modified, and you can load balance between two gateway servers.

The script can be found HERE!

Happy SCOM’ing!

SCOM Servers not “Remotely Manageable”? – Automation

Few posts ago, I blogged on how you can change your manually installed SCOM agents to actually appear as console-deployed. Although this solution is essentially a one time work-around, the solution below is intended for on-going manual installs. The solution below using the same SQL query and creating an automated SQL tasks that runs on a user-defined interval. Following the steps below, you can set this to run every month (or week, or quarter, etc.) and any manually installed will back their “Change Primary Management Server” enabled again.

In my solution below, I was working with SQL Server 2012SP1. This should work for previous iterations of SQL Server as well, 2012, 2008R2, etc.

Following the steps below, and using the SQL query used in a previous POST, you can automate this as well!

 

image001

image002

image003

 

image004

SCOM Servers not “Remotely Manageable”?

Odds are you probably will have some machines where you can’t deploy the SCOM agent via SCOM console, or PowerShell, or some automated way, and you must install and configure the agent manually. Days/weeks/years go by and now you need to decommission that troublesome, manually installed agents Primary Managed Server. You go to the console and right click, and notice you cannot change the machines primary management server.  Well that is because any manually installed agents SCOM/SQL disables this feature. Well, there is a workaround!

Launch SQL and run the following query against the OperationsManager database to get a list of all manually installed servers:

select bme.DisplayName from MT_HealthService mths
INNER JOIN BaseManagedEntity bme on bme.BaseManagedEntityId = mths.BaseManagedEntityId
where IsManuallyInstalled = 1

Now that you have determined which servers were manually installed, to re-enable the remotely manageable feature, run the following SQL query (against the OpsMgr DB).

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1

You should note, this will re-enable this feature for all servers.

Now you should be able to change your machine or any manually installed machines primary management server!

 

Happy SCOM’ing =)