SCOM 2012 - SharePoint WebPart shows only a blank page in a SharePoint 2013 HTTPS environment

  • Makale

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

I ran into an interesting case with a client that I think deserves a post.   The scenario is as follows:

The client was attempting to get the SharePoint webpart to connect to their SCOM 2012 web console and the results were blank.  In this particular case, both the SharePoint server and the SCOM server were setup to use HTTPS.  This is required as Silverlight cannot switch back and forth between HTTP and HTTPS.  We started by confirming their setup.  There are two pieces to this setup.  The first is to make sure the SCOM web-console renders HTTPS properly.  Once that works, you can configure SharePoint using the process described in this article.  Their setup followed all of these procedures, yet when you launched a SharePoint site with the WebPart configured, the results were blank.  After doing some additional checking, we noticed the following in the IIS logs:

2015-04-01 17:20:36 <IP_ADDRESS> GET / - 80 - <IP_ADDRESS>- - 403 4 5 0

Based on that information, we see that the connection to the SCOM server is coming across port 80, and that we are getting a 403 error in response.  The SCOM console was set to require HTTPS, so the response is what you would expect with a port 80 connection.  Also of interest, using the service account configured in SharePoint, we could successfully load the SCOM console using HTTPS (note, you need to install Silverlight on the front ends to test this).

As it turns out, in this particular case, the problem was with IE security settings.  Due to the security requirements of the environment, we were using an FQDN for the SCOM web console.  This means that IE was treating this request as if it was going to an internet site even though the site itself was internal, and by default, it will not pass credentials of the service account.  The reason for this is that even though certificates are in place, IE does not view this site as a trusted site.  There are two possible ways to address this:

1)  Create a certificate mapped to the short name.  As long as default configuration is in place, IE will view this site as a local intranet site and trust it implicitly (thus passing the credentials)

2)  Sign on to each SharePoint web front end with the service account used to connect to SCOM and add this site to the trusted local intranet sites.  This tells IE that it is OK to pass credentials to this site.

image

We opted in this case for the second option.  On doing so, the webpart began to display data from the dashboards we selected.  In this particular case, we were using SharePoint 2013, though I suspect the issue would still exist in SharePoint 2010.

Comments

  • Anonymous
    January 01, 2003
    Useful article. Thank you.
  • Anonymous
    January 01, 2003
    Thank you for the comments.
  • Anonymous
    April 16, 2015
    Information was good, I like your post.

    http://staygreenacademy.com/>SharePoint Developer Training
  • Anonymous
    April 16, 2015
    Information was good, I like your post.

    http://staygreenacademy.com/