SCOM 2025 UR1 inplace upgrade - Web Interface Views display 500 - Internal Error

Yeater, Doug (CCI-Northeast) 0 Reputation points
2026-02-18T19:27:09.66+00:00

Completed a successful in-place upgrade to SCOM 2025 UR1 from SCOM 2022 UR2 and now getting an 500 Internal Error on some of the view in the Web Console. Followed Kevin Holman's pre & post upgrade tasks.

System Center Operations Manager
System Center Operations Manager

A family of System Center products that provide infrastructure monitoring, help ensure the predictable performance and availability of vital applications, and offer comprehensive monitoring for datacenters and cloud, both private and public.

0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-02-18T19:27:20.5733333+00:00

    If you are encountering a 500 Internal Server Error on some views in the Web Console after an in-place upgrade to SCOM 2025 UR1, there are several steps you can take to troubleshoot and resolve the issue:

    1. Check SPNs: Ensure that the Service Principal Names (SPNs) for both the SDK and HTTP are correctly registered. This is crucial for Kerberos authentication, which is often a cause of 500 errors.
      • For the SDK SPNs, you can register them using commands like: 
             Setspn.exe -S MSOMSdkSvc/SCOMMS SCOMMS
     Setspn.exe -S MSOMSdkSvc/SCOMMS.Lab.Local SCOMMS
      • For HTTP SPNs, you can register them similarly: 
             Setspn.exe -S HTTP/mySCOM SCOMWeb
     Setspn.exe -S HTTP/mySCOM.Lab.Local SCOMWeb
    2. Verify SPNs: After registering, verify that the SPNs are correctly set up by running: 
         Setspn.exe -L SCOMMS
   Setspn.exe -L SCOMWeb
    3. Configure Delegation: Make sure that the delegation settings are correctly configured in Active Directory for the accounts used by the SDK and the Web Console.
    4. Check Authentication Settings: Ensure that Kernel-mode authentication is disabled for both the MonitoringView and OperationsManager in IIS. This can be done by navigating to the respective sites in IIS Manager and adjusting the authentication settings.
    5. Review Logs: Check the event logs on the server hosting the Web Console for any additional error messages that could provide more context on the 500 Internal Server Error.

    By following these steps, you should be able to identify and resolve the cause of the 500 Internal Server Error in your SCOM Web Console after the upgrade.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. SChalakov 10,861 Reputation points MVP Volunteer Moderator
    2026-03-09T09:22:15.17+00:00

    Hi Doug,

    I would start by looking at this as an IIS / web tier issue first, especially if the upgrade completed successfully and only some views in the Web Console now return 500 Internal Server Error.

    A few generic checks I would do:

    • Check the IIS logs for the exact failing /OperationsManager request and note the HTTP substatus. A plain 500 is too generic.

    Enable Failed Request Tracing (FREB) for status 500 so you can see where the request is failing in the IIS pipeline.

    Then I would verify the basic IIS pieces:

    Make sure the OperationsManager site / application is started.

    Recycle the related application pool.

    Check Application, System, WAS, W3SVC-WP, and .NET Runtime events around the failure time. IIS app pool recycle and worker-process issues can easily surface as 500 errors after an upgrade.

    For SCOM specifically, I would also re-check the IIS prerequisites after the upgrade:

    Confirm ASP.NET v4.8 is present and allowed under ISAPI and CGI Restrictions. Microsoft still calls that out for SCOM 2022 and later Web Console deployments.

    Authentication is another area worth checking:

    Review the IIS authentication settings for the Web Console.

    If the issue only happens remotely or only with Windows Authentication, I would validate SPNs, delegation, and whether kernel-mode authentication or account settings changed during/after the upgrade.

    Also worth checking:

    Compare the current web.config with any pre-upgrade customizations.

    If there were old manual tweaks in the Web Console config, the upgrade may have exposed them or left something inconsistent. A repair can also reset manual changes, so keep that in mind before making further edits.

    My first pass would be:

    Recycle the Web Console app pool

    Check IIS logs for the exact failing request

    Enable FREB for 500

    Verify ASP.NET 4.8 / ISAPI restriction settings

    Review authentication / SPN / delegation only if the pattern points there

    That usually narrows it down fairly quickly.

    Best Regards

    Stoyan Chalakov

    "If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.