Azure Monitor

In this session we take a look at Azure Monitor and its capabilities.

Azure Monitor Overview

6:08 – Alerts
11:00 – Alerts – Create a New Rule
11:50 – Alerts – Create a New Rule – Step 1
15:46 – Alerts – Create a New rule – Configuring Signal Logic
20:00 – Alerts – Create a new rule – Define Action Groups
25:50 – Metrics
30:21 – Logs
36:20 – Service Health
42:29 – Insights – Application Insights

44:25 – Insights – Virtual Machines (Preview)

48:53 – Insights – Network Watcher

56:12 – ‘More’ Insights
58:12 – Diagnostic settings, AutoScale, Cost, etc


Estimated Usage and Cost


Operations Management Suite Overview

In this session, we will take a look at the ‘current’ Microsoft Operations Management Suite (OMS) Portal and discuss several of the available solutions.

  • Overview of the UI
  • Enabling OMS Solutions
  • AD and SQL Health Checks
  • Log Analytics
  • Security and Audit
  • Data Plan Options
  • Downloading and Installing Agents
  • Connected Data Sources – Storage Accounts, Log Data from Agents, SCOM, SCCM, AD, WSUS
  • Windows Telemetry data ingestion
  • Collecting Windows Event Logs and Performance Data
  • Collecting Linux Performance Counters


Note: It appears the OMS Portal will eventually be fully integrated within the Azure Portal. So some features you see in the OMS Portal may not currently show up in the Azure Portal, and some features in the Azure portal may not show up in the OMS Portal while the service is in this in-between transitional period.

Note: Even if you are on the FREE data plan, some solutions have a COST after a 60 day or less trial period. In particular the Security and Audit feature, now integrated within the Azure Security Center feature has a cost after the expiration of the trial period.

Project Honolulu is now Windows Admin Center and GA!

Earlier we explored using Project Honolulu  and Installing Project Honolulu during its preview phase. Project Honolulu is now generally available and it has been rebranded as “Windows Admin Center”.

Microsoft has released Windows Admin Center, as a re-imagined Windows Server management experience. Windows Admin Center is intended to replace and or supplement the various MMC snap-in tools that an administrator use to do day-to-day activities. Windows Admin Center can be installed on a Windows 10 system, or on a Windows Server 2016 system or later.

Windows Admin Center supports managing Windows Server 2012, 2012 R2, 2016, and later including the free Hyper-V editions of Windows Server remotely. If you need to manage Windows Server 2012 or 2012 R2 you will need to install WMF 5.1 on the target server. Windows Server 2016, 1709, and 2019 Preview do not require any additional add-ins to be managed. Windows Admin Center leverages PowerShell and WMI primarily to perform its’ magic and no additional agents are required. It has no dependencies on Azure or any cloud services. Lastly, Windows Admin Center is quick to install, it does not require IIS or a SQL installation to get started. Currently it is supported on Microsoft’s Edge browser and Google’s Chrome browser.

The best part is that it is web browser based, has no additional cost, and has some functionality that is not available via MMC admin snap-ins or System Center out of the box.

Download Windows Admin Center Now.


Windows Server 2019 Insider Preview Build 17639 Released

A new Windows server 2019 build has been released for windows insiders for both the Long-Term-Servicing Channel (LTSC) branch and the Semi-Annual Channel (SAC) release branch.

Today we will be exploring the installation of a brand new Windows Server 2019 LTSC Preview Build 17639.

In this session, we won’t be focusing on either of the (2) test scenarios or any specific new feature, purely installing and briefly going through the Server Manager experience from a roles and feature perspective.

You can use the following table to help you decide if to use the LTSC or SAC branches.

Long-Term Servicing Channel Semi-Annual Channel
Recommended scenarios                                           General purpose file servers, first and third-party workloads, traditional apps, infrastructure roles, software-defined Datacenter, and Hyper-converged infrastructure Containerized applications, container hosts, and application scenarios benefiting from faster innovation
New releases Every 2–3 years Every 6 months
Support 5 years of Mainstream support
+ 5 years of Extended support
18 months
Editions All available Windows Server editions Standard and Datacenter editions
Who can use All customers through all channels Software Assurance and cloud customers only
Installationoptions Server Core and Server with Desktop Experience Server Core for container host and image and Nano Server container image

There are (2) major areas that the windows insider team would like insiders to try out in this preview release and report back any issues:

  • In-Place OS Upgrade (from Windows Server 2012 R2, Windows Server 2016)
  • Application Compatibility

New Features introduced in Server 2019

  • Cluster Sets
  • Windows Defender Advanced Threat Protection
  • Windows Defender ATP Exploit Guard
  • Windows Defender Application Control
  • Failover cluster removing use of NTLM authentication
  • Shielded virtual machines – offline mode, VMConnect and Linux support
  • Encrypted Network in SDN
  • Performance History for Storage Spaces Direct in combination with Project Honolulu
  • Storage Migration Service
  • Storage Replica enhancements
  • Windows subsystem for Linux- Not called out in any of the announcements but something I noticed in this preview release

Read more about this announcement over on the Windows Blog.

Download Windows Server Insider Preview Builds





Using the SCOM Powershell modules without installing the Console

Today we will be exploring how to use the SCOM Powershell modules without installing the console. By default when you install the SCOM Console on a server or workstation the SCOM PowerShell modules also get installed. Normally, this is the only way to gain access to most of the SCOM Powershell modules. However, by manually copying over the requisites pieces and a few OS tweaks you can use the SCOM PowerShell modules without installing the console.

In order to get started you will need the following:

  • An existing server/workstation with the SCOM Console already installed
  • An existing server/workstation running a supported OS

In this example I will be using a Windows Server 2012 R2 system to deploy the SCOM PowerShell modules. The SCOM environment is a SCOM 1801 deployment. The folders and path may vary if you are using a SCOM 2012, 2012 R2, or 2016 deployment but the steps are essentially the same.

Step 1

Create a temporary folder on your target workstation/server. In my case I am creating a folder named E:\SCOM-Powershell.


Step 2

Connect to a server/workstation that has the full SCOM console already installed and copy the [Install-Drive]:\Program Files\ Microsoft System Center\Operations Manager\PowerShell folder to your temporary folder from Step 1 ex: E:\SCOM-PowerShell.  In this case, I am connecting to the server via a network share and copying the files over from the SCOM-SAC1 server which is a management server that also has the SCOM Console installed.

Note: Your path may vary slightly if you are running SCOM 2012, 2012 R2, or 2016 in all steps.

Step 3

In the temporary folder from Step 1, create a folder named Console and a folder named Server.

Step 4

You will need to copy the following (3) DLLs from your source computer:

  • Microsoft.EnterpriseManagement.Core.dll
  • Microsoft.EnterpriseManagement.OperationsManager.dll
  • Microsoft.EnterpriseManagement.Runtime.dll

The path will vary depending on if the source computer in question is a SCOM management server or a workstation with the console installed and also depending on if it is for SCOM 2012, 2012 R2, 2016, or 1801.

If you are using a SCOM management server browse to the following path:  [Install-Drive]:\Program Files\ Microsoft System Center\Operations Manager\Server\SDK Binaries

If you are using a workstation with the console installed browse to the following path:  [Install-Drive]:\Program Files\ Microsoft System Center\Console\SDK Binaries

Copy the (3) DLLs to your temporary folder from Step 1. ex: E:\SCOM-PowerShell

Step 5

After you have copied the folder, created the empty folders, and copied the DLL files you should have a temporary folder that looks something like this:

Now, on your target workstation, open an Administrator PowerShell command prompt or the Administrator PowerShell ISE and copy and paste the PS code below.  Replace the $TargetFolder variable with the path to your Temporary folder. This will register the DLL’s on your system.

# Replace the TargetFolder with your Temp Folder Path
$TargetFolder = "E:\SCOM-PowerShell"
[Reflection.Assembly]::LoadWithPartialName("System.EnterpriseServices") | Out-Null 
[System.EnterpriseServices.Internal.Publish] $publish = New-Object System.EnterpriseServices.Internal.Publish



Step 6

Lastly, you need to add the SCOM PowerShell module path to the local environment variables. In PowerShell run the following command against your workstation replacing the path with your temp folder.

$CurrentValue = [Environment]::GetEnvironmentVariable(“PSModulePath”, “Machine”)
[Environment]::SetEnvironmentVariable(“PSModulePath”, $CurrentValue + “;$TargetFolder\PowerShell\OperationsManager”, “Machine”)
Import-Module $TargetFolder\PowerShell\OperationsManager\OperationsManager.psd1

Step 7

Close and reopen your PowerShell command prompt or PowerShell ISE session, now The SCOM PowerShell modules should be available and accessible on the target workstation/server. You can test by opening a PowerShell window and attempting to run the following SCOM cmdlets using an account that has permissions within the Management group:

import-module OperationsManager
New-SCOMManagementGroupConnection [EnterAManagementServerNameHere]
Get-SCOMAlert -resolutionstate 0

The (3) commands above will attempt to connect to a SCOM management server and display all of the alerts with a resolution state of ‘New’.

Let me know if you have trouble with any of this with various OS/PowerShell versions/SCOM versions. This has been tested using a SCOM 1801 environment with a Server 2016 and Server 2012 R2 as the target workstation.