locked
"Failed to retrieve site state" for IIS sites lacking HTTP bindings RRS feed

  • Question

  • Using the Windows Server 2008 Internet Information Services 7 management pack 6.0.7600.0, we've been getting what appear to be false-positive (buggy?) alerts on all of our IIS machines.

    On our servers we have a single site used to host our WCF services - on this site we have WAS/WCF bindings for net.tcp, net.pipe, net.msmq, and msmq.formatname - but NO bindings for HTTP or HTTPS. Consistently, the IIS7 management pack reports an error for all of these sites:

    Failed to Retrieve site state
    Event Description: Failed to retrieve the state of the following site: 'Default Web Site'. The operation will be retried.
    HRESULT: 0x800710d8
    Details: The object identifier does not represent a valid object.

    I'm not sure how to proceed. I've been trying to override it, but it appears I can only disable the alert for all sites on a server, not just for a specific site. I'd rather not change our configuration and add a 'fake' HTTP binding if I can avoid it - does anyone have any other ideas?

    Wednesday, September 29, 2010 8:52 PM

Answers

  • This sounds about right - site state will not come from a per-site query (that would be too inefficient). The MP uses a single data source to get the status of all sites.  Is "default web site" the one that has no default bindings?  What if you make a dummy default site - will this let the monitor successfully complete?

    The MP was not designed to handle IIS hosted WCF services, unfortunately.


    Microsoft Corporation
    • Marked as answer by Shadow Chaser Thursday, October 7, 2010 2:27 AM
    Thursday, September 30, 2010 1:13 AM

All replies

  • This sounds about right - site state will not come from a per-site query (that would be too inefficient). The MP uses a single data source to get the status of all sites.  Is "default web site" the one that has no default bindings?  What if you make a dummy default site - will this let the monitor successfully complete?

    The MP was not designed to handle IIS hosted WCF services, unfortunately.


    Microsoft Corporation
    • Marked as answer by Shadow Chaser Thursday, October 7, 2010 2:27 AM
    Thursday, September 30, 2010 1:13 AM
  •  

    Hi,

     

    Regarding the IIS error, I would like to share the following with you for your reference:

     

    The object identifier does not represent a valid object.

    http://blogs.iis.net/brian-murphy-booth/archive/2008/06/03/visual-studio-2008-unable-to-debug-asp-net-app-on-iis-7-0.aspx

     

    The object identifier does not represent a valid object. (Exception from HRESULT: 0x800710D8)

    http://www.dotnetscraps.com/dotnetscraps/post/The-object-identifier-does-not-represent-a-valid-object-(Exception-from-HRESULT-0x800710D8).aspx

    Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

     

    Please also go to the IIS Server side to check if the error is there. If so, please also try the methods in the above articles.

     

    If the issue persists, considering it occurs on the IIS Server originally, it is also recommended that you go to IIS Forum for help.

     

    IIS Forum

    http://forums.iis.net/

     

    Hope this helps.

     

    Thanks.


    Nicholas Li - MSFT
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, October 1, 2010 8:15 AM
  • I went in and checked the IIS site - it definitely appears to be working correctly. Checked the two articles supplied but I'm not seeing the underlying problem that was described in those cases.


    Adding an HTTP binding to the site solved the problem. I don't understand the internals of how the IIS management pack works, but my guess is that it must be a bug or design oversight in it's implementation. It appears to make the incorrect assumption that all sites have HTTP bindings. Hopefully this can be reviewed for future releases.

    I wrote a URL Rewriting rule in the web.config that forces an "unauthorized" for the HTTP binding. It's a bit more configuration, but it's not much worse than the previous behavior for unbound sites.


    In case you were wondering why our configuration is the way it is:

    * We leave "Default Web Site" on our servers so that misconfigured installers or other applications have a location to "latch onto". Otherwise, some other site becomes "Site 1" and gets reconfigured by Windows and other apps.

    * We use WCF to bind to MSMQ and receive messages that way. Since we can only have one net.msmq binding for the entire server, we leave this on Default Web Site. Also, Windows 2008 R2's installer "reconfigures" default web site during component install or reconfiguration


    * We host a large number of websites for clients. We do not want the default page to show if another site ever goes offline ("Welcome to IIS", etc). That's the primary reason we remove the HTTP binding.

     

    Thanks for the help!

    Thursday, October 7, 2010 2:27 AM
  • Unfortunately the issue is not technically in the MP, since the actual discovery module is a native C++ module that ships with the OpsMgr agent. The MP merely "uses" the module. 

    I have now a bug tracking this module's behavior to be addressed in the agent in the future if possible.

    Also check the other thread http://social.technet.microsoft.com/Forums/systemcenter/en-US/46e2f01c-3241-4679-9d14-9ee7e3636d0c/failed-to-retrieve-site-state for another possible workaround to minimize the alert noise.

    If you could share the URL rewriting rule you have written (anonymized of course), that would be also useful to the community...


    • Edited by Daniele Muscetta Thursday, July 11, 2013 5:57 PM clarified one sentence
    Thursday, July 11, 2013 5:56 PM
  • Just came back to this thread to inform all that this bug is fixed in System Center 2012 R2. The fix has also been backported to System Center 2012 SP1 Update Rollup 4 - http://support.microsoft.com/kb/2879276/en-us (you need to update the agents, since the fix in in the discovery module)
    Tuesday, October 22, 2013 8:44 PM