none
Web Application Availability Test: The URL probe returned error code 80072F78. Reason: 0x80072f78 RRS feed

  • Question

  • Hi all,

    I've got an issue I can't find much information about.  I can reproduce the same issue on 2 different SCOM environments that are unrelated, so I presume the issue is with the site I am doing availability checking on, but how to further diagnose the issue is where I need help.

    I am using SCOM 2012 R2 with UR2, to monitor a public facing internet website (www.sunsuper.com.au).  When I monitor this site through WEB APPLICATION AVAILABILITY MONITORING, I get the following error when trying to run a test.

    The URL probe returned error code 80072F78. Reason: 0x80072f78

    When trying to run a WEB APPLICATION TRANSACTION MONITOR, I get the following error.

    Run with errors: Failed Error Code check.  ErrorCode: 2147954552 - 0x80072f78

    From what I can gather, these error codes mean ERROR_WINHTTP_INVALID_SERVER_RESPONSE.

    These errors don't give much information and the RAW data tells me basically nothing.  I get the same error when monitoring this website from the internal customer management servers, as well as my home SCOM lab which is on an open ADSL connection.

    Note that both on the customer site, and at home in my lab I can access the web page just fine and it loads.  We can also monitor other web pages without any problem (internal intranet sites, other public sites like bing.com or google.com etc). 

    I am fairly certain the issue is with this site itself, but before I can go to someone to tell them what to fix, I need to understand what's causing this issue.

    Can anybody offer some advice?



    http://www.dreamension.net

    • Changed type Noel Fairclough Wednesday, July 16, 2014 12:28 AM is suppose to be a question
    Wednesday, July 16, 2014 12:02 AM

Answers

  • Hi everyone, well I eventually got to the bottom of the error and I thought I would post my troubleshooting procedure and what the issue turned out to be. 

    I installed the trial version of Visual Studio 2013 Ultimate, and I ran a Web Performance and Load Test.  For those of you not familiar with the test (it was the first time I had ever run one) - after installing VS2013, you simply go to File -> New -> Project -> Web Performance and Load Test Project.  From there, you can hit "Record", which will launch a browser, and then navigate to your URL that you are testing.  When you're done, stop and save the recording and then you can playback/re-run the test.

    Performing this test gave me more information about the problem - and Visual Studio returned the following error.

    Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

    I then spoke to a web developer friend of mine who gave me some more guidance and things to look at.

    I then ran FIDDLER again ((http://www.telerik.com/fiddler) this time looked at the headers tab and we found a problem which we didn't notice before, and I've now included here:

    RESPONSE HEADERS:
    HTTP/1.1 200 OK
    Cache-Control: public, max-age=1
    Connection: keep-alive
    Content-Encoding: gzip
    Content-Type: text/html; charset=utf-8
    Date: Thu, 31 Jul 2014 09:04:36 GMT
    Expires: Thu, 31 Jul 2014 09:04:37 GMT
    Last-Modified: Thu, 31 Jul 2014 09:04:36 GMT
    Server: nginx
    Set-Cookie: ecm=UAC_4Cpfo6ccCJxPkYvcIjDE0mEMas6Gh3ebCeHw7ZdzN_rnNUqoZBioEUynPk2Sv6d0Dk8AiwYyhhCxPw4w32zGh0f_7BRqKh9NtnLSZmh28uo_SUdMu0CcR1fFsG2k_VN2xiOcjeETokTysK9YWqBRQ0uw-lNSjW74WZY3kxoIekHvk65ks_ltBL59mwGuvjjZPZWvlsHcupsDFofLcpomQ4GUdL1yjxUi32EnDBSwOIHWXea4q0-Jfk0CcY7i5OkYIvlD5CebN1C29RaYZvyE4eL_0wq6d_Gst5a0dCvpSVZwgY6LYpDhecwdJo-9SPjvf6P6oGRIqhCx1w1jg3gRa01ig4cxvWbYXPlOKcXDvtKMefPH1zTD7VAvHBfJkxz1A01Fpyb38Ko-CNFlvRewcCUMrUIl7xFp3NCDZxZQy6vRa4Je718O-XNXlFQuJ0o82jxaRj_Kx3WwEzktJ-Jdgv99ckV9UfHbZKbAhos1; path=/
    Set-Cookie: EktGUID=7e8353d1-bf55-42fd-b5b1-063a88d8a167; expires=Fri, 31-Jul-2015 09:04:36 GMT; path=/
    Set-Cookie: EkAnalytics=0; expires=Fri, 31-Jul-2015 09:04:36 GMT; path=/
    Set-Cookie: ASP.NET_SessionId=nveaxvtnmivrft4rhu1aocvb; path=/; HttpOnly
    Set-Cookie: BALANCEID=mycluster.node1; path=/;
    Transfer-Encoding: chunked
    Vary: Accept-Encoding
    Vary: *
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    X-UA-Compatible: IE=edge
    X=UA-Compatatible: IE=Edge,crome=1

    ^I've bolded the error.  Someone butterfingered the custom header.  Compatatible is suppose to say "Compatible" and Crome is suppose to say "Chrome".

    This is what the Visual Studio web test was complaining about, and it turns out it is what SCOM wasn't recognizing during the Availability Test.  After the header was corrected the Visual Studio web tests passed successfully, and also the SCOM Web Availability tests were successful. 

    So correcting this header has resolved our issue.  Hopefully this will help someone in the future who may come across the same error.


    http://www.dreamension.net

    Thursday, August 14, 2014 11:55 PM

All replies

  • Hi Noel,

    Try to use the lower case letters when typing the URL address, as it could be connected to Linux firewall.


    Natalya

    Wednesday, July 16, 2014 2:10 AM
  • Hi Natalya,

    Thanks for your suggestion.  I did have it in lower case, but thinking it might be case sensitive - I changed it all to upper case, but unfortunately I still receive the same error.

    I also just used FIDDLER, and I used the same GET HTTP request response from SCOM (which is from the test results section), and I used that in FIDDLER to check the page - and it returned HTTP 200 (which is good).

    So it seems the problem is specifically between SCOM and this site.

    I will continue my investigation and if I get to an answer I will post up what I find. 

    But if anybody else has other suggestions, please let me know.


    http://www.dreamension.net

    Wednesday, July 16, 2014 2:48 AM
  • And this is the RAW data if it helps...

    <DataItem type="Microsoft.SystemCenter.WebApplicationTest.WebTestData" time="2014-07-16T15:30:02.1562412+10:00" sourceHealthServiceId="A02DA25F-640A-9006-E30E-929BC1EED5DE"><TransactionResponseTime>0.79363955474788</TransactionResponseTime><TransactionErrorCode>0</TransactionErrorCode><CollectPerformanceData Type="Boolean">true</CollectPerformanceData><TestTimeout Type="Boolean">false</TestTimeout><TransactionEvalResult>3</TransactionEvalResult><TransactionResponseTimeEvalResult>0</TransactionResponseTimeEvalResult><TransactionErrorCodeEvalResult>1</TransactionErrorCodeEvalResult><RequestResults><RequestResult Id="1"><State>1</State><CollectPerformanceData Type="Boolean">false</CollectPerformanceData><RequestEvalResult>3</RequestEvalResult><BasePageData><ResponseUrl>http://www.sunsuper.com.au</ResponseUrl><DNSResolutionTime>0</DNSResolutionTime><TCPConnectTime>0</TCPConnectTime><TimeToFirstByte>0</TimeToFirstByte><TimeToLastByte>0</TimeToLastByte><RedirectTime>0</RedirectTime><ContentTime>0</ContentTime><ResponseTime>0</ResponseTime><DownloadTime>0.79363955474788</DownloadTime><ContentSize>0</ContentSize><StatusCode>0</StatusCode><ErrorCode>2147954552</ErrorCode><Redirected Type="Boolean">false</Redirected><ResponseHeaders></ResponseHeaders><ResponseBody></ResponseBody><SecureFailureCode>0</SecureFailureCode><DaysToExpiry>4294967295</DaysToExpiry><RequestUrl>http://www.sunsuper.com.au</RequestUrl><RequestHeaders><![CDATA[GET / HTTP/1.1
    Accept: */*
    Accept-Language: en-us
    Accept-Encoding: GZIP
    User-Agent: Microsoft Monitoring Agent 7.1.10184.0
    Proxy-Connection: Keep-Alive
    
    ]]></RequestHeaders><Verb>GET</Verb><Version>HTTP/1.1</Version><CertificateExpired Type="Boolean">false</CertificateExpired><CertificateAuthorityUntrusted Type="Boolean">false</CertificateAuthorityUntrusted><CertificateCNInvalid Type="Boolean">false</CertificateCNInvalid><DNSResolutionFailure Type="Boolean">false</DNSResolutionFailure><Unreachable Type="Boolean">false</Unreachable><ResponseBodyEvalResult>0</ResponseBodyEvalResult><StatusCodeEvalResult>0</StatusCodeEvalResult><ErrorCodeEvalResult>3</ErrorCodeEvalResult><CheckRedirectsEvalResult>0</CheckRedirectsEvalResult><MonitorSSLEvalResult>0</MonitorSSLEvalResult></BasePageData><ResourceData><AggregateDNSResolutionTime>0</AggregateDNSResolutionTime><AggregateTCPConnectTime>0</AggregateTCPConnectTime><AggregateTimeToFirstByte>0</AggregateTimeToFirstByte><AggregateTimeToLastByte>0</AggregateTimeToLastByte><AggregateRedirectTime>0</AggregateRedirectTime><AggregateContentTime>0</AggregateContentTime><AggregateResponseTime>0</AggregateResponseTime><AggregateContentSize>0</AggregateContentSize><StatusCodeEvalResult>0</StatusCodeEvalResult><ErrorCodeEvalResult>0</ErrorCodeEvalResult></ResourceData></RequestResult></RequestResults></DataItem>


    http://www.dreamension.net

    Wednesday, July 16, 2014 5:31 AM
  • Hi Noel,

    Some ideas are - try to use different DNS server and check DNS; check\play with proxy settings.


    Natalya

    Thursday, July 17, 2014 2:00 AM
  • Hi everyone, well I eventually got to the bottom of the error and I thought I would post my troubleshooting procedure and what the issue turned out to be. 

    I installed the trial version of Visual Studio 2013 Ultimate, and I ran a Web Performance and Load Test.  For those of you not familiar with the test (it was the first time I had ever run one) - after installing VS2013, you simply go to File -> New -> Project -> Web Performance and Load Test Project.  From there, you can hit "Record", which will launch a browser, and then navigate to your URL that you are testing.  When you're done, stop and save the recording and then you can playback/re-run the test.

    Performing this test gave me more information about the problem - and Visual Studio returned the following error.

    Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

    I then spoke to a web developer friend of mine who gave me some more guidance and things to look at.

    I then ran FIDDLER again ((http://www.telerik.com/fiddler) this time looked at the headers tab and we found a problem which we didn't notice before, and I've now included here:

    RESPONSE HEADERS:
    HTTP/1.1 200 OK
    Cache-Control: public, max-age=1
    Connection: keep-alive
    Content-Encoding: gzip
    Content-Type: text/html; charset=utf-8
    Date: Thu, 31 Jul 2014 09:04:36 GMT
    Expires: Thu, 31 Jul 2014 09:04:37 GMT
    Last-Modified: Thu, 31 Jul 2014 09:04:36 GMT
    Server: nginx
    Set-Cookie: ecm=UAC_4Cpfo6ccCJxPkYvcIjDE0mEMas6Gh3ebCeHw7ZdzN_rnNUqoZBioEUynPk2Sv6d0Dk8AiwYyhhCxPw4w32zGh0f_7BRqKh9NtnLSZmh28uo_SUdMu0CcR1fFsG2k_VN2xiOcjeETokTysK9YWqBRQ0uw-lNSjW74WZY3kxoIekHvk65ks_ltBL59mwGuvjjZPZWvlsHcupsDFofLcpomQ4GUdL1yjxUi32EnDBSwOIHWXea4q0-Jfk0CcY7i5OkYIvlD5CebN1C29RaYZvyE4eL_0wq6d_Gst5a0dCvpSVZwgY6LYpDhecwdJo-9SPjvf6P6oGRIqhCx1w1jg3gRa01ig4cxvWbYXPlOKcXDvtKMefPH1zTD7VAvHBfJkxz1A01Fpyb38Ko-CNFlvRewcCUMrUIl7xFp3NCDZxZQy6vRa4Je718O-XNXlFQuJ0o82jxaRj_Kx3WwEzktJ-Jdgv99ckV9UfHbZKbAhos1; path=/
    Set-Cookie: EktGUID=7e8353d1-bf55-42fd-b5b1-063a88d8a167; expires=Fri, 31-Jul-2015 09:04:36 GMT; path=/
    Set-Cookie: EkAnalytics=0; expires=Fri, 31-Jul-2015 09:04:36 GMT; path=/
    Set-Cookie: ASP.NET_SessionId=nveaxvtnmivrft4rhu1aocvb; path=/; HttpOnly
    Set-Cookie: BALANCEID=mycluster.node1; path=/;
    Transfer-Encoding: chunked
    Vary: Accept-Encoding
    Vary: *
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    X-UA-Compatible: IE=edge
    X=UA-Compatatible: IE=Edge,crome=1

    ^I've bolded the error.  Someone butterfingered the custom header.  Compatatible is suppose to say "Compatible" and Crome is suppose to say "Chrome".

    This is what the Visual Studio web test was complaining about, and it turns out it is what SCOM wasn't recognizing during the Availability Test.  After the header was corrected the Visual Studio web tests passed successfully, and also the SCOM Web Availability tests were successful. 

    So correcting this header has resolved our issue.  Hopefully this will help someone in the future who may come across the same error.


    http://www.dreamension.net

    Thursday, August 14, 2014 11:55 PM