OWSUG.ca

Welcome to Ottawa's Windows Server User Group Community!
Welcome to OWSUG.ca Sign in | Join | Help
in Search

Rantings of an IT Pirate

As a pirate is passionate about the open sea, such is my passion about technology. I am the first "ethical" IT Pirate.

401 HTTP return code in Web Application monitor test even if you can get the page successfully

While configuring monitoring of a web site for a customer, I was perplexed by a 401 (unauthorized) HTTP return code.  This error was present even when I attempted to configure the monitor using a browser recording session.  Within the session itself, I was able to successfully authenticate and access the site which generates a typical HTTP return code of 200 as expected.

The test itself indicates in a prompt that it may fail even if you can successfully get the page to load.  The test does not however, go into why this is the case.

This was particularly frustrating in my case as I was creating the Web Application monitor in SCOM to generate a client perspective view which was only one of the components in a distributed application.  So, this test showing up as failed consistently caused my entire distributed application to track as Critical because of the configured relationships and the way health rolls up in Operations Manager.

After researching Microsoft resources, it turns out that if anonymous access is disabled on the web site you are accessing due to the way IIS evaluates authentication, this behavior is expected.

In Operations Manager, the default evaluation for a Web Application is to generate a Critical Alert if an HTTP return code of 400 or anything above comes back.

In IIS, even if anonymous authentication is disabled for the site, it is still evaluated and will always return a 401.  The aggregated results (The outcome) will succeed but the 401 return code will cause the test to fail...

There are 2 ways to work around this issue. 

First, anonymous access to the site can be enabled.  This is not always practical. 

Second, the evaluation criteria can be modified to alert on anything above an HTTP 401 return code.  Effectively, this nullifies your ability to be alerted to any actual 400 or 401 return code issues but the test will now succeed.

Alternatively, monitoring the web application can be performed based on content and not HTTP return codes.  As for myself, I used the second work around to get this functional.

Published Wednesday, September 24, 2008 7:25 AM by Brad Bird

Comments

No Comments
Anonymous comments are disabled
Powered by Community Server, by Telligent Systems