Using the Microsoft Web Sites and Services Management Pack

On This Page

Creating Request Sequences for Monitoring a Web Site
Creating Request Sequences for Monitoring a Web Service
Security

Creating Request Sequences for Monitoring a Web Site

Capturing a Web Browser Session

You can create Request Sequences for monitoring Web sites either manually or with the help of the capture Web site navigation feature.  Using the MP Configuration Wizard you can capture the navigation through one or more Web sites and turn it into a Request Sequence.

The capture Web site navigation feature intercepts traffic between Internet Explorer and the Web site and captures all HTTP request data, such as headers and body.  

This feature also sets defaults for monitoring criteria to match the captured data. For instance, if during capture a Web server reports status code 404 for a request, the MP Configuration Wizard defaults to expecting a 404 status code for that request. These defaults can be changed.

When you are using the capture navigation features, responses from a Web server may be affected by the client-side state of Internet Explorer. This usually affects caching behavior and cookie handling. Before recording a Web browser session, you should clear the Internet Explorer cache.

If Internet Explorer does have a cached copy of the file, it will indicate this using the if-modified-since HTTP header in the request to the Web server. If the if-modified-since header is sent, the Web server might return a 304 status code to confirm that the file need not be transferred again because Internet Explorer already has the most recent version. If defaults are not changed and the file on the Web server does not change, monitoring criteria will succeed. If the file changes, the Web server will return the new file and a 200 status code and the monitoring criteria will fail. You can prevent this by manually removing the if-modified-since header from the request after recording the Web browser session, changing the expected status code from 304 to 200, and clearing the Follow HTTP Redirects option for the entire Request Sequence.

By default, HTTP redirects in a Request Sequence Group are not followed. If you enable redirects and you also create the Request Sequence by recording a Web browser session, redirect status codes, such as 302, are recorded and used to determine the error and warning criteria. Note that during monitoring, if the redirect is followed and leads to a URL that returns a status code of 200, the request will be treated as a failure and an error or warning event will be raised.

The Web Sites and Services MP is not able to record a Web browser session for SSL-protected URLs, since the messages transmitted between the browser and the server are encrypted. You must manually add URLs that use the SSL and the HTTPS protocol to your Request Sequence.

Manually Creating Requests

Although it is easier to create a Request Sequence by automatically recording a Web browser session, you can also manually create the requests in situations where you need more control over the request properties.

This technique requires knowledge of the HTTP protocol, the behavior of the HTTP client you are trying to emulate, and the behavior of the Web application and Web server you are monitoring.

Handling Cookies

Cookies are usually used for persisting preferences for a Web site or to identify a session. During monitoring, the Web Sites and Services MP will automatically manage the updating and, if necessary, the creation of cookies.

Session cookies captured from a Web browser session will not be valid during monitoring, so you must manually delete them from the request headers. During monitoring, the Web Sites and Services MP will automatically store and manage session cookies set by the Web server. You should also manually delete any session cookies that will be modified by the server during monitoring, such as the ASP.NET_SessionID, or JSESSIONID cookies.

Handling Redirects

A Request Sequence can be configured to automatically follow all redirects based on the response status code value. Status code values of 301, 302, 303, and 307 will result in redirects.

When you create a new Request Sequence by recording a Web browser session, you do not need to enable HTTP redirects during monitoring. All redirects that occurred during the recorded session are automatically captured as a separate request that follows the original request. If you do enable redirects for the Request Sequence during monitoring, the Web Sites and Services MP will produce a second, unnecessary request to the redirect URL.

Unless you are recording a Web browser session, redirects based on client-side HTML or scripting are not followed automatically.

Monitoring the Response Body

On the Request Properties dialog box, you can configure a Request Sequence to monitor the size and content of a response body. For security and performance reasons, the Web Sites and Services MP is configured to read only the first 256 KB of response data. If the string you are monitoring occurs after the first 256 KB of data, it will not be found. To increase the amount of content the Web Sites and Services MP reads from the response, edit the value of the following registry entry on the Management Server:

HKLM\SOFTWARE\Microsoft\Microsoft Web Service Monitoring\1.0\Setup\MaximumResponseStorageBytes

For more information about supported values for this entry, see the “Web Sites and Services MP Registry Key Entries” section of this guide.

The Web Sites and Services MP does not try to interpret Web page content the same way that a Web browser would. For example, client-side dynamic HTML scripts are not executed. Metadata stored in the HTML, such as character encoding information, is also not retrieved or used.

Monitoring Response Content

In most cases, a Web page is composed of content and scripts assembled from more than one source. To render a Web page correctly, the Web browser requests and processes content from cascading style sheets, client-side scripts, images, and frames that are associated with the main page. To provide data that more accurately reflects what users experience, the monitoring criteria for a Request Sequence can be configured to include items referenced by in the response body’s HTML. There are two ways to perform this type of monitoring.

If you are monitoring a Web page with referenced content that rarely changes, you can easily create a Request Sequence by recording a Web browser session. As Internet Explorer processes the request for a Web page and sends additional requests for the referenced items, they are all recorded as individual requests in the Request Sequence. The resulting Request Sequence represents the Web page and all of the items it references. This method also records requests that are created or modified through the execution of client-side scripts in the Web browser.

When you must monitor a Web page and the items it references, but the URLs for the referenced items change frequently (perhaps even for each request), then a Request Sequence composed of static requests would not be suitable. For monitoring rapidly changing content, it is better to exclude the requests for referenced items from the Request Sequence and instead rely on the Web Sites and Services MP’s ability to dynamically process a request’s content and request items referenced in specific HTML elements, such as IMG, and SCRIPT.

Two measurements are affected by the settings on the Content tab of the Request Properties page:

1. Response time: When you enable content monitoring, the response time for the initial request will be calculated by adding the response time for the initial response with the sum of the response times for all referenced items. The underlying performance counter values, however, remain the same. Like most Web browsers, the Web Sites and Services MP requests the items referenced in the HTML sequentially. The sum of these response times is the value used when the response time criterion is evaluated. You can individually enable or disable the specific HTML elements used to reference external resources. If the A (anchor) element is enabled, links to other Web pages are requested, but the pages are not processed in a recursive manner.

2. Status Code: The status code criterion for the main request is applied to all of the resources it references. Unlike the response time, results for referenced items do not influence the value recorded for the main request. For example, the main request will succeed, and be recorded as a success for reporting purposes even when one of the images it references returns a 404 status code and fails. You can individually enable or disable the specific HTML elements used to reference external resources.

     Note
   The response time values used during criteria evaluation and for reporting at the Request Sequence level are always based on the actual value measured for the main request, even when you enable content monitoring on one or more of the requests contained in the Request Sequence.

Response Content Character Encodings

To avoid ambiguity, the response for a URL should contain a Content-Type HTTP header, including a charset parameter. Character sets specified in the HTML of a Web page are ignored by the Web Sites and Services MP. If the Content-Type header or charset parameter is missing, the Web Sites and Services MP might try using a default character encoding for some recognized file types. If the character encoding of the response is not known and a default does not exist, the Web Sites and Services MP does not parse the content.

Resources, such as scripts and style sheets, are not assumed to use the same character encoding as the Web page that referenced them.

If you experience problems parsing the response body content with the Web Sites and Services MP, you can use the IIS Manager to explicitly configure a Multipurpose Internet Mail Extensions (MIME) type mapping for any file type that uses a specific file name extension. After the MIME type mapping is configured, IIS will include a Content-Type header in the response for files of that type.

If the Content-Type header exists in the response, but specifies a character encoding that is not recognized or available on the computer, the content is ignored. You can add additional language packs to a computer from the Language and Regional Settings Control Panel.

Creating Request Sequences for Monitoring a Web Service

You can create Request Sequences for monitoring Web services either manually or with the help of the Web Sites and Services MP Configuration Wizard WSDL import feature. You can point the MP Configuration Wizard to the WSDL file for the Web service you want to monitor. The MP Configuration Wizard imports the WSDL file and shows you the methods exposed by the Web service.

After assembling a sequence of method calls from all available methods, you need to set parameter values for each method call. The MP Configuration Wizard provides a parameter editor that supports basic SOAP 1.1 data types, arrays of basic SOAP 1.1 data types, and enumerations.

Use the left navigation tree in the parameter editor to select the parameter you want to edit. When filling in the values for an array, you first need to specify the length of the array. This will create additional nodes in the parameter tree to reflect the desired array length.

Security

Data Storage in Rules and Request Sequence Data Files

The Web Sites and Services MP creates and stores data in two different formats. It uses MOM rule groups and rules, which are the same as those found in any other MOM Management Pack. The second format, the XML-based Request Sequence data file, is unique to the Web Sites and Services MP, and has a unique set of security characteristics and requirements.

It is important to note that when you create a Request Sequence to monitor a Web application secured with SSL (Secure Sockets Layer), although any data transmitted between the Web Sites and Services MP and the Web application during monitoring is encrypted, the content stored in the Request Sequence data file is not encrypted. Similarly, if the request headers include authentication information, for example, when Basic authentication is used, then the authentication credentials will be transmitted in an unencrypted format within the Request Sequence data file.

Increasing Security for Request Sequence Data Files Using SSL

The configuration information for the Request Sequence is saved to an XML document that is not encrypted during storage in a BITS virtual directory, or when it is transmitted between the MOM Management Server, BITS virtual directory, MP Configuration Wizard or Agent Configuration Components.

You can configure the Web Sites and Services MP to send the Request Sequence data file over an encrypted (SSL) channel when it is transmitted between the BITS virtual directory, the MP Configuration Wizard, and the agent-managed computers running the Web Sites and Services MP rules.

If you configure BITS to use the HTTPS protocol for increased security, you must also configure the response for the rule used to transfer the Request Sequence files. For more information, see the “Installing the Server Configuration Components” section of this guide.

Increasing Security for Request Sequence Data Files by Restricting Access

The System (LocalSystem) and NetworkService Accounts are used by MOM file transfer responses, and they must have access to the relevant BITS virtual directory to create or modify Request Sequence data files. The virtual directory, by default, is configured to use Anonymous access for read-only requests. To restrict Read access, you must:

1. Use the IIS Manager to manually configure the virtual directory to use authentication, preferably Windows Authentication.

2. Only allow the built-in System (LocalSystem) and NetworkService Accounts on agent computers to access this virtual directory by granting directory access to their respective computername$ computer accounts.

Using Authentication During Monitoring

The Request Sequences created by the Web Sites and Services MP run as MOM rules, and like other MOM rules, they will run under the same account and credentials as the MOM Action Account. The MOM Action Account must have sufficient privileges to request the URLs specified in the Request Sequences. For some authentication schemes, you can explicitly provide credentials for an account other than the MOM Action Account.

The following table shows the authentication schemes supported by the Web Sites and Services MP, and how you can implement them.

Table 3  Authentication Support

The Web Sites and Services MP does not support Passport authentication, Digest authentication, or X.509 certificate authentication.