Gather Log Analytics/MMA agent version

Had some questions come up from the community to check the Log Analytics agent version.

Depending on how you are setup, the SCOM Integration makes this easy with Holman’s blog for the agent management pack.

If you have admin right in Operations Manager console then you can check this directly from SCOM server:

If you are an admin in SCOM, you can check from MS

$Server = “DC01.yourlabnamehere.net”
(Get-SCOMAgent -Name $ServerName).Version

Alternatively, from server registry:

(Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\setup”)

# Just the Agent version variable

(Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\setup”).AgentVersion

Log Analytics

Kusto query

// Servers and Versions

Heartbeat
| project Computer,Version

// Specific version

Heartbeat
| where Version == “8.0.10918.0”
| project Computer,Version

// Summarize by Version

Heartbeat
| summarize by Version

If you’re visual

From the Portal > Log Analytics > workspace > Workspace Summary > Agent Health

Scroll right to agent version

Monitor

Monitor > Overview > Agent Health Assessment

Scroll right to agent version

Azure Log Analytics for Windows Telemetry data

 

 

I blogged about this last year here

 

 

As best practice, the Upgrade Analytics script checks for far more than just injecting the workspace key and telemetry value.

 

 

FYI – This could also be managed in an SCCM Compliance setting.

Paul Fitzgerald – Platform PFE blogged about a non SCCM method here

 

 

Assess requirements for environment:

 

Barebones configuration requires Commercial ID, allow telemetry, and level of telemetry data to send

Optional – Create key for IEDataOptIn

Send data to Application Insights

Customer proxy setup

 

 

Script has 11 parameters specified, not all are needed (excerpt below from script)

Param(
# run mode (Deployment or Pilot)
[Parameter(Mandatory=$true, Position=1)]
[string]$runMode,

# File share to store logs
[Parameter(Mandatory=$true, Position=2)]
[string]$logPath,

# Commercial ID provided to you
[Parameter(Mandatory=$true, Position=3)]
[string]$commercialIDValue,

# logMode == 0 log to console only
# logMode == 1 log to file and console
# logMode == 2 log to file only
[Parameter(Mandatory=$true, Position=4)]
[string]$logMode,

#To enable IE data, set AllowIEData=IEDataOptIn and set IEOptInLevel
[Parameter(Position=5)]
[string]$AllowIEData,

#IEOptInLevel = 0 Internet Explorer data collection is disabled
#IEOptInLevel = 1 Data collection is enabled for sites in the Local intranet + Trusted sites + Machine local zones
#IEOptInLevel = 2 Data collection is enabled for sites in the Internet + Restricted sites zones
#IEOptInLevel = 3 Data collection is enabled for all sites
[Parameter(Position=6)]
[string]$IEOptInLevel,

[Parameter(Position=7)]
[string]$AppInsightsOptIn,

[Parameter(Position=8)]
[string]$NoOfAppraiserRetries = 30,

[Parameter(Position=9)]
[string]$ClientProxy = “Direct”,

[Parameter(Position=10)]
[int]$HKCUProxyEnable,

[Parameter(Position=11)]
[string]$HKCUProxyServer

 

 

 

Simple method to update machines to send Windows telemetry data:

 

 

PowerShell script

From PowerShell as Administrator

Set-Location HKLM:

 

$registryPath = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies”

$Name = “DataCollection”

$Name2 = “AllowTelemetry”

$CommercialID = “00000000-0000-0000-0000-000000000000”

$value = “2”  # Values from 0-3 accepted

$vIEDataOptInPath = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection”

$IEOptInLevel = “2”  # Values from 0-3 accepted

 

If ( (Test-Path $registryPath\$Name) ) { write-host -f green “Registry keys already exist” }

If ( ! (Test-Path $registryPath\$Name) )

{

New-ItemProperty -Path $registryPath -Name $name

New-ItemProperty -Path $registryPath -Name $CommercialID

New-ItemProperty -Path $vIEDataOptInPath -Name IEDataOptIn -Type DWord -Value $IEOptInLevel

New-ItemProperty -Path $registryPath\$Name -Name $name2 -Value $value `

    -PropertyType DWORD -Force | Out-Null

Write-host -f green “Registry keys added for Telemetry”

}

 

 

 

 

References

Configure telemetry

Get Started link

Win 7,8 Opt in link

Scripting SCOM Registry key tweaks

 

Time to tune!

 

 

Had some requests to script the registry tweaks for SCOM

 

Starting off with Holman’s blog entry …

 

TechNet Gallery download here

 

Save .txt file as .ps1

 

On SCOM Management server(s)

Close out any SCOM Console session (to prevent SDK errors)

Run as administrator in PowerShell window

Restart SCOM services

restart-service omsdk; restart-service healthservice; restart-service chost

Verify services running

get-service omsdk; get-service healthservice; get-service chost

Workflow Manager Addendum MP for SQL Aliases

 

A SQL Alias is kinda like wearing disguise glasses…

 

From a security perspective, you can make things difficult for attackers by specifying a SQL alias and different port for SQL.

 

 

 

Symptom – discovery fails for WFM pack

 

Trying to monitor and figure out what the real database name, instance, etc. can be a challenge.

A couple of years ago, I was able to find an example for one customer where the registry key shed light on the alias.

 

The workflow manager management pack has a DataSourceModuleType “Microsoft.WorkflowManager.Addendum.v1.WFCommandExecuterDataSource”, where this change successfully retrieved the sql server name.

This datasource uses the PowerShell script (WorkflowPSDiscovery.ps1)

 

This function was changed in one example

# Get computer name from splitted dataSource
function GetPrincipalName {
param(
$ADDomain,
$ss
)

#$ssWithoutPort = $ss[0].split(‘,’)
#if (-not $ssWithoutPort[0].Contains(‘.’))
#{
# $ssWithoutPort[0] = $ssWithoutPort[0] + “.” + $ADDomain.Name
#}
#$principalName = $ssWithoutPort[0]

$key = ‘HKLM:\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo’
$sqlfromalias = (Get-ItemProperty -Path $key -Name $ss).$ss
$sqlserverstr = $sqlfromalias.Split(‘,’)
$sqlserver = $sqlserverstr[1]
$principalName = $sqlserver

return $principalName
}

 

 

Ran into this discovery issue a second time, and the function didn’t solve the failure.

Real quick – a shout out and my thanks to Chuck Hughes and Mike Sadoff, for their time and testing this more robust discovery method.

 

 

 

Added logic to fix the assumed InstanceName ($instname) – Most likely why my first function worked (configuration had default SQL instance name of MSSQLSERVER )

Added GetSqlAlias function to help decode the disguise

 

 

Gallery download here

 

Don’t forget to override the original workflow manager discovery!

Microsoft.WorkflowManager.v1.Addendum.WFPSDiscovery

Test fire any event on any server from any application

Golden Oldies – always popular (tools vs music)

Old Holman blog that’s still relevant, even more powerful than EventLog Explorer

Basically anyone who wants to test fire events off a SCOM MP should use this tool.

Event Create, write-eventlog all have limitations (certain event sources that can be used to create events, or event ID number limitations)

First, download the 2007 R2 Admin ResKit here

MomTeam blog reference

Double click the downloaded MSI

I prefer to move extracted files under my SCOM tools/Management pack directory structure under MonAdmin (Monitoring Admin)

Copy extracted files to gold depot

Move to gold depot – SCOM \ tools \ <toolname here>

Go into the MPEventAnalyzer directory

Run the exe

MP Event Analyzer

Click on Investigate Event Sources Tab (bottom middle)

Don’t forget you can use the search bar (where I typed apm)

For my example, double click on APM Agent

Search Events on right hand pane

Check checkbox to select the 1319 APM event for configuration error (right hand pane)

Click the ‘Add selected events to execution list’

Once event verified in bottom box, click the green box to fire selected event(s)

Verify event in Event Viewer

Validate Management Pack

Stay tuned… this did not complete the validation process.

Re-learn an old but still relevant tool – EventLog Explorer

 

Sometimes we forget about tools that can make things easier.

 

Time to talk about EventLog Explorer.

 

Need to repro and test events for an installed program, to see what SCOM will handle?

Read this old mom team blog, courtesy of Kevin Holman blog

 

 

I wanted to try it to test fire some events, had a use case where we needed to test Skype events from the SCOM MP

 

Testing on my SCOM 2016 Management server

 

Download file, run EventLog Explorer

The Paste icon next to the X is ‘Add to Execution List’ and fills out the bottom pane

The Green Arrow is ‘go’ or execute (similar to PowerShell ISE)

 

Navigate through the Event Log and Event Source on the left hand pane

Mark events with the checkbox  

 

Add to Execution

 

Verify events added to bottom pane

(see my test yesterday for fired, and not fired events from today)

 

 

 

Click Green box with white arrow to fire events, and check Event Viewer

 

 

Yesterday’s test

 

 

 

Today’s test

 

 

Verify alerting occurred as expected!

Adding Management Solutions in Azure

Decoder ring applies!

 

OMS is Log Analytics is Azure Management Solutions.

 

 

 

Do you want to add solutions to your Azure subscription?

Pre-packaged visuals and insights on your data, whether azure or hybrid.

 

 

 

Adding Management Solutions

Login to the Azure Portal

Click on All Services

Type ‘solutions’, hit enter

Click star icon to favorite Solutions

 

 

Drag Solutions higher in your preferences (wasn’t in above screenshot)

 

 

Click Solutions

 

 

 

 

Click + to Add

Click on Security and Compliance

 

 

Click Create

 

 

Don’t forget solutions require MMA agents connected to a workspace to render any data/insights!

 

 

 

 

References

The Docs article lists how to use the management solutions

 

MMA Agent and SCOM Agent version numbers


 

FYI – Updated 17 July 2020

 

This idea sprung from a discussion with Sr. PFE Brian Barrington, and it got me wondering…

 

FYI – If you’re running a SCOM agent, 2016 or above, various Log Analytics solutions may have pre-reqs.

 

OMS Gateway requires Microsoft Monitoring Agent (MMA)

(agent version – 8.0.10900.0 or later)

Simple English, that means SCOM2016 RTM agent or above

 

 

 

As of 6 Sep 18, MMA agent = 8.0.11103.0

As of 17 Oct 18, MMA agent = 8.0.11136.0

Skipping forward to 2020, the MMA agent is 10.20.18040.0

 

 

Windows SCOM Agent Version numbers 

SCOM2016 
RTM 8.0.10918.0
UR1 8.0.10931.0
UR2 8.0.10949.0
UR3 8.0.10970.0
UR4 8.0.10977.0
UR5 8.0.10990.0
UR6 8.0.11004.0
UR7 8.0.11025.0
UR8 8.0.11037.0
UR9 8.0.11049.0
SCOM1801
RTM 8.0.13053.0
SCOM1807
RTM 8.0.13067.0
SCOM 2019 
Technical Preview 10.19.10003.0
RTM 10.19.10014.0
UR1 10.19.10140.0

 

  • @Larry LeBlanc – thank you for the SCOM Agent version updates!

 

Verify what version is installed

Via SCOM – use Holman’s Agent Version Addendum management pack

 

If you don’t have SCOM

From PowerShell

$Agent = get-itemproperty -path “HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup”

$Agent.CurrentVersion

 

 

 

 

 

 

Resources

SCOM Agent Version Addendum pack https://kevinholman.com/2017/02/26/scom-agent-version-addendum-management-pack/

SCOM Agent build numbers https://social.technet.microsoft.com/wiki/contents/articles/34312.system-center-operation-manager-momscom-list-of-build-numbers.aspx

Linux Agent can be downloaded from GitHub – github.com/Microsoft/OMS-Agent-for-Linux

 

If more information is needed for build number –

System Center Operations Manager 2019

Build Number KB Release Date Description
10.19.10050.0 Evaluate March 2019 SCOM 2019 RTM
10.19.10311.0 KB4533415 February 2020 SCOM 2019 Update Rollup 1

System Center Operations Manager 2016

Build Number KB Release Date Description
7.2.11719.0 Evaluate September 2016 SCOM 2016 RTM
7.2.11759.0 KB3190029 October 2016 SCOM 2016 Update Rollup 1
7.2.11822.0 KB3209591 February 2017 SCOM 2016 Update Rollup 2
7.2.11878.0 KB4016126 May 2017 SCOM 2016 Update Rollup 3
7.2.11938.0 KB4024941 October 2017 SCOM 2016 Update Rollup 4
7.2.12016.0 KB4090987 April 2018 SCOM 2016 Update Rollup 5
7.2.12066.0 KB4459897 October 2018 SCOM 2016 Update Rollup 6
7.2.12150.0 KB4492182 April 2019 SCOM 2016 Update Rollup 7
7.2.12213.0 KB4514877 October 2019 SCOM 2016 Update Rollup 8

Installing and configuring the MMA agent via PowerShell

 

GUI install option, see blog

 

 

Pre-reqs to build out an install script/package

MMA agent executable

Workspace ID

Workspace Primary Key

 

 

Download MMA agent

Click on Windows Servers from Connected Sources to download Windows Agent

Click on Linux Servers from Connected Sources to download Linux Agent

 

 

 

 

Obtain WorkspaceID

From the Azure Portal (https://portal.azure.com)

Click on Log Analytics, <your subscription >

Click on Advanced Settings

My view defaulted to Connected Sources > Windows Servers

 

Save the workspace ID and workspace key to notepad/OneNote for later

 

 

 

 

 

Build out command line for setup file

(optionally to include in Application Deployment package)

 

Grab pre-reqs above: (saved from above to build the command line)

Exe/msi file

Workspace ID

Workspace key

 

The setup.exe or MSI command line parameters to pass are:

MMA-specific options Notes
NOAPM=1 Optional parameter. Installs the agent without .NET Application Performance Monitoring.
ADD_OPINSIGHTS_WORKSPACE 1 = Configure the agent to report to a workspace
OPINSIGHTS_WORKSPACE_ID Workspace Id (guid) for the workspace to add
OPINSIGHTS_WORKSPACE_KEY Workspace key used to initially authenticate with the workspace
OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE Specify the cloud environment where the workspace is located

0 = Azure commercial cloud (default)

1 = Azure Government

OPINSIGHTS_PROXY_URL URI for the proxy to use
OPINSIGHTS_PROXY_USERNAME Username to access an authenticated proxy
OPINSIGHTS_PROXY_PASSWORD Password to access an authenticated proxy

Example:

setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID=<your workspace id> OPINSIGHTS_WORKSPACE_KEY=<your workspace key> AcceptEndUserLicenseAgreement=1

 

 

 

Other helpful links

Docs site https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-quick-collect-windows-computer

Daniel Orneling Blog https://blog.orneling.se/2017/01/installing-oms-agent-with-powershell/

TechNet gallery https://gallery.technet.microsoft.com/scriptcenter/Install-OMS-Agent-with-2c9c99ab

Service Map SCOM pack configuration errors

Look for 6400 Event ID’s in the Operations Manager log on the management server if you do not have the correct information

 

Event ID 6400 in Operations Manager log helps show what’s missing with Azure AD error events

 

Follow steps outlined in the ‘Set up Azure Service Principal’ blog here

 

 

Sample 6400 event

 

Message: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: AADSTS90002: Tenant XXXXXXXXX not found.

This may happen if there are no active subscriptions for the tenant. Check with your subscription administrator.

Trace ID: 89abf27f-4884-4191-b577-de2fce100600

Correlation ID: c8a2470e-2383-4325-b91f-86b5e20ade57

Timestamp: 2018-08-06 20:34:49Z —> System.Net.WebException: The remote server returned an error: (400) Bad Request.

at System.Net.HttpWebRequest.GetResponse()

at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpHelper.<SendPostRequestAndDeserializeJsonResponseAsync>d__0`1.MoveNext()

— End of inner exception stack trace —

at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.RunAsyncTask[T](Task`1 task)

at Microsoft.SystemCenter.ServiceMap.REST.Credentials.AdCredentials.GetToken()

at Microsoft.SystemCenter.ServiceMap.UI.SubscriptionData.TestConnection()

ErrorCode: invalid_request

StatusCode: 400

 

Inner Exception

Message: The remote server returned an error: (400) Bad Request.

Response URI: https://login.windows.net/XXXXXXXXX/oauth2/token

Headers:

Pragma: no-cache

Strict-Transport-Security: max-age=31536000; includeSubDomains

X-Content-Type-Options: nosniff

client-request-id: c8a2470e-2383-4325-b91f-86b5e20ade57

x-ms-request-id: 89abf27f-4884-4191-b577-de2fce100600

x-ms-clitelem: 1,90002,0,,

Cache-Control: no-cache, no-store

Content-Type: application/json; charset=utf-8

Expires: -1

P3P: CP=”DSP CUR OTPi IND OTRi ONL FIN”

Set-Cookie: esctx=AQABAAAAAADXzZ3ifr-GRbDT45zNSEFEzFrPhp_xcoXIlYw2iOqAFXkz7NO-Hm1hJdVAn6298A0ylDD5VvX2VosFiRVxTDzmRz24sbVUbhiTuyHJsmeIkR47y1MU3SafDlFp6xPo91BwZhRqoDPtP6YTBi5D6mHGqy2lkSAEVQtg9D4lsWTmKipm9iLaB2twBZcYR0VkDhIgAA; domain=.login.windows.net; path=/; secure; HttpOnly,x-ms-gateway-slice=004; path=/; secure; HttpOnly,stsservicecookie=ests; path=/; secure; HttpOnly

Server: Microsoft-IIS/10.0

Date: Mon, 06 Aug 2018 20:34:48 GMT

Content-Length: 508