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"
BINDING_CONFIGURATION: DefaultHttpsBinding
HTTP_GET_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.

Currently the linux agent is distributed using a management pack that implements a huge script that installs the agent.
This script violates almost every (if not all) best practise for linux distributions to packaging and installing software on linux.
This makes maintaining the package a huge task that is very prone to errors.
Using the distributions best practises to package and install software will make this a lot easier for you.
- less errors
- it will save you time.
- support will be easier
- less complex
- most off your work has already been done for you
- profit from updates and improvements done by others for free
- the community will start working for you when you use their methods
- distribution updates are less likely to break your package
- you can profit from all the improvements the distribution makes
- respecting the distributions best practises will earn you kudo's from the distributions community

We deployed the latest version of the Management Pack Microsoft Dynamics AX 2012, and now we noticed while executing 'Reject New Client Sessions Monitor' from 'Microsoft Dynamics AX 2012 Application Object Server Task' users are not getting notified that the administrator is going to shut down the application. The same as available in Dynamics application Console.

Microsoft Dynamics AX 2012 (V 6.3.158.0)
Microsoft Dynamics AX 2012 Application Object Server Task

Task Name: - Reject New Client Sessions Monitor

Task Description:-

Prevent Microsoft Dynamics AX Clients from Connecting to the application object server (AOS)

Additional requirement :-

Notify the users who are connected to the Dynamics application when the Reject New Client Sessions Monitor task is executed.