What’s new in System Center Operations Manager (SCOM) 2019?

When it comes to monitoring your on-premises datacenter, System Center Operations Manager (SCOM) is still the tool of choice. The System Center stack has been the Microsoft go-to toolset for decades for datacenter management. System Center 2019 it is expected be made Generally Available (GA) in the next few weeks, as Q1 comes to an end.

It is also worth mentioning, SCOM and the entire System Center 2019 stack will be following the Long-Term Servicing Channel (LTSC) model.

Some of the key features that will be highlighted with the release of SCOM 2019 are below.

  • Improved Azure Management Pack (faster and easier to manage)
  • Improved HTML5 dashboards – The new web console has no dependencies on SilverLight and is officially HTML5
  • Azure Service Map Integration
  • Enhanced notifications and alert management – Rich HTML notifications are now default
  • Customize and Preview HTML notification content
  • Email notification improvements such as the ability operators (‘OR’ and ‘EXCLUDE’) to the criteria builder
  • Backend support for SQL Server 2017 and SilverLight dependencies removed
  • Enhanced Agentless alerting during failover scenarios
  • Enhanced certificate validation for Web Application monitoring
  • Application Performance Monitoring (APM) support for CSM (Client Side Monitoring) for Edge and Chrome
  • Support for OpenSSL 1.1.0 for Linux platforms
  • Kerberos support for Linux agent
  • Linux log file monitoring (any custom datasource ie. docker/kubernetes container monitoring)

Advertisements

Deploy an Azure Cloud Witness for your Failover Cluster Quorum for Windows Server 2016 & 2019 with PowerShell

For the longest time, when deploying a cluster with Windows Server, you only had the two options,

  1. Using a dedicated disk for the quorum, or
  2. Configuring an SMB file-share as the quorum witness

With Server 2016 and 2019, there is now a third option, Cloud Witness. The Cloud Witness leverages Azure Blob storage to provide that additional cluster/quorum vote.

Before showing you how this is done, one should understand the purpose of a witness/quorum is with respect to a failover cluster.

When one or more members of a cluster stops reporting to the other cluster members, there is a vote. The vote ensures that there is no split-vote, and ensures the cluster has a true owner. For example, in a two node cluster, if each node believe it is the owner, then this will cause a “split-brain”. In short, neither node will ever agree it is the owner (or not). This is where a quorum is required to determine who is the owner by providing the third vote, ie. majority. This ensures the cluster has a true owner by having the majority of votes. Each member gets a vote, plus the quorum.

Why this matters, in the even there is no quorum, a node from the cluster can be evicted and as a result will suspend all application services to prevent data corruption by more than one system writing data without the cluster services coordinating data writes and access. Depending on policies, VMs running on the ejected cluster member will either suspend operations or be migrated to other nodes before being ejected.

Below is a step-by-step guide on how to configure the Azure Blob storage as the Cloud Witness.

Assumptions:

  • The Azure Blob storage account has already been created,
  • The cluster with at least 2 nodes already exists.

Launch the PowerShell console as Administrator, and execute the following cmdlet:

Set-ClusterQuorum -CloudWitness -AccountName "storage_account_name" -AccessKey "primary_access_key"

Now if we go back to the Failover Manager console we can see we have successfully configured cluster with a Cloud Witness.

In conclusion, deploying a Cloud Witness for a Failover Cluster is very simple, and in case of power outage in one datacenter, maintenance on a node, etc. then the entire cluster and its members (nodes) are all given an equal opportunity. Not only is it recommended and a requirement for 2-node clusters, but for any number of nodes, having a quorum is key ensuring high-availability.  As mentioned, there are the traditional options such as using a dedicated disk or a file-share (SMB) as the cluster witness. However with Azure Blob storage with its 16×9 uptime, we can always ensure the quorum witness is online and available.

Deploy an Azure Cloud Witness for your Failover Cluster Quorum for Windows Server 2016 & 2019

For the longest time, when deploying a cluster with Windows Server, you only had the two options,

  1. Using a dedicated disk for the quorum, or
  2. Configuring an SMB file-share as the quorum witness

With Server 2016 and 2019, there is now a third option, Cloud Witness. The Cloud Witness leverages Azure Blob storage to provide that additional cluster/quorum vote.

Before showing you how this is done, one should understand the purpose of a witness/quorum is with respect to a failover cluster.

When one or more members of a cluster stops reporting to the other cluster members, there is a vote. The vote ensures that there is no split-vote, and ensures the cluster has a true owner. For example, in a two node cluster, if each node believe it is the owner, then this will cause a “split-brain”. In short, neither node will ever agree it is the owner (or not). This is where a quorum is required to determine who is the owner by providing the third vote, ie. majority. This ensures the cluster has a true owner by having the majority of votes. Each member gets a vote, plus the quorum.

Why this matters, in the even there is no quorum, a node from the cluster can be evicted and as a result will suspend all application services to prevent data corruption by more than one system writing data without the cluster services coordinating data writes and access. Depending on policies, VMs running on the ejected cluster member will either suspend operations or be migrated to other nodes before being ejected.

Below is a step-by-step guide on how to configure the Azure Blob storage as the Cloud Witness.

Assumptions:

  • The Azure Blob storage account has already been created,
  • The cluster with at least 2 nodes already exists.

Launching the Failover Manager within Windows Server manager, connect to the cluster, and do the following. Right click the cluster object and select More Actions > Configure Cluster Quorum Settings…

Next select the Advanced Quorum configuration..

Ensure we have all the nodes selected, as seen below.

Next, select the Configure a Cloud Witness:

Now we need to get our Azure Blob storage account name, and its primary account key. This can be retrieved from the Azure portal.

Now validate the settings and complete the configuration.

Now if we go back to the Failover Manager console we can see we have successfully configured cluster with a Cloud Witness.

In conclusion, deploying a Cloud Witness for a Failover Cluster is very simple, and in case of power outage in one datacenter, maintenance on a node, etc. then the entire cluster and its members (nodes) are all given an equal opportunity. Not only is it recommended and a requirement for 2-node clusters, but for any number of nodes, having a quorum is key ensuring high-availability.  As mentioned, there are the traditional options such as using a dedicated disk or a file-share (SMB) as the cluster witness. However with Azure Blob storage with its 16×9 uptime, we can always ensure the quorum witness is online and available.

DNS commands (Command Prompt vs PowerShell)

Recently I discovered Windows PowerShell has the ability to clear the local DNS on a machine, just like the traditional Command Prompt. Below is a table of the most common commands I personally use on a day-to-day basis and its PowerShell equivalent(s). Of course there are more PowerShell cmdlets, see the URL below for the complete list.

Command Prompt PowerShell Description
ipconfig /flushdns Clear-DnsClientCache Clears the contents of the DNS client cache.
ipconfig /registerdns Register-DnsClient Registers all of the IP addresses on the computer onto the configured DNS server.
ipconfig /displaydns Get-DnsClientCache Retrieves the contents of the DNS client cache.
 

(more…)

Flush DNS Cache with PowerShell

For years I have always been using Windows’s command prompt to flush the DNS cache on a local machine. As we know, that command is pretty well known, “ipconfig /flushdns“. Turns out there is an equivalent command we can run within the PowerShell console, and that is, “Clear-DnsClientCache“. Clear-DnsClientCache does exactly what it states, it clears the contents of the DNS client cache/local machine. Consider this next time you need to flush the local machine’s DNS cache.

Clear-DnsClientCache

Happy Retirement SCOM GSM (Global Service Monitor)

Earlier this month, Microsoft announced that the SCOM’s (Operations Manager) GSM (Global Service Monitor) will officially call it quits and retire the service, effectively, November 7th, 2018. As it is a sad day for us, long-time SCOM administrators, the future remains bright, as Microsoft makes way for Application Insights. Over the last year or so, I have done numerous presentations and conferences on Azure’s Application Insights (App Insights), and demonstrating the natural evolution from SCOM APM to Azure App Insights. However, before we start talking about Azure’s App Insights, we need to start thinking about migrate away from GSM.

If you don’t know, GSM, Global Service Monitor in System Center Operations Manager provides the ability to monitor the availability of external web-based applications from multiple locations throughout the world. Microsoft Azure has this feature already within App Insights, called, “Availability“. Creative, I know.. But it does exactly that, measures the availability of your application.

Fellow MVP, Kevin Greene wrote an amazing, and in-depth article on how to migrate your application and GSM to Azure App Insights, so please have a read here. Over the next few blog posts, I would like to provide some detailed demos on Application Insights and how you can start taking advantage of this service to start monitoring your applications.

Step-by-Step – Deploying Azure Site Recovery (ASR) OVF Template (VMware On-Premises)

In the following tutorial, I will go through a step-by-step walk-through on deploying the Azure Site Recovery (ASR) VMware OVF template. This OVF template is a critical step as it bridges the connection between your On-Premises datacenter and the Azure Site Recovery Vault. Obviously there are a handful of prerequisites, as we need to prepare our VMware environment in addition, prepare our Azure workspace. I have created similar posts for Hyper-V and Azure to Azure (A2A) ASR Migrations, please visit the following link for the detailed setups of the Azure Recovery Services Vault HERE.

Let’s begin…  The first step is to download and install the VMware OVF template. The VMware OVF template can be found at the Microsoft Download Center.

Next, we need to deploy the OVF template within vCenter.

Note, this template will consuming about 1.5TB of space. This is a result of Microsoft consolidating the Configuration server and Process server into one workload.

Once the template is deployed, start the appliance and let’s begin registering our vCenter with ASR vault.

Note, the licence provided with OVF template is an evaluation licence valid for 180 days. You as the customer need to activate the windows with a procured licence.

Now we need to provide the server with some local administrative credentials.

Once you have given it some credentials, the server will auto login. The ASR wizard should launch on its own, if not, you can launch it manually — the icon should be on the desktop.

Once the ASR wizard starts, we will now need to complete the setup for this server following by registering the server with ASR.

Give the server some name, ie. VMwareASR01

Next, we need to validate the server can go over the Internet, ie. Azure and communicate as needed. If you are using a proxy, here is the time to set that up.

One thing to note, having the proxy settings configured within Internet Explorer should be removed.

Once an Internet connection has been established, we can then sign into the Azure Portal.

Now we need to sign into Azure with some credentials, ideally with a privileged/Global Administrator account.

Once you have logged into Azure successfully, you will need to reboot the server.

Once the server is back online, the next steps is to configure the Configuration server. 🙂 This step we will register this server/vCenter appliance with our Recovery Services vault. Let’s begin!

The server will auto-launch the ASR wizard, if not, launch it from the desktop icon.

Now that we have established an internet connection, we can configure our Network Interface Card(s) (NICs). Note, you can add as many as NICs needed, however, this needs to be done at the vSphere level. Once the server has been configured, you cannot add and/or remove those NICs. So, make sure you have it configured exactly as you need it. In my case, we will only need one, so, we will configure the NIC here.

Next, we need to sign into our Azure account, and select the corresponding subscription, resource group and select the appropriate recovery services vault. All of these should be available, and should have been created well before we began configure this server, as per the prerequisites…

Next, our server will download, install and configure MySQL on the server, along with the vSphere PowerCLI tools.

Gotcha, here, the appliance did not provide the vSphere PowerCLI tools, so we had to manually download, and install it.

Once we downloaded VMware’s vSphere PowerCLI toolset, we were able to continue. As mentioned, this was not provided, although it should have been. If we continued forward, the wizard would have thrown an error at the end of validation.

Next, we need to now provide the credentials and information with regards to our vCenter server(s).

Please read the prerequisites with regards to the needed permissions to allow our ASR Configuration server to communicate with the vCenter server(s).

Next we need to provide Windows and Linux based credentials to deploy install the ASR Mobility Service to all machines that will need to be replicated to Azure.

For this exercise, we are not replicating Linux machines to Azure, however if we were, similar to the Windows Mobility Service, we would need to provide some credentials that have elevated access to each of the Linux machines.

Once we have provided all the information above, we should now be able to validate some of the settings we have provided, and register our server with Azure and the Recovery Services vault. Give this a few minutes, as it took about 5 minutes to establish the communication/trust.

Once the registration of the server is complete, and the ASR appliance is officially configured with our Azure Recovery Services vault, we should now be able to see the vCenter/Configuration Server within our Azure Recovery Services vault.

If we click on the server, we can get some additional information, such as the server’s health, configuration, heartbeat, and so on…

We can also now click on the Process Server and get some additional information as well.

Now we are able to select the VMs we want to begin replicating to Azure and start testing failovers, either real, or simulated.

I hope this was helpful! Thanks, and until next time…