0 comments
Various 
Notification channels in operations manager 2007 R2 give you the option to determine what to include in alert notifications being sent to, for instance, a specific e-mail address.
For an Email (SMTP) channel the default format for your messages is as follows:
Alert: $Data/Context/DataItem/AlertName$
Source: $Data/Context/DataItem/ManagedEntityDisplayName$
Path: $Data/Context/DataItem/ManagedEntityPath$
Last modified by: $Data/Context/DataItem/LastModifiedBy$
Last modified time: $Data/Context/DataItem/LastModifiedLocal$
Alert description: $Data/Context/DataItem/AlertDescription$
Alert view link: “$Target/Property[Type=”Notification!Microsoft.SystemCenter.AlertNotificationSubscriptionServer”]/WebConsoleUrl$?DisplayMode=Pivot&AlertID=$UrlEncodeData/Context/DataItem/AlertId$”
Notification subscription ID generating this message: $MPElement$
As can be seen above (the bold part), at the bottom of your mail there will be a link included to view the alert in the Web Console.
Should your (webconsole) server be located at a remote location behind a TMG or ISA firewall which publishes the webconsole, you could run into the problem where you would get the following message in your browser:
Accompanied by the following text:
Technical Information (for support personnel)
- Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact the server administrator. (12217)
Cause
The alert view link contained in the e-mail by default is URL-encoded, and although this normally should not be a problem, it can become a problem when you’re not logged in on the webconsole. When you are not logged in, the webconsole redirects you to the logon page, and in doing that, the URL is encoded a second time making it an URL being blocked by ISA / TMG.
This is caused by the setting ‘verify normalization’ in http filtering. As stated on technet on this setting:
“… Web servers receive requests that are URL encoded. This means that certain
characters may be replaced with a percent sign (%) followed by a number. For
example, %20 corresponds to a space, so a request for
http://myserver/My%20Dir/My%20File.htm is the same as a request for
http://myserver/My Dir/My File.htm. Normalization is the process of decoding
URL-encoded requests. Because the % can be URL encoded, an attacker can submit a
carefully crafted request to a server that is basically double-encoded. If this
occurs, the Web server may accept a request that it would otherwise reject as
not valid. When you select Verify Normalization, the HTTP filter normalizes the
URL twice. If, after the second normalization, the URL is different to the URL
from the first normalization, the filter rejects the request. This prevents
attacks that rely on double-encoded requests …”
Solution
You could circumvent this problem by turning off the verification for normalization, but in my opinion this is not the ideal situation since you’re lowering security.
There’s another solution that I prefer more, which is to change the e-mail format in the notification channel. As stated earlier the link to the webconsole in the e-mail is presented by:
Alert view link:
“$Target/Property[Type=”Notification!Microsoft.SystemCenter.AlertNotificationSubscriptionServer”]/WebConsoleUrl$?DisplayMode=Pivot&AlertID=$UrlEncodeData/Context/DataItem/AlertId$”
Notification subscription ID generating this message: $MPElement$
As can be seen, this code explicitly tells to URL-Encode the data in the e-mail. Should you replace ‘$UrlEncodeData’ by ‘$Data’ the URL will be sent in the e-mail unencoded.
The only downside is that if you use Outlook, the link will still fail if you simply click it in your e-mail because somewhere between outlook and internet explorer apparently the link is still URL-Encoded (OWA does not have this problem). I’ve searched for a solution but haven’t found one so far. If you have a solution to this please inform me ’cause I want to know. Until then (or until microsoft fixes the redirection problem) I right-click the link >> ‘copy hyperlink’ and paste it in my browser.