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!

ISSUE:

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

IIS/SCOM BUG:

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".

SOLUTION

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.

NOW...

MICROSOFT developer team should fix in deployment this, please.

The Technet frum link about my solution is:
https://social.technet.microsoft.com/Forums/en-US/68b6ee3b-ba7c-4dcd-8020-7300db43663e/bug-in-microsoft-scom-2016-web-console-500-internal-server-error-solved-?forum=operationsmanagerdeployment

Best Regards

Birdal

15 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Birdal shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Birdal commented  ·   ·  Flag as inappropriate

        Hi,

        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

      • Birdal commented  ·   ·  Flag as inappropriate

        Hi,
        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
        Birdal

      • 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