Tip

Create a secure Microsoft Outlook Web Access (OWA) redirect page

Incorrectly typing the URL for your Microsoft Outlook Web Access (OWA) page will result in an error message. Because users may mistakenly type HTTP instead of HTTPS to access OWA, Microsoft Exchange expert Brien Posey recommends creating an OWA redirection page that doesn't sacrifice secure sockets layer (SSL) security. This tip explains the steps to create your own secure OWA redirect page.

Although I'm familiar with Exchange Server and Microsoft Outlook Web Access (OWA), I sometimes forget to type HTTPS when accessing my OWA site. This causes my OWA server to generate a The Page Must Be Viewed Over A Secure Channel error message. When this happens, I simply enter the URL correctly and log on.

    Requires Free Membership to View

More OWA resources:
How to improve Outlook Web Access (OWA) security

Customizing Outlook Web Access in Exchange Server 2007

Customize OWA authentication logon in Exchange 2003

It occurred to me that there will always be a group of users who may also forget to type HTTPS. I came up with an easy way to help these users -- eliminating the need to type HTTPS without sacrificing SSL security.

To do this, I set up a redirection page. That way, if a user enters the OWA URL using the HTTP prefix (instead of HTTPS), he will be redirected to the OWA website (with SSL enabled), rather than receiving the error message. This should help reduce help desk calls.

The following steps apply to OWA 2007, but this technique will also work for OWA 2003 with slight modifications.

  1. Open Notepad and create a new file containing the following code:
    <head>
    <Meta HTTP-Equiv="refresh" CONTENT=1; URL=https://mirage/owa">
    </head>
  2. This script instructs the Web page to wait one second and then redirect the user to https://mirage/owa (the internal URL for my OWA server). Be sure to replace this URL with the URL for your OWA server.

  3. Once you have created this Notepad document, save it in the client access server's (CAS) C:\Windows\help\iisHelp\common folder as OWA-Redir.htm.

    This creates an HTML page that can redirect users to your OWA page. Next, configure the OWA server to use this new page. To do so, use the Internet Information Services (IIS) Manager console.

  4. Open the IIS Manager console and navigate through the console tree to
    Your server -> Web Sites -> Default Web Site.
  5. Right-click on the Default Web Site container and choose the Properties command from the menu. The console will then display the default website's properties sheet.

Keep in mind that trying to access OWA without typing HTTPS triggers an HTTP 403.4 error. This essentially denies access to the resource (OWA), because a policy states that SSL is required. The error message is actually just a Web page that has been linked to the 403.4 error. To fix this, replace the error Web page with the page that we created earlier. To do so:

  1. Select the Custom Errors tab from the Properties sheet and scroll through the list of errors until you locate the 403.4 error.
  2. Select the 403.4 error and click Edit. You will see that the error is linked to a file named C:\Windows\help\iisHelp\common\403-4.htm.
  3. Redirect this error to C:\Windows\help\iisHelp\common\OWA-Redir.htm.
  4. Click OK a few times and restart IIS.

Although this technique works well, there are a couple of things to note.

  • The change applies to any website that falls beneath the Default Web Site container. This means that if you have any other default websites that are hosted on the OWA server that require SSL encryption, they will be redirected to OWA if a user forgets to type HTTPS. Users won't be redirected to the site that they intended to access.
  • If there is a certificate-related SSL failure, this technique could potentially cause users to become trapped in an infinite loop. For instance, the user would enter the correct URL for the OWA site, but the failure would trigger a redirection. However, because a failure occurred, the redirect would be triggered again and again.

Note: IIS can be particular about custom error pages. I have used this technique on multiple occasions. Most often, it works. However, sometimes IIS gives me a permissions error that I am unable to resolve. If this happens, I recommend editing the existing error message file (DO NOT replace it), so that it includes the new code.

This method won't work for all organizations, but if OWA is the only HTTPS-enabled site on your CAS, this technique might save users some frustration.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Server (IIS) and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.

This was first published in September 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.