Hi All, I have a simple web application to monitor the presence of a specific URL. I found a problem where the watcher node is not able to open the web page but does not report any problem. I tried opening the URL from the watcher with IE but IE just sits there in an infinite loop and never report that the page is not available. It seems SCOM does the same thing and never report that the page is unreacheable. So the end result is that the web site is down but SCOM never generate an alert. Is this the expected behavior for a web application that when the URL request never answers SCOM never reports an error ?

Hi there. Is the web application configured with a response time criteria?Layne

Hi Layner, yes we did try to check the response time to generate an error but that does not work either. It's look like the transaction never completes and the SCOM watcher never gets any info to complete the monitoring scenario.

Hi, do you know how the page is getting stuck? What is the underlying problem that makes IE/URLProbe keep trying to fetch the data? The URL Probe does have some timeouts configured (like connection timeouts for instance), but it does not abort a request from a responding server... If this is a public URL I would like to try the test to debug the issue in house. Otherwise, if you could collect the winhttp traces and OM product traces from the watcher node performing the test - they may explain what is going on. - Alex.This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Hi, I also think you may need to provide more information about your environment and configurations, such as the site you want to monitor. At this time, please also try the following: 1. Double-check your Web Application Monitor: How to Create a Web Application Monitor http://technet.microsoft.com/en-us/library/bb381370.aspx 2. How to generate web application response time reports in OpsMgr 2007 http://blogs.technet.com/operationsmgr/archive/2009/04/28/how-to-generate-web-application-response-time-reports-in-opsmgr-2007.aspx Hope this helps. Thanks. Nicholas Li - MSFT

Thanks for the input. I have checked my web apps configuration and read the links provided but that does help me. The web app monitor works fine is most situations but there is one case where the web site does not answer and the web app state does not change to unhealthy. When we try to reach the site with IE, it just loops and never comes back with an error message or a timeout. We know there is something wrong with the web site and that's when SCOM should report a problem but it does not. SCOM's web applications does not look like an enterprise class solution for reliable web monitoring. Anyone know of other products for web monitoring scenarios ?

When you say the web site just loops, what do you mean? Resorting to slamming something won't be helpful - let's just focus on what the details of your situation are and we will try and help you. Clarity will move things along quickly. One possible way for a poorly written web application to "loop" is to redirect to a page that resolves to the same redirect. In this case, the timeout conditions are not applicable because the hosted browser session is active, and getting data. Essentially, the fetch time is quite long - and if the redirect ever resolved or ceased, you would probably see a slow page load alert. Consider setting the transaction to not accept redirects and to not drill down on embedded links. If there are scripts on the page that you know to be bad (which your IE test proves that the page you are monitoring is not functioning in a production ready state), then consider fixing the page code that is causing the infinite browser loops. Microsoft Corporation

Hi Dan, thanks for your feedback. Sorry it came out as slamming. The URL that caused a problems is not a redirect and the web app does not follow links. Correct me if I'm wrong but the diagnostics that you are suggesting apply to the web site itself and not the monitoring scenario. So are you saying that SCOM's web applications scenarios depend on a web site that is problem free and well written? We are actually trying to monitor web sites that can have those kind of problems (bad redirects or scripts) and are trying to get alerts from SCOM when those problems occur through a timeout in the request or a content filter. I agree with you that the cause of the loop is a problem with the site itself but I still think that the web app should timeout and report a problem and that's not what it does.

Hi, we really need more data to be able to help here. Even if you are following links, link loops should be detected and avoided by the probe. If your site has bad script, it doesnt matter since the probe won't run client side scripts. If you have bad server side scripts that redirects then it could be a problem - but you are not following redirects so it is out of the question. At this point, winhttp traces would really help understand what is happening. Do you know how to collect those? If not I would need at least the OS version of the watch node to provide instructions. - Alex.This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Hi Alex, I investigated the problem on the server and it was in fact a circular redirection. The link loop was created by a 302 return code that pointed back to the page. I will try to reproduce the problem in my lab and will give you more details.

Hi, I will "mark as answer" as no activity for a long time, feel free to re-open this thread. ThanksAnders Bengtsson | Microsoft PFE | blog at http://www.contoso.se