I suggest you ...

BUG in Microsoft SCOM 2016 Web Console: "500 - Internal Server Error" !!!! SOLVED !!!!

Dear Microsoft IIS/SCOM Developer Team,

we have a absolutely new SCOM 2016 infrastructure and had had until today issue with the SCOM 2016 Web Console.

I created related to "500 - Internal server error" some forum questions. Also I read the similar 500 error on other discusiions in Technet forums.

Finally I found the BUG in SCOM 2016 Web Console!

I will list the bug in IIS/SCOM and my solution, and also want that MICROSOFT should make a statement to this issue!


If any user try to access to SCOM 2016 Web Console, "500 - Internal server error" will be displayed.


1) Applicaton Pools are set not correctly in the sites "MonitoringView" and "OperationsManager"

- the site "MonitoringSite" has as application pool "OperationsManager".

- the site "OperationsManager" ahs as application pool "OperationsManagerMonitoringView".


Logically, these applications pools must be set contrary.

- I changed both sites to the correct application pools.

- Make iisreset (better start the Web Console server)

BINGO! It works....

NOTICE: We did never changed in the deployment or afterwards the applications pools!

But how about with "physical path"?

I checked both physical paths of the sites "MonitoringView" and "OperationsManager". It is very strange. The site "MonitoringView" uses "C:\Program Files\Microsoft System Center 2016\Operations Manager\WebConsole\WebHost", and the site "OperationsManager" uses "C:\Program Files\Microsoft System Center 2016\Operations Manager\WebConsole\MonitoringView".

I expect here also contrary settings. But NO! If I change the settings contrary, the Internet browser prompt the following:

If this configured,

But, the Web Console does not work and give the following error:

"This view cannot be displayed because this computer is not configured for the Operations Manager web console. refresh the browser to configure"

OK.... I set the physical path again back! In my opinion, "physical path" is also a bug which Microsoft developer should try to fix.


MICROSOFT developer team should fix in deployment this, please.

The Technet frum link about my solution is:

Best Regards


48 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Birdal shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Andresp commented  ·   ·  Flag as inappropriate

    I do have same problem (on 2016 UR4) - several IP's on server and SSL bound on specific IP. Resolved when allowed all IPs.

  • Craig Wilson commented  ·   ·  Flag as inappropriate

    Similar issue for me in 1801 Web Console, When trying to login I got an "Underlying Connection was closed" error.

    To cut a long story short, this only happened across HTTPS, and after much hair pulling and console re-installs, the problem was found to be the IIS binding..

    Specifically, I had an IP bound to port 443, but as soon as I bound it to all IPs it started working on HTTPS

    So instead of <server-ip-address>:443
    I changed it to *:443

    Weird, but it works!

  • Birdal commented  ·   ·  Flag as inappropriate


    the other important thing is the access of operators on SCOM Operations Console.
    Please check, if the user account has enough access permission under "ADMINISTRATION > Security > User Roles".

    Best Regards

  • Birdal commented  ·   ·  Flag as inappropriate

    the one of the main problem for 500 error is the mismatch of ApplicatonPooly in IIS. For example, if you install UR4, this installation set ApplicationPools again not correctly. We hvae to change them again manually. Then it worked again.
    Best Regards

  • CloudInMyHead commented  ·   ·  Flag as inappropriate

    What about all these others steps you took. Do we need to change all of those too?
    1) all SPNs are registered definetly correct. Delegation for the SDK-Account, etc. in AD correct.
    2) Kerberos authentication
    3) IIS authentication is as recomended:
    - VirtualSite "OperationsManager" > Authentication > Windows Authentication is enabled.
    - Provider (Negotiate first, then NTLM)
    - "Enable Kernel-mode authentication" is OFF
    - The same settings above also for the VirtualSite "MonitoringView"
    4) Application Pools
    - .NET CLR Version is v4.0 for both "OperationsManagerAppMonitoring" and "OperationsManagerMonitoringView". It did not help to switch Version 2.0. It did not help also to switch the "Managed Pipeline Mode" from "Integrated" to "Classic".
    5) There is no problem on the Web Console Server to access the SCOM Web Console.
    6) On the client site, in Internet EXplorer, the Web Console Server is trusted server in the local intranet. Kerberos authentication is enabled, etc..

Feedback and Knowledge Base