We're using management pack version 10.19.1123.0.
And we're using JBoss EAP 6.4.23.GA (AS 7.5.23.Final-redhat-00002)

And we're installing JBoss in domain mode, so this happens on host controllers.

The first thing we've discovered is that the vb script inside the MP uses a NET3.5 library. NET3.5 is default not installed on Windows Server 2019. The following is the dependency:

CreateObject("System.Collections.ArrayList")

After we install NET3.5 the script still fails now on the following error:

\Microsoft.JEE.JBoss.7.Discover.2019.vbs(1056, 1) Microsoft VBScript runtime error: Type mismatch: 'CInt'

Output is: JBoss EAP 6.4.23.GA (AS 7.5.23.Final-redhat-00002)

ElseIf CInt(Left(objConfigurationInfo.Version, 1)) >= 5 Then

The result is: the letter 'J' and not a number (7) and thus the equation fails. And thus the whole script fails.

So if anyone is able to get this information to the correct dev team, please!?

There appears to be a bug in the "DFS Namespaces Role Service Discovery (Windows Server 2016 and 1709+)" discovery within this MP. On every server it runs on in my environment I get error 4511 from source "HealthService" in the agent log:

"Initialization of a module of type "RegistrySyncProbe" (CLSID "{472364F2-A1F0-41C0-9A8F-E00C92C2AB31}") failed with error code The parameter is incorrect. causing the rule "Microsoft.Windows.FileServer.DFSN.10.0.RoleServiceDiscovery" running for instance "SOMESERVER.mydomain.com" with id:"{982B451D-958B-EC97-1FCE-E04CA6402B58}" in management group "MyCompany"."

I'm not the only one seeing this, there is a thread created in January about this:

https://social.technet.microsoft.com/Forums/en-US/fbc0ce74-ac57-4517-8704-ed6550e19aad/event-4511-healthservice-initialization-of-a-module-of-type-quotregistrysyncprobequot?forum=systemcenter

I'll be disabling this discovery in my environment until this gets resolved.

I was trying to manually add a WebLogic 12c application for monitoring in SCOM 2019 and was encountering the following error:

.\NewJEEAppServer.ps1 -ManagementServer MGMTSVR1 -Target https://app.site.domain.com:443 -JEEAppServerType WebLogic
WebClient call failed to server: https://app.site.domain.com:443
Unable to determine the application server type and version : https://app.site.domain.com:443

After trying the old management pack (v7.5.1038.0), this error did not appear and the application appeared to be successfully added, however no further discoveries take place. I assumed this was down to different versions of BeanSpy and the .ps1 scripts themselves, so reverted this and looked further into the new management pack scripts.

It appears that the "IsSupportedAppServer" function in JEEAppServerLibrary.ps1 does not have WebLogic 12c listed as a supported version, unlike the previous version of this management pack:

v10.19.1011.0:
function IsSupportedAppServer($serverType, $serverVersion)
{
$isSupported = $false;
if ($serverType.CompareTo("Tomcat") -eq 0)
{
if (($serverVersion -eq "5") -or
($serverVersion -eq "6") -or
($serverVersion -eq "7"))
{
$isSupported = $true
}
}
elseif ($serverType.CompareTo("JBoss") -eq 0)
{
if (($serverVersion -eq "4") -or
($serverVersion -eq "5") -or
($serverVersion -eq "6"))
{
$isSupported = $true
}
}
elseif ($serverType.CompareTo("WebSphere") -eq 0)
{
if (($serverVersion -eq "6") -or
($serverVersion -eq "7"))
{
$isSupported = $true
}
}
elseif ($serverType.CompareTo("WebLogic") -eq 0)
{
if (($serverVersion -eq "10") -or
($serverVersion -eq "11"))
{
$isSupported = $true
}
}
return $isSupported
}

v7.5.1038.0:
function IsSupportedAppServer($serverType, $serverVersion)
{
$isSupported = $false;
if ($serverType.CompareTo("Tomcat") -eq 0)
{
if (($serverVersion -eq "5") -or
($serverVersion -eq "6") -or
($serverVersion -eq "7") -or
($serverVersion -eq "8"))
{
$isSupported = $true
}
}
elseif ($serverType.CompareTo("JBoss") -eq 0)
{
if (($serverVersion -eq "4") -or
($serverVersion -eq "5") -or
($serverVersion -eq "6") -or
($serverVersion -eq "7") -or
($serverVersion -eq "8"))
{
$isSupported = $true
}
}
elseif ($serverType.CompareTo("WebSphere") -eq 0)
{
if (($serverVersion -eq "6") -or
($serverVersion -eq "7") -or
($serverVersion -eq "8"))
{
$isSupported = $true
}
}
elseif ($serverType.CompareTo("WebLogic") -eq 0)
{
if (($serverVersion -eq "10") -or
($serverVersion -eq "11") -or
($serverVersion -eq "12"))
{
$isSupported = $true
}
}
return $isSupported
}

It also appears that Tomcat 8, JBoss 8 and WebSphere 8 aren't listed as supported versions in the new management pack version of this script either.

Today I found in our weekly health check we have two DHCP servers that SCOM is collecting thousands of DHCP events from. The reason for the event spam is that they have a DHCP scope that has run out of addresses. These scopes are small, one is four addresses and one is five. The "DHCP Server 2016 and 1709+ IPV4 Individual Scope Addresses Available Percentage Monitor" monitor is enabled on these scopes with default thresholds, but remains in a healthy state. I have verified that the "DHCP.10.0.IndividualScopesProbe.ps1" runs successfully on the server, and returns a percentage free of "0" for these scopes, but the monitor never changes state.

Hi together,
again there is a bug in the Web Console, this time in SCOM 1801.

I installed SCOM 1801 Web Console using "Enable SSL" option. But if I browse on Internet Explorer, or Firefox, etc. https://<WEB CONSOLE>/OperationsManager gives the following error:
"The remote server returned an error: (404) Not found".

I could broswe the following pages without any problem:
https://<WEB CONSOLE>/Dashboard
https://<WEB CONSOLE>/AppAdvisor
https://<WEB CONSOLE>/AppDiagnostics

I figured out the issue

If I install SCOM Web Console without "Enable SSL", then the access to Web Console works.

SCOM Web COnsole installation process with "Enable SSL" does not set in IIS "SSL required" option, and does not set any Web Console registry parameter value automatically. I could reproduce this behaviour many times.

WORKAROUND

1) Set "SSL Reuired" manuals in IIS:
After the installaion of Web Console with "Enable SSL" set following:
"Default Web Site > SSL Settings", and enable "SSL required"

2) Set Registry parameter values manually:
"HKLM\SOFTWARE\Microsoft\System Center Operations Manager\Setup\Web Console"
BINDINGCONFIGURATION: DefaultHttpsBinding
HTTPGET_ENABLED: false

That is definetly a bug in the installation process of SCOM 1801 Web Console. This instasllion BUG must be fixed by SCOM developer team.

Discussion link about this problem:
https://social.technet.microsoft.com/Forums/en-US/aa088cb8-f3c0-4486-ac9a-26a78a7277fe/scom-1801-web-console-installation-issue?forum=operationsmanagerdeployment

Best Regards
Birdal

It’s a well-known problem that MPs are way too noisy and that customers spend most of their time tuning the damn things. All that noise also means that the first thing ordinary SCOM users get is bombarded with emails / noise, which causes those users to disengage from using SCOM right from the very outset.

In terms of best practices, it is customers who operate and run these MPs at scale and who therefore have the real-world knowledge of what's needed from the MPs when running them in Production, much more so than disconnected development teams.

Right now, there's no good way of customers sharing their best practices on tuning MPs with one another and so we’re all doing the same work over and over again, trying to get them fit for purpose for our environments.

I can appreciate – and I’m sure other customers can too – that this is a big problem for you guys to tackle and that there isn’t an easy fix for this for you.

That’s why I think you should do something bold and open source your MPs.

The new Microsoft is supposed to love open source and community but we don’t see a lot of that from Microsoft in the world of SCOM.

What better way of showing that, for SCOM, Microsoft isn't stuck in dead old ways of thinking and understands how the world has changed and can respond to that in an agile and effective way?

That way, customers could effectively collaborate on making these MPs much more useable in the real-world.

It might also encourage companies who've developed their own custom MPs internally to also share / open source them, again, saving everyone massive amounts of repeated work.

As far as I’m aware, all of the MPs’ content and structures are all available publicly on (some admittedly slightly dodgy?) websites anyway, and so it's not like the IP in them isn’t pretty exposed already.