Additional Resources:

The Azure Log Analytics Query Language Reference can be used to search for examples and further information on query operators and functions:
https://docs.loganalytics.io/docs/Language-Reference

Log Analytics Demo Portal:
https://portal.loganalytics.io/demo

Disclaimer:

All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

let testTable=datatable(projectedVal1: string, projectedResult: string)
[
'Row1','Healthy',
'Row2','Critical',
'Row3','Healthy',
'Row4','Healthy',
'Row5','Warning',
'Row6','Critical',
'Row7','Healthy',
'Row8','Healthy',
'Row9','Healthy',
'Row10','Warning'
];
testTable | project projectedVal1, projectedResult

testTable 
| extend count1=iff(projectedResult == "Healthy" , 1 , 0) //If Healthy, Return 1, else 0
| extend count2=1 // to be used for total row count
| summarize HealthyCount=sum(count1), TotalRecords=sum(count2)
| extend percentAvailable=(HealthyCount*100)/TotalRecords

range i from 0 to 99 step 1 // create dummy table
| project numcount=i+1, mergecol="oms" 
| join kind=rightouter (testTable 
| extend count1=iff(projectedResult == "Healthy" , 1 , 0) //If Healthy, Return 1, else 0
| extend count2=1 // to be used for total row count
| summarize HealthyCount=sum(count1), TotalRecords=sum(count2)
| extend percentAvailable=(HealthyCount*100)/TotalRecords
| extend mergecol="oms" ) on mergecol
| project numcount, HealthyCount, TotalRecords, percentAvailable 


 

range i from 0 to 99 step 1 
| project numcount=i+1, mergecol="oms" 
| join kind=rightouter (testTable 
| extend count1=iff(projectedResult == "Healthy" , 1 , 0) //If Healthy, Return 1, else 0
| extend count2=1 // to be used for total row count
| summarize HealthyCount=sum(count1), TotalRecords=sum(count2)
| extend percentAvailable=(HealthyCount*100)/TotalRecords
| extend mergecol="oms" ) on mergecol
| project numcount, HealthyCount, TotalRecords, percentAvailable 
| where numcount <= percentAvailable
| count
 

let testTable=datatable(projectedVal1:string, projectedResult:string) ['Row1','Healthy','Row2','Critical','Row3','Healthy','Row4','Healthy','Row5','Warning','Row6','Critical','Row7','Healthy','Row8','Healthy','Row9','Healthy','Row10','Warning'];range i from 0 to 99 step 1 | project numcount=i+1, mergecol="oms" | join kind=rightouter (testTable | extend count1=iff(projectedResult == "Healthy" , 1 , 0) | extend count2=1 | summarize HealthyCount=sum(count1), TotalRecords=sum(count2) | extend percentAvailable=(HealthyCount*100)/TotalRecords | extend mergecol="oms" ) on mergecol| project numcount, HealthyCount, TotalRecords, percentAvailable | where numcount <= percentAvailable| count
 

range i from 0 to 99 step 1 | project numcount=i+1, mergecol="oms" | join kind=rightouter (testTable | extend count1=iff(projectedResult == "Healthy" , 1 , 0) | extend count2=1 | summarize HealthyCount=sum(count1), TotalRecords=sum(count2) | extend percentAvailable=(HealthyCount*100)/TotalRecords | extend mergecol="oms" ) on mergecol| project numcount, HealthyCount, TotalRecords, percentAvailable | where numcount <= percentAvailable| count

let tot1=toscalar ( Perf | summarize count() ) ;
let tot2=toscalar ( Perf | where ObjectName == "Processor" | summarize count() ) ;
let perc = tot2*100/tot1;
print perc

Additional Resources:

The Azure Log Analytics Query Language Reference can be used to search for examples and further information on query operators and functions:
https://docs.loganalytics.io/docs/Language-Reference

Log Analytics Demo Portal:
https://portal.loganalytics.io/demo

Disclaimer:

All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

1. The number of computers connected and sending data to the Security & Audit Solution
2. A “1” if Solution Based Billing has been activated for the Security & Audit Solution of this OMS Workspace, and “0” if otherwise,

within a default 24 Hour window.

The following views are available when drilling-in from the summary tile:

1. Information View – Provides a summary description for the OMS Free Tier Solution Based Billing Tracker - Security & Audit Dashboard, links to obtain further information and to download the .omsview JSON file for the dashboard.
2. View 1 (Retention - 90 Days | Source - Azure Log) – Provides a last 24-hour summary of the number of times the Security & Audit Solution was added successfully after June 19, 2017 on the 2-Numbers Tile section, and lists the Security & Audit Solution related activities captured in the Azure Activity Log after June 19, 2017, like Add or Remove, order by date and time on the List section of the View.
3. View 2 (Retention - 7 Days) – Provides a last 24-hour summary of the number of computers connected and sending data to the Security &Audit Solution on the Single Number Tile section, and returns a “YES” if Billing has been enabled for the Security & Audit Solution of the OMS Workspace in the Free Tier (when LinkedMeterId!="00000000-0000-0000-0000-000000000000"), and a “NO” if otherwise on the List section of the View.
4. View 3 (Retention - 7 Days) – Provides a chart of the total size of data uploaded by computers monitored by the Security & Audit Solution (in MB) over a 24-hour period on the Line Chart & Callout section, and returns a “YES” if Solution Based Billing specifically has been activated for the Security & Audit Solution of the OMS Workspace in the Free Tier (when LinkedMeterId="15e6182d-2afe-4c9e-8c23-4062bd80b3d4" in the Free Tier), and a “NO” if otherwise on the List section of the View.

 


An OMS Workspace with the Security & Audit Solution added before June 19, 2017 would look like this example:


 

To implement the OMS Free Tier Solution Based Billing Tracker Dashboard – Security & Audit Dashboard to an OMS Workspace, download the .omsview JSON file from the TechNet Gallery and upload the file to the OMS Workspace using the Import option in the View Designer.





Here is the main log search query that extends the Azure Activity Log records in Log Analytics and is used to lists the Security & Audit Solution related activities captured after June 19, 2017:
Type=AzureActivity Resource=Security TimeGenerated>2017-06-19T00:00 | select OperationName, TimeGenerated

Here is the query that provides further filtering to look for records of the Security & Audit Solution being added successfully after June 19, 2017:
Type=AzureActivity Resource=Security ActivityStatus=Succeeded ActivitySubstatus=Created* TimeGenerated>2017-06-19T00:00

Since the AzureActivity typed records from the Azure Activity Logs are available in an OMS Workspace for 90 days, the list of Security & Audit Solution related activities beyond 7 days after June 19, 2017, like when was the solution added or removed, can be retrieved with these log search query to help with further analysis or auditing. Note that if the Azure Subscription has multiple OMS Workspaces, then the Azure Activity Log will contain the events from all the OMS Workspaces and accessible in these Workspaces as well.
 

Here are the main log search queries that extends the Log Analytics Usage records and used within the Free Tier Solution Based Billing Tracker - Security & Audit Dashboard to detect whether Solution Based Billing has been enabled for the Security and Audit Solution in an OMS Workspace in the Free Tier:

1. Returns a “YES” if Billing has been enabled for the Security & Audit Solution of the OMS Workspace in the Free Tier, and a “NO” if otherwise
   Type=Usage DataType=SecurityEvent MeterId="2073b0aa-c836-4642-9d97-0635f52e3520" | Extend if(termfreq(LinkedMeterId,"00000000-0000-0000-0000-000000000000"),"NO", "YES") as IsFreeTierBilled| select IsFreeTierBilled| Top 1
2. Returns a “YES” if Solution Based Billing has been activated for the Security & Audit Solution of the OMS Workspace in the Free Tier, and a “NO” if otherwise:
   Type=Usage DataType=SecurityEvent MeterId="2073b0aa-c836-4642-9d97-0635f52e3520" | Extend if(termfreq(LinkedMeterId,"15e6182d-2afe-4c9e-8c23-4062bd80b3d4"),"YES","NO") as Billing| select Billing | Top 1

OMS Alerts can be configured to send notifications to recipients (via emails or SMS) if Solution Based Billing is enabled or Security & Audit Solution activities from the Azure Activity Log is detected.


Here is a mapping of the Display Name to Meter ID GUID of some of the OMS Pricing Tiers:

If the Linked Meter Id of SecurityEvent related Usage typed records from the Security & Audit Solution is not overriden and still maintains the default value of "00000000-0000-0000-0000-000000000000", it indicates that billing has not been enabled for the Security & Audit Solution in this OMS Workspace, as shown in the picture below for an OMS Workspace in the Free Tier:
 


If the Linked Meter Id of SecurityEvent related Usage typed records from the Security & Audit Solution is overriden with a value NOT EQUALS to  "00000000-0000-0000-0000-000000000000", it indicates that billing has been enabled for the Security & Audit Solution in this OMS Workspace, and Solution Based Billing has been enabled if the Linked Meter Id is EQUAL to “15e6182d-2afe-4c9e-8c23-4062bd80b3d4", as shown in the picture below for an OMS Workspace in the Free Tier:
  

In this case, after 60 days of trial for the continuous use of this solution, a per node billing will be applied.

Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

This post provides some additional information on how we can utilize the Free Tier Data Consumption Tracker to understand OMS data ingestion behaviour and status of a particular OMS Workspace using the Free Tier.
 


For an OMS Workspace using the Free Tier, if the daily data upload limit for the Free Tier is exceeded, data ingestion will stop (until UTC midnight when it will resume). However, this stop action does not take place immediately and it takes a little while longer for the data ingestion to fully come to a stop. Hence, some of the data collected beyond that limit will still show up in the OMS Portal.

The Free Tier Data Consumption Tracker uses a direct approach to calculate the percentage of the Free Tier data allowance used within the last 24 hours (NOW-24HOURS) regardless of whether it overlaps with UTC midnight or not. With this approach, if the data flows in to the OMS Workspace at a steady volume and the hourly data allowance used is on average safely below the hourly data limit of around 4%, then the % Quota Used value shown on the Tracker’s view will be a value that is below 100%.

When a value of over 100% is displayed on the Tracker, it could be due to the following reasons:

1. When large volumes of data is collected within a small time window in the last 24 hours, causing the % Quota Used to spike up to a value more than 100%, as illustrated in the table below:
      
   
   On the Usage page, it could look like the following example where more than 500 MB of data was ingested into the OMS Workspace and only stops after 859 MB (171.8% of the Free Tier allowance) was ingested.
   
   
   
   Another example below uses the time window chart on the top left of the Log Search page to show the relative size of the total number of records ingested per hour, by using the Custom setting to drill into a specific hourly window:
   
   
   
   First hour after UTC midnight:
    
   
   
   2 hours after UTC midnight:
    
   
   
   3 hours after UTC midnight:
    
   
   
   4 hours after UTC midnight:
    
   
   
   5 hours after UTC midnight:    
   
   
   The example above shows that data ingestion for this instance stops after the 4th hour window when 135.16% of the Free Tier allowance has been consumed.
    
   
   
2. When large volumes of data is collected in the last 24 hours and overlaps with UTC midnight where the 500 MB data allowance is resumed, causing the % Quota Used to spike up to a value more than 100% or even 200%, as illustrated in the table below:
   
   
   
   On the Tracker, it could look like the following example where more than 200% of the Free Tier allowance was consumed.
   
   
   

A % Quota Used value of over 100% is a good indicator that a particular OMS Workspace maybe receiving too much data due to configuration changes or something happening in the OMS monitored environment causing a sudden increase in the Or it could just be a case of the connected sources sending too much data daily to their OMS workspace via agent collection or the collector API etc and consuming all the Free Tier data allowance before reaching UTC midnight of the next day.


As demonstrated above, this “NOW-24HOURS” approach provides a straight forward summary of the overall data allowance consumption status and whether the daily upload limit of the Free Tier is being stretched or close to being exceeded to help OMS users make an educated decision on either to upgrade to the Standalone tier or to the E1/E2 subscriptions, to build on their existing investments while enjoying the larger data upload allowance or Premium solutions in the upgraded tiers.

Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

Here is an example of how Sample Script 1 identifies state changes happening within the Entity Health rollup monitor, calculates the total time difference in seconds between each state change from Healthy to Not Healthy between “now” and 15 hours ago, and sums them all up in order to get the percentage of time the Operations Manager Management Group distributed application object was in Healthy state over the last 15 hours.

Sample Script 1: 

Sample Script 1 takes into account the following conditions:

• If the initial state of the monitor is Healthy and No State Changes has been identified over the last X hours, then it is Available 100% of the time.
• If the initial state of the monitor is Not Healthy (in Warning or Error or Uninitialized) and No State Changes has been identified over the last X hours, then it is Available 0% of the time.
• If the first state change is a change from a Healthy to Not Healthy state, include the time difference between the start time and the time of that state change into the total time the monitor is in Healthy state.
• If the last state change is a change from a Not Healthy to Healthy state, include the time difference between the time of that state change and the current time (now) into the total time the monitor is in Healthy state.

function New-Collection ( [type] $type ) 
{
   $typeAssemblyName = $type.AssemblyQualifiedName;
   $collection = new-object "System.Collections.ObjectModel.Collection``1[[$typeAssemblyName]]";
   return ,($collection);
}

$newline = "`r`n" 

#Last x hours UTC
$backdateHour  = 15  #NOTE: Replace with a numerical value for the time window in hours.

#Get Entity Health Monitor
$monitorObject = Get-SCOMMonitor -Name System.Health.EntityState

#Get the Distributed Application object. NOTE: Use the Object ID for more accuracy. 
$DistributedApp = get-scomclassinstance -displayname "Operations Manager Management Group"

#Add monitor to collection
$monitorCollection = new-collection $monitorObject.GetType()
$monitorCollection.Add($monitorObject)

#Get health state information of the Entity Health Monitor running against the Distributed Application object
$monitoringStates = $DistributedApp.GetMonitoringStates($monitorCollection)

#Get all state changes of the Entity Health Monitor running against the Distributed Application object
$stateChanges = $monitoringStates.GetMonitoringStateChangeEvents()

#Get start and end points of date time range
#Get current date time in UTC and date time X hours ago
$aggregationInterval = $backdateHour
$dt = New-TimeSpan -hour $aggregationInterval
$nowlocal = Get-Date
#Convert local time to UTC time
$now = $nowlocal.ToUniversalTime()
$from = $now.Subtract($dt)

#Get all state changes between date time range and sort based on state change time
$stateChangesSortedx = $stateChanges | where{$_.TimeGenerated -gt $from} | sort-object @{Expression={$_.TimeGenerated}; Ascending=$true} 

$index = 0
$TotalTimeDiff = 0

#If state changes exists ...
If($stateChangesSortedx.count -ne 0)
{

    foreach($stateChangesSorted in $stateChangesSortedx)
    {    
        if($index -lt 1)
        {
            If($stateChangesSorted.OldHealthState -eq "Success")
            {
             $TimeDiff = $stateChangesSorted.TimeGenerated - $from
          $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds
            }
            else  #New State Equals Success
            {  
                if($stateChangesSortedx.count -eq 1 -and $stateChangesSorted.NewHealthState -eq "Success") #Only 1 single state change
                {
                    $TimeDiff = $now - $stateChangesSorted.TimeGenerated
                    $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds               
                }
            }

        }
        else
        {
            If($stateChangesSorted.OldHealthState -eq "Success")
            {
                $TimeDiff = $stateChangesSorted.TimeGenerated-$stateChangesSortedx[$index-1].TimeGenerated
                $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds                
            }
         else
         {
         
             if($index -eq $stateChangesSortedx.count-1 -and $stateChangesSorted.NewHealthState -eq "Success")
                {
                    $TimeDiff = $now - $stateChangesSorted.TimeGenerated
                    $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds               
                }         
         }  
        }
        $index++
    }
}
else # if no state change exist
{
    if($monitoringStates.HealthState -eq "Success")
    {$TotalTimeDiff = $backdateHour*3600}
    else
    {$TotalTimeDiff=0}

}

#Calculate percentage of availability of the distributed application object
$PercentAvailable = [Math]::Round(($TotalTimeDiff/(3600*$backdateHour))*100,2)

if($monitoringStates.HealthState -eq "Success")
{
    $HealthState1 = "Healthy"
}
else
{
    $HealthState1 = $monitoringStates.HealthState
}

$result = "Current Health State of "+ $DistributedApp.displayName + " is " + $HealthState1 + ", was available " + [String]$PercentAvailable  +"% of the time over the last " + $backdateHour + " hour(s)." + $newline + $newline + "Number of State Changes: " + $stateChangesSortedx.count + $newline

$result

The following picture shows another example of an OpsMgr native dashboard with the Speedometer and Text Display widgets, displaying the percentage of availability of the Operations Manager Management Group distributed application object in two difference ways, but this time, its above the 80% threshold.

 

Sample Script 2: 

Sample Script 2 is similar to Sample Scrip1. The only difference is that the script returns all distributed application objects under the System.Service class and loops through to calculate their overall percentage of availability to produce the following result:

function New-Collection ( [type] $type ) 
{
   $typeAssemblyName = $type.AssemblyQualifiedName;
   $collection = new-object "System.Collections.ObjectModel.Collection``1[[$typeAssemblyName]]";
   return ,($collection);
}

$newline = "`r`n" 

#Last x hours UTC
$backdateHour  = 15  #NOTE: Replace with a numerical value for the time window in hours.

$monitorObject = Get-SCOMMonitor -Name System.Health.EntityState

#Get parent Class for all Distributed Applications
$class = get-scomclass -Name System.Service
#Return all Distributed Application Objects
$DistributedApps = get-scomclassinstance -clas $class

#Add monitor to collection
$monitorCollection = new-collection $monitorObject.GetType()
$monitorCollection.Add($monitorObject)

ForEach($DistributedApp in $DistributedApps)
{
#Get health state information of the Entity Health Monitor running against the Distributed Application object
$monitoringStates = $DistributedApp.GetMonitoringStates($monitorCollection)

#Get all state changes of the Entity Health Monitor running against the Distributed Application object
$stateChanges = $monitoringStates.GetMonitoringStateChangeEvents()

#Get start and end points of date time range
#Get current date time in UTC and date time X hours ago
$aggregationInterval = $backdateHour
$dt = New-TimeSpan -hour $aggregationInterval
$nowlocal = Get-Date
#Convert local time to UTC time
$now = $nowlocal.ToUniversalTime()
$from = $now.Subtract($dt)

#Get all state changes between date time range and sort based on state change time
$stateChangesSortedx = $stateChanges | where{$_.TimeGenerated -gt $from} | sort-object @{Expression={$_.TimeGenerated}; Ascending=$true} 

$index = 0
$TotalTimeDiff = 0

#If state changes exists ...
If($stateChangesSortedx.count -ne 0)
{

    foreach($stateChangesSorted in $stateChangesSortedx)
    {    
        if($index -lt 1)
        {
            If($stateChangesSorted.OldHealthState -eq "Success")
            {
             $TimeDiff = $stateChangesSorted.TimeGenerated - $from
          $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds
            }
            else  #New State Equals Success
            {  
                if($stateChangesSortedx.count -eq 1 -and $stateChangesSorted.NewHealthState -eq "Success") #Only 1 single state change
                {
                    $TimeDiff = $now - $stateChangesSorted.TimeGenerated
                    $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds               
                }
            }

        }
        else
        {
            If($stateChangesSorted.OldHealthState -eq "Success")
            {
                $TimeDiff = $stateChangesSorted.TimeGenerated-$stateChangesSortedx[$index-1].TimeGenerated
                $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds                
            }
         else
         {
         
             if($index -eq $stateChangesSortedx.count-1 -and $stateChangesSorted.NewHealthState -eq "Success")
                {
                    $TimeDiff = $now - $stateChangesSorted.TimeGenerated
                    $TotalTimeDiff = $TotalTimeDiff + $TimeDiff.TotalSeconds               
                }         
         }  
        }
        $index++
    }
}
else # if no state change exist
{
    if($monitoringStates.HealthState -eq "Success")
    {$TotalTimeDiff = $backdateHour*3600}
    else
    {$TotalTimeDiff=0}
}

$PercentAvailable = [Math]::Round(($TotalTimeDiff/(3600*$backdateHour))*100,2)

#Calculate percentage of availability of the distributed application object
if($monitoringStates.HealthState -eq "Success")
{
    $HealthState1 = "Healthy"
}
else
{
    $HealthState1 = $monitoringStates.HealthState
}

$result = "Current Health State of "+ $DistributedApp.displayName + " is " + $HealthState1 + ", was available " + [String]$PercentAvailable  +"% of the time over the last " + $backdateHour + " hour(s)." + $newline + $newline + "Number of State Changes: " + $stateChangesSortedx.count + $newline

$result
}

IMPORTANT NOTE about Sample Script 1 and Sample Script 2:

Both sample scripts assume that the distributed application objects are always NOT in a greyed out state and hence also assumes that the management server(s) managing them are always available and running.

Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

This post features a custom OMS Dashboard – the Free Tier Data Consumption Tracker - that extends the Log Analytics Usage records used primarily to drive the Usage Dashboard. It provides a summary view of the data quota consumption relative to the 500 MB daily data upload limit of the OMS Free Tier, calculated in percentage. The .omsview JSON file for the OMS Free Tier Data Consumption Tracker Dashboard can now be downloaded from the TechNet Gallery.
 
                     

My personal view is that having the Free Tier in OMS is an advantage as it not only allows the end user to try out the services and solutions in OMS for free, it also allow solution developers and service providers to test the waters with their custom solutions and plan their customer POCs without having to deal with the complexities of billing and usage charges up front.
However, if the daily data upload limit for the Free Tier is exceeded, data beyond that limit will not be analysed and records will stop showing up in the OMS Portal. Therefore, this dashboard will be able to provide a clearer picture of the overall data consumption status and whether the daily upload limit of the Free Tier is being stretched or close to being hit when used in an OMS Workspace.

The OMS Free Tier Data Consumption Tracker Dashboard consists of a summary tile on the main page of the OMS Portal that shows how much of the Free Tier daily upload limit has been consumed by all the billable solutions used in the OMS Workspace. The following views are available when drill-in from the summary tile:

1. Information View – Provides a summary description for the OMS Free Tier Data Consumption Tracker Dashboard, links to obtain further information and to download the .omsview JSON file for the dashboard.
2. Free Tier Data Consumption by Solution & DataType View – Provides a last 24-hour summary of the overall Free Tier billable data consumption broken down by Solution on the Donut section, and listing the names of all the OMS DataTypes and their corresponding Solution with the highest Free Tier quota usage, with a monitor that will change state when their % Quota Used exceed thresholds: Above 75=Warning and Above 95=Error, on the List section of the View.
3. For Nodes/Endpoints/Computers Only View – Provides a last 24-hour summary of the overall Free Tier billable data consumption caused by Nodes/Endpoints/Computers only, broken down by DataType on the Donut section, and listing the names of all the OMS Nodes/Endpoints/Computers and their corresponding DataType with the highest Free Tier quota usage, with a monitor that will change state when their % Quota Used exceed thresholds: Above 75=Warning and Above 95=Error, on the List section of the View.
4. For Non-Nodes View – Provides a last 24-hour summary of the overall Free Tier billable data consumption caused by non-Nodes (records Data not associated with a computernot associated to any Node/Endpoint/Computer), broken down by DataType on the Donut section, and listing the names of all the non-Nodes and their corresponding DataType with the highest Free Tier quota usage, with a monitor that will change state when their % Quota Used exceed thresholds: Above 75=Warning and Above 95=Error, on the List section of the View.
5. Billable vs Non-Billable Usage View - Provides a last 24-hour summary of the overall non-billable data usage to the Free Tier comparison, broken down by DataType on the Donut section, and displaying the total billable Free Tier quota usage, with a monitor that will change state when it’s % Quota Used exceeds thresholds: Above 75=Warning and Above 99=Error, on the List section of the View.

 

 
To implement the OMS Free Tier Data Consumption Tracker Dashboard to an OMS Workspace, download the .omsview JSON file from the TechNet Gallery and upload the file to the OMS Workspace using the Import option in the View Designer.

 



Here is the main query that extends the Log Analytics Usage records and is used to drive each of the Views within the Free Tier Data Consumption Tracker Dashboard. It filters the record of Type=Usage, to summarize and display them accordingly:

Type=Usage QuantityUnit="MBytes" IsBillable=true TimeGenerated>NOW-24HOURS | Extend mul(Quantity,0.2) AS UsedFreeTierPercent | measure sum(UsedFreeTierPercent) AS TotalUsedFreeTierPercent by Solution

Additional Resources:

Analyze data usage in Log Analytics by Richard Rundle
https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-usage

Get notified if OMS Log Analytics usage is higher than expected by Richard Rundle
https://blogs.technet.microsoft.com/msoms/2016/11/21/get-notified-if-oms-log-analytics-usage-is-higher-than-expected/

Arithmetic operations meet aggregate queries in OMS by Leyla Kazemi
https://blogs.technet.microsoft.com/msoms/2016/09/13/arithmetic-operations-meet-aggregate-queries-in-oms/

Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

1. Information View – Provides a summary description for the OMS Upgrade Helper Dashboard, links to obtain further information and to download the Upgrade Helper Management Pack, the .omsview JSON file for and the collection script.
2. Upgrade State of Core Components View – Provides a summary of the overall upgrade state of the core components of the management group of interest by showing the percentage and number of core components already upgraded or not upgraded to OpsMgr 2016 on the Donut section, and listing the names of all the core components, their upgrade state and their roles on the List section of the View.
3. Upgrade State of Agents View – Provides a summary of the overall upgrade state of the agents of the management group of interest by showing the percentage and number of agents already upgraded or not upgraded to OpsMgr 2016 on the Donut section, and only listing the names and versions of each agents that have yet to be upgraded on the List section of the View.
4. SCOM Agent Patch List View – Provides a count of the total number of agents found in the management group of interest on the Single Number section, and a list of agent patches identified with the number of occurrences found for each patch list in the management group of interest on the List section of the View.

 

Here are the steps on how to:

• Implement the OMS Upgrade Helper Dashboard to an OMS Workspace, and
• Collect and send the required upgrade state data of a management group to the OMS Workspace to be displayed on the Upgrade Helper Dashboard.
  

To implement the OMS Upgrade Helper Dashboard to an OMS Workspace, download the .omsview JSON file from the TechNet Gallery and upload the file to the OMS Workspace using the Import option in the View Designer.

 


To collect and send the required upgrade state data of a management group to an OMS Workspace, use the sample data collection script that can be downloaded together with the .omsview JSON file from the TechNet Gallery. The sample collection script is written in PowerShell and leverages the OMS HTTP Collector API  to introduce a Custom Log Type for the upgrade state data –  OM16UpgradeState, and to send the collected data to the OMS Workspace in a JSON payload.

Here is the sample PowerShell script used in the data collection script (UpgradeStatusCollectionScript.SendtoOMS.v1.ps1):
IMPORTANT NOTE:
This collection script must either be (1.) run on the Operations Manager Shell or in a PowerShell session with the OperationsManager module imported, (2.) connected to the Operations Manager management group of interest (3.) with the Upgrade Helper Management Pack imported, and (4.) have access to the internet via HTTP.

# Replace with your Workspace ID
$CustomerId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
  
# Replace with your Primary Key
$SharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

#Specify the name of the record type that we'll be creating.
$LogType = "OM16UpgradeState"

#Specify a time in the format YYYY-MM-DDThh:mm:ssZ to specify a created time for the records.
$TimeStampField = ""

$coreComponentArray=@()
$agentCollectionArray=@()

# Function to create the authorization signature.
Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
    $xHeaders = "x-ms-date:" + $date
    $stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" + $resource

    $bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
    $keyBytes = [Convert]::FromBase64String($sharedKey)

    $sha256 = New-Object System.Security.Cryptography.HMACSHA256
    $sha256.Key = $keyBytes
    $calculatedHash = $sha256.ComputeHash($bytesToHash)
    $encodedHash = [Convert]::ToBase64String($calculatedHash)
    $authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
    return $authorization
}

# Function to create and post the request
Function Post-OMSData($customerId, $sharedKey, $body, $logType) 
{
    $method = "POST"
    $contentType = "application/json"
    $resource = "/api/logs"
    $rfc1123date = [DateTime]::UtcNow.ToString("r")
    $contentLength = $body.Length
     $signature = Build-Signature `
        -customerId $customerId `
        -sharedKey $sharedKey `
        -date $rfc1123date `
        -contentLength $contentLength `
        -fileName $fileName `
        -method $method `
        -contentType $contentType `
        -resource $resource
    $uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"

    $headers = @{
        "Authorization" = $signature;
        "Log-Type" = $logType;
        "x-ms-date" = $rfc1123date;
        "time-generated-field" = $TimeStampField;
    }

    $response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
    return $response.StatusCode
} 


#////Main Section////

$coreComponentClass = get-scomclass -name OperationsManager2016.Upgrade.CoreComponent
$coreComponents = Get-SCOMClassInstance -class $coreComponentClass
foreach ($coreComponent in $coreComponents) {

$Hostname = $coreComponent.Name
$ComponentVersion = $coreComponent.'[OperationsManager2016.Upgrade.CoreComponent].ComponentVersion'.value
$Role = $coreComponent.'[OperationsManager2016.Upgrade.CoreComponent].Role'.value
If($coreComponent.HealthState -ne "Success")
{$UpgradeState = "Not Upgraded"}
else
{$UpgradeState = "Success"}
$IsAvailable = $coreComponent.IsAvailable
$OMManagementGroupName = $coreComponent.ManagementGroup
$FullName = $coreComponent.FullName
$LastModified = ($coreComponent.LastModified).ToString("yyyy-MM-ddThh:mm:ssZ");
$OMObjectId= $coreComponent.Id
$OMManagementGroupId= $coreComponent.ManagementGroupId
$AgentPatchList= ""
$AgentManagement =""
$coreComponentArray += @{"Hostname"=$Hostname.ToString();"ComponentVersion"=$ComponentVersion.ToString();"Role"=$Role.ToString();"UpgradeState"=$UpgradeState.ToString();"IsAvailable"=$IsAvailable.ToString();"OMManagementGroupName"=$OMManagementGroupName.ToString();"FullName"=$FullName.ToString();"LastModified"=$LastModified;"OMObjectId"=$OMObjectId;"OMManagementGroupId"=$OMManagementGroupId;"AgentPatchList"=$AgentPatchList.ToString();"AgentManagement"=$AgentManagement.ToString()}
}


$agentClass = get-scomclass -Name Microsoft.SystemCenter.Agent
$Agents = Get-SCOMClassInstance -class $agentClass
foreach ($Agent in $Agents) {

$Hostname = $Agent.Path
$ComponentVersion = $Agent.'[Microsoft.SystemCenter.HealthService].Version'.value
$Role = "Agent"
If($ComponentVersion -gt 7.2)
{$UpgradeState = "Success"}
else
{$UpgradeState = "Not Upgraded"}
$IsAvailable = $Agent.IsAvailable
$OMManagementGroupName = $Agent.ManagementGroup
$FullName = $Agent.FullName
$LastModified = ($Agent.LastModified).ToString("yyyy-MM-ddThh:mm:ssZ");
$OMObjectId= $Agent.Id
$OMManagementGroupId= $Agent.ManagementGroupId
$AgentPatchList= $Agent.'[Microsoft.SystemCenter.HealthService].PatchList'.value
$AgentInstallation = $Agent.'[Microsoft.SystemCenter.HealthService].IsManuallyInstalled'.value
If($AgentInstallation -eq $True)
{$AgentManagement ="Manual"}
else
{$AgentManagement ="Remote"}
$agentCollectionArray += @{"Hostname"=$Hostname.ToString();"ComponentVersion"=$ComponentVersion.ToString();"Role"=$Role.ToString();"UpgradeState"=$UpgradeState.ToString();"IsAvailable"=$IsAvailable.ToString();"OMManagementGroupName"=$OMManagementGroupName.ToString();"FullName"=$FullName.ToString();"LastModified"=$LastModified;"OMObjectId"=$OMObjectId;"OMManagementGroupId"=$OMManagementGroupId;"AgentPatchList"=$AgentPatchList.ToString();"AgentManagement"=$AgentManagement.ToString()}
}

$coreComponentArrayJSON = $coreComponentArray | ConvertTo-JSON
# Submit the data to the API endpoint - for core components
Post-OMSData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($coreComponentArrayJSON)) -logType $logType

If($agentCollectionArray.count -lt 480)
{
$agentCollectionArrayJSON = $agentCollectionArray | ConvertTo-JSON

# Submit the data to the API endpoint - for agents
Post-OMSData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($agentCollectionArrayJSON)) -logType $logType
}
else
{
    $indextracking=0
    ForEach($collectedAgentItem in $agentCollectionArray)
    {
        # Submit the data to the API endpoint - for agents
        $collectedAgentItemFixed = ConvertTo-Json -InputObject @($collectedAgentItem) 
        Post-OMSData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($collectedAgentItemFixed)) -logType $logType

        $indextracking++

   }
}

If successful, the upgrade state data collected by the HTTP Collector API should appear in the OMS Upgrade Helper Dashboard in the targeted OMS Workspace within a few minutes.

To list all records of the OM16UpgradeState type that were successfully sent to the targeted workspace, run the Type=OM16UpgradeState_CL search query. The records returned from the search result should appear as follows with the field data types identified accordingly as indicated by their suffix:
 


The search queries used to power each of the Views within the Upgrade Helper Dashboard will filter these records to summarize and display them accordingly as show in the following example:

 


The tooltip feature displays the full name when hovering the pointer above the line item in the List view.
 



Here are the queries for each visualization and navigation component of each View in the Upgrade Helper Dashboard above:

##Upgrade State of Core Components
#Donut Query
Type=OM16UpgradeState_CL Role_s!=Agent| measure count() by UpgradeState_s
#List Query
Type=OM16UpgradeState_CL Role_s!=Agent | Measure Countdistinct(Hostname_s) by Hostname_s, UpgradeState_s, Role_s
#Navigation Query
Type=OM16UpgradeState_CL Role_s!=Agent

##Upgrade State of Agents
#Donut Query
Type=OM16UpgradeState_CL Role_s=Agent | measure count() by UpgradeState_s
#List Query
Type=OM16UpgradeState_CL Role_s=Agent UpgradeState_s="Not Upgraded" | Measure Countdistinct(Hostname_s) by Hostname_s, ComponentVersion_s
#Navigation Query
"Type=OM16UpgradeState_CL Role_s=Agent UpgradeState_s="Not Upgraded"

##SCOM Agent Patch List
#Number Tile Query
Type=OM16UpgradeState_CL Role_s=Agent
#List Query
Type=OM16UpgradeState_CL Role_s=Agent | Measure Count() by  AgentPatchList_s
#Navigation Query
Type=OM16UpgradeState_CL Role_s=Agent

Additional Resources:

Log Analytics HTTP Data Collector API by Brian Wren
https://azure.microsoft.com/en-us/documentation/articles/log-analytics-data-collector-api/

HTTP Data Collector API: Send us data from space… or anywhere! by Evan Hissey
https://blogs.technet.microsoft.com/msoms/2016/08/30/http-data-collector-api-send-us-data-from-space-or-anywhere/

OMS View Designer: Visualize your data your way by Evan Hissey
https://blogs.technet.microsoft.com/msoms/2016/06/30/oms-view-designer-visualize-your-data-your-way/

 
Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

1. Configure a 3-state VBscript-based unit monitor and force the state changes to trigger alerts,
2. Configure a notification subscription scoped to the 3-state unit monitor from (1.) with a command notification channel to simulate a notification by writing the alert information to a text file whenever a new alert is generated by the 3-state monitor.

Step 1: To Configure the 3-state VBscript-based unit monitor:

Create a 3-state unit monitor using the Timed Script Three State Monitor type, target the RMS Emulator class and configure it to run at a 5 minute interval.

 


Paste the following VBscript in the Script field of the Script page and give a name like MyTestScript.vbs to the script in the File Name field:

'Returns: State = "Green"
'SCOM Parameter Name: Property[@Name='SetState']
'Healthy: Equals "Green"
'Warning: Equals "Yellow" 
'Critical: Equals "Red" 

    Dim oAPI, propertyBag
    Set oAPI = CreateObject("MOM.ScriptAPI")    
    Set propertyBag = oAPI.CreatePropertyBag()

Call propertyBag.AddValue ("SetState", "Green") 

Call oAPI.Return(propertyBag) 

Step 2: To Configure the notification subscription with command notification channel:

Follow the steps on How to Configure Command Notification in SCOM 2012 with PowerShell script by fesiro for the notification channel and subscriber:
 

 



Create a new notification subscription and scope it to the 3-state unit monitor, New(0) resolution state for it’s alerts and the command notification channel and subscriber created earlier:
 



 
Test Results:

1. On an OpsMgr 2012 R2 management group patched with only Update Rollup 7 (7.1.10226.1090), the test returned a NEGATIVE result as the issue still persist where the state changes in the 3-state unit monitor from Warning to Critical or Critical to Warning did not trigger a simulated notification by writing the alert information to the LogAlerts log file:
   
   
   
   
2. However, on an OpsMgr 2012 R2 management group patched with Update Rollup 11 (7.1.10226.1239), the test returned a POSITIVE result as every state change in the 3-state unit monitor from Warning to Critical or Critical to Warning triggered a simulated notification by writing the alert information to the LogAlerts log file:
   
   
   The severity of the alert generated by the 3-state unit monitor was also updated accordingly with every state change from Warning to Critical or Critical to Warning:
   
   
   Housekeeping: After completing the test, delete the management pack with the VBScript-based 3-state unit monitor and delete the notification subscription, channel and subscriber used for the test case.

The test results above showed that this long persisting issue is FINALLY fixed in Update Rollup 11 for OpsMgr 2012 R2. Well, better late than never! :-)

 

Additional Resources:

UR11 for SCOM 2012 R2 – Step by Step by Kevin Holman
https://blogs.technet.microsoft.com/kevinholman/2016/09/06/ur11-for-scom-2012-r2-step-by-step/

 
Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

The OMS Change Tracking Solution can be used to identify software and Windows Services changes and Linux daemon changes that occur in your environment and help pinpoint operational issues. Changes to installed software and Windows services on the monitored servers are read and then the data is sent to an OMS Workspace by the OMS Agent for processing. Logic is applied to the received data and the cloud service records the data of type ConfigurationChange. When changes are found, servers with changes are shown in the Change Tracking dashboard. Here is an example of an ConfigurationChange type record:
 

There are 2 types of fields for this record type:

• Type 1 Fields: Common fields:
  • SourceSystem
  • MG
  • id
  • Type
  • ManagementGroupName
• Type 2 Fields: Solution level fields:
  • TimeGenerated 
  • Computer
  • SourceComputerId
  • ConfigChangeType
  • ChangeCategory
  • SvcChangeType
  • SvcDisplayName
  • SvcName
  • SvcState
  • SvcPreviousState
  • SvcStartupType
  • SvcAccount
  • SvcPath
  • SoftwareType
  • SoftwareName
  • Previous
  • Current
  • Publisher
  • SvcPreviousStartupType
  • SvcPreviousPath

Lets name the Custom Log Type that we are creating to simulate the ConfigurationChange, record type as MyConfigurationChange.
Since the values for the Type 1 fields are automatically assigned to ALL records upon ingestion by the OMS Service, the sample records of type MyConfigurationChange will have most of these fields populated as well. Hence only the Type 2 fields and their corresponding sample values are required to be added into the JSON payload for MyConfigurationChange records to be injected into an OMS Workspace of interest.

Here is a sample PowerShell script that converts a CSV file with sample ConfigurationChange type data into JSON data and injecting it into an OMS Workspace with the Log Analytics HTTP Data Collector API in a JSON payload. The sample data will appear as records of type MyConfigurationChange_CL in the targeted OMS Workspace.


This PowerShell script consist of 4 main parts:

Part 1: Specify the key information for authentication, custom log type name and record time stamp.
Note: The MyTimeGenerated field holds the timestamp for the records in the CSV file and is assigned to $TimeStampField variable so that the records injected will have the same create time as their timestamp value in the MyTimeGenerated field once in the OMS Workspace.

# Replace with your Workspace ID
$CustomerId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
 
# Replace with your Primary Key
$SharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 
#Specify the name of the record type that we'll be creating.
$LogType = "MyConfigurationChange"
 
#Specify a time in the format YYYY-MM-DDThh:mm:ssZ to specify a created time for the records.
$TimeStampField = "MyTimeGenerated"

# Function to create the authorization signature.
Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
    $xHeaders = "x-ms-date:" + $date
    $stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" + $resource

    $bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
    $keyBytes = [Convert]::FromBase64String($sharedKey)

    $sha256 = New-Object System.Security.Cryptography.HMACSHA256
    $sha256.Key = $keyBytes
    $calculatedHash = $sha256.ComputeHash($bytesToHash)
    $encodedHash = [Convert]::ToBase64String($calculatedHash)
    $authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
    return $authorization
}

# Function to create and post the request
Function Post-OMSData($customerId, $sharedKey, $body, $logType) 
{
    $method = "POST"
    $contentType = "application/json"
    $resource = "/api/logs"
    $rfc1123date = [DateTime]::UtcNow.ToString("r")
    $contentLength = $body.Length
     $signature = Build-Signature `
        -customerId $customerId `
        -sharedKey $sharedKey `
        -date $rfc1123date `
        -contentLength $contentLength `
        -fileName $fileName `
        -method $method `
        -contentType $contentType `
        -resource $resource
    $uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"

    $headers = @{
        "Authorization" = $signature;
        "Log-Type" = $logType;
        "x-ms-date" = $rfc1123date;
        "time-generated-field" = $TimeStampField;
    }

    $response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
    return $response.StatusCode
}

$ConfigurationChangeData = Import-Csv -Path <<Path\SampleConfigurationChangeData.csv>> | select MyTimeGenerated,Computer,SourceComputerId,ConfigChangeType,ChangeCategory,SvcChangeType,SvcDisplayName,SvcName,SvcState,SvcPreviousState,SvcStartupType,SvcAccount,SvcPath,SoftwareType,SoftwareName,Previous,Current,Publisher,SvcPreviousStartupType,SvcPreviousPath

{
        "MyTimeGenerated": "2016-10-18T20:05:12.07Z",
        "Computer":  "MyComputer.contoso.com",
        "SourceComputerId":  "805ca53d-1a02-be85-e10c-4b4f32f2f2ac",
        "ConfigChangeType":  "WindowsServices",
        "ChangeCategory":  "Modified",
        "SvcChangeType":  "State",
        "SvcDisplayName":  "Microsoft Storage Spaces SMP",
        "SvcName":  "smphost",
        "SvcState":  "Running",
        "SvcPreviousState":  "Stopped",
        "SvcStartupType":  "Manual",
        "SvcAccount":  "NT AUTHORITY\\NetworkService",
        "SvcPath":  "C:\\Windows\\System32\\svchost.exe -k smphost",
        "SoftwareType":  "",
        "SoftwareName":  "",
        "Previous":  "",
        "Current":  "",
        "Publisher":  "",
        "SvcPreviousStartupType":  "",
        "SvcPreviousPath": ""
},

Part 4: Submit the data to the API endpoint.

ForEach($ConfigurationChangeSingleRecord in $ConfigurationChangeData)
{
  $ConfigurationChangeSingleRecordFixed = ConvertTo-Json -InputObject @($ConfigurationChangeSingleRecord) 
  # Submit the data to the API endpoint
Post-OMSData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($ConfigurationChangeSingleRecordFixed)) -logType $logType
}

##Configuration Changes Summary
#WindowsServices Chart Query
Type=MyConfigurationChange_CL ConfigChangeType_s="WindowsServices" | Measure count() by ConfigChangeType_s
#Software Chart Query
Type=MyConfigurationChange_CL ConfigChangeType_s="Software" | Measure count() by ConfigChangeType_s
#Other Configuration Changes (Files or Daemons) Chart Query
Type=MyConfigurationChange_CL ConfigChangeType_s!="Software" ConfigChangeType_s!="WindowsServices" | Measure count() by ConfigChangeType_s

##Changes by Condiguration Type
#Trend1 Query
Type=MyConfigurationChange_CL (ConfigChangeType_s=WindowsServices AND SvcChangeType_s!=State AND NOT (SvcName_s=BITS AND SvcChangeType_s=StartupType))
#Trend2 Query
Type=MyConfigurationChange_CL (ConfigChangeType_s=Software AND NOT (SoftwareName_s=*KB2461484* OR SoftwareName_s=*KB2267602*))
#List Query
Type=MyConfigurationChange_CL ((ConfigChangeType_s=WindowsServices AND SvcChangeType_s!=State AND NOT (SvcName_s=BITS AND SvcChangeType_s=StartupType)) OR (ConfigChangeType_s=Software AND NOT (SoftwareName_s=*KB2461484* OR SoftwareName_s=*KB2267602*)) OR (ConfigChangeType_s=Daemons AND (SvcChangeType_s=StartupType OR SvcChangeType_s=Path OR SvcChangeType_s=Runlevels)) OR ConfigChangeType_s=Files) | measure count() as Count by ConfigChangeType_s
#Navigation Query
Type=MyConfigurationChange_CL ((ConfigChangeType_s=WindowsServices AND SvcChangeType_s!=State AND NOT (SvcName_s=BITS AND SvcChangeType_s=StartupType)) OR (ConfigChangeType_s=Software AND NOT (SoftwareName_s=*KB2461484* OR SoftwareName_s=*KB2267602*)) OR (ConfigChangeType_s=Daemons AND (SvcChangeType_s=StartupType OR SvcChangeType_s=Path OR SvcChangeType_s=Runlevels)) OR ConfigChangeType_s=Files) | measure count() as Count by ConfigChangeType_s

##Total Application and Package Changes
#First Number Query
Type=MyConfigurationChange_CL ConfigChangeType_s="Software" SoftwareType_s="Application" | Measure count() by SoftwareName_s
#Second Number Query
Type=MyConfigurationChange_CL ConfigChangeType_s="Software" SoftwareType_s="Package" | Measure count() by SoftwareName_s
#List Query
Type=MyConfigurationChange_CL ConfigChangeType_s="Software" (SoftwareType_s="Package" OR SoftwareType_s="Application") | Measure count() by SoftwareType_s"

##Software, Windows Services, LINUX DAEMON Changes
#Donut Query
Type=MyConfigurationChange_CL (ConfigChangeType_s=Software AND NOT (SoftwareName_s=*KB2461484* OR SoftwareName_s=*KB2267602*)) | measure count() by ChangeCategory_s
Type=MyConfigurationChange_CL ConfigChangeType_s=WindowsServices SvcChangeType_s!=State And Not (SvcName_s=BITS And SvcChangeType_s=StartupType) | measure count() by SvcChangeType_s
Type=MyConfigurationChange_CL (ConfigChangeType_s=Daemons AND (SvcChangeType_s=StartupType OR SvcChangeType_s=Path OR SvcChangeType_s=Runlevels)) | measure count() by SvcChangeType_s
#List Query
Type=MyConfigurationChange_CL (ConfigChangeType_s=Software AND NOT (SoftwareName_s=*KB2461484* OR SoftwareName_s=*KB2267602*)) | measure count() as Count by Computer | top 500000
Type=MyConfigurationChange_CL ConfigChangeType_s=WindowsServices SvcChangeType_s!=State And Not (SvcName_s=BITS And SvcChangeType_s=StartupType) | measure count() as Count by Computer | top 500000
Type=MyConfigurationChange_CL (ConfigChangeType_s=Daemons AND (SvcChangeType_s=StartupType OR SvcChangeType_s=Path OR SvcChangeType_s=Runlevels)) | measure count() as Count by Computer | top 500000
#Navigation Query
Type=MyConfigurationChange_CL (ConfigChangeType_s=Software AND NOT (SoftwareName_s=*KB2461484* OR SoftwareName_s=*KB2267602*)) | measure count() as Count by Computer
Type=MyConfigurationChange_CL ConfigChangeType_s=WindowsServices SvcChangeType_s!=State And Not (SvcName_s=BITS And SvcChangeType_s=StartupType) | measure count() as Count by Computer 
Type=MyConfigurationChange_CL (ConfigChangeType_s=Daemons AND (SvcChangeType_s=StartupType OR SvcChangeType_s=Path OR SvcChangeType_s=Runlevels))

A shout out and word of thanks to my colleague Ben Shy (OMS PM) for helping me figure out how to allow the $TimeStampField variable to specify a timestamp field to use from a record’s data.





Additional Resources:

Log Analytics HTTP Data Collector API by Brian Wren
https://azure.microsoft.com/en-us/documentation/articles/log-analytics-data-collector-api/

HTTP Data Collector API: Send us data from space… or anywhere! by Evan Hissey
https://blogs.technet.microsoft.com/msoms/2016/08/30/http-data-collector-api-send-us-data-from-space-or-anywhere/

Change Tracking solution in Log Analytics by Bill Anderson
https://azure.microsoft.com/en-us/documentation/articles/log-analytics-change-tracking/

 
Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.

The management servers run on Windows Server 2012 R2 and the SQL Server version is SQL Server Enterprise Edition (64bit) 2014 (12.0.2000.8). All the virtual machines are running on a Hyper-V host.
For more information on the System Requirements for System Center 2016, go to
https://technet.microsoft.com/en-us/system-center-docs/system-requirements/system-requirements

Important Note:
When upgrading multiple management servers in a distributed management group, only start upgrade of additional management servers until AFTER SETUP ON THE FIRST MANAGEMENT SERVER COMPLETES. Failing to do so can result in database issues.

The Sample Upgrade Helper Management Pack can only be imported into a System Center 2012 R2 Operations Manager management group at UR3 and above. After importing the management pack, the initial upgrade state of this distributed management group shown on the Summary Dashboard was as follows:

 
Select any object in each state widget available in the Summary Dashboard and read the important notes specified in the Recommendations widget.

When the System Center 2016 Operations Manager installation media was run on the Management Server that is hosting the RMS emulator role, the upgrade wizard page listed the following existing features to be upgraded:

 

As the Operations Console was available on this Management Server, the Microsoft Report Viewer 2015 Runtime redistributable package (download here) and the Microsoft System CLR Type for Microsoft  SQL Server 2014 (download here) were required:


 


When all prerequisites were met, the credentials of the Configuration & Data Access Service account used in each of the management servers in this management group was applied to the fields in the Configuration page (the Local System Account was not used for these services in this management group):

After this, the upgrade was able to proceed with the default settings accepted for all other pages. Upgrade of the RMS Emulator and databases completed successfully as shown on the following Setup Complete page (the Retail License was not applied at that point):

 


The new upgrade state of the distributed management group shown on the Summary Dashboard was as follows:
– Notice that the upgrade state of the RMS Emulator is now in Healthy state, and that the overall upgrade state of the management group is still in Warning state with 33.33% core components upgraded at this stage. 

 


Next, running the upgrade wizard on the additional Management Server listed the following existing features to be upgraded,
– The Operational Database and the DW database were not listed as they were already upgraded earlier on from the RMS Emulator.

 

When all prerequisites were met and the credentials of the Configuration & Data Access Service account was provided, upgrade was able to proceed with the default settings accepted for all other pages.

Upgrade of the additional Management Server completed successfully as shown on the following Setup Complete page:

 


The new upgrade state of the distributed management group shown on the Summary Dashboard was as follows:
– Notice that the upgrade state of the additional management server – OMMS02.contoso.com, is now in Healthy state, and that the overall upgrade state of the management group is still in Warning state with 66.67% core components upgraded at this stage.




Next, the Gateway server was upgraded to 2016 by running the upgrade wizard on the Gateway Server and using the default settings:
 


The new upgrade state of the distributed management group shown on the Summary Dashboard was as follows:
– Notice that the upgrade state of the gateway server – DC.contoso.com, is now in Healthy state, and that the overall upgrade state of the management group is now in Healthy state with 100% core components upgraded successfully.

 


The database server with the reporting server role was then upgraded to 2016 as well using the default settings:

The last step involved upgrading the Windows agents to 2016 via:

1. the Pending Management view for remotely manageable agents, and
2. manually for manually installed agents

On the Agent Detail Dashboard of the Upgrade Helper, the Windows agents that are yet to be upgraded to 2016 showed a blue bar marker in the ToUpgrade column:

After approving the 3 remotely manageable agents in this distributed management group for agent update in the Pending Management view, their ToUpgrade column showed a “0” value on the Agent Detail Dashboard.

 




At this stage, the Summary Dashboard was showing that 75% of agents have been upgraded to 2016.





After manually upgrading the last agent in this distributed management group, the overall agent upgrade status was at 100% on the Summary Dashboard.
 

Additional Resources:

Resources & Tips About Upgrading To SCOM 2016 by Marnix Wolf
https://thoughtsonopsmgr.blogspot.com.au/2016/10/resources-tips-about-upgrading-to-scom.html

 
Disclaimer:
All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.