Configure Sign-In URLs for Outlook Web App
Applies to: Office 365 for professionals and small businesses, Office 365 for enterprises, Live@edu
Before your users can sign in to their Exchange Online mailbox using Outlook Web App, you have to tell them what URL to use. You have the following options:
Do you want to keep things simple? That’s easy!
- For Microsoft Live@edu, use http://outlook.com.
- For Microsoft Office 365, especially Microsoft Office 365 for professionals and small businesses, use http://mail.office365.com.
Note Because federated identity and hybrid deployments aren't so simple, you should follow the guidance later in this topic at Federated identity in Office 365 for enterprises. Also, you can’t use https in the URL with mail.office365.com. Even though the URL starts with http, the URL is immediately redirected to use https for the entire session, including authentication and accessing your mailbox in Outlook Web App.
Do you want to provide a customized URL for your organization? For example, if your domain is contoso.com, do you want to have your users sign in to their mailbox at http://webmail.contoso.com? If so, you need to do a little bit of work.
Let’s take a look at your options for customized URLs for Microsoft Office 365 and for Live@edu.
Microsoft Office 365
- Non-federated identity in Office 365
- Direct access URLs in Office 365
- Customized URL using a CNAME record in Office 365
- Customized URL using Web page redirection in Office 365
- Federated identity in Office 365 for enterprises
- Direct access URLs in Office 365 for federated users
- Customized URL using a CNAME record in Office 365 for federated users
- Customized URL using Web page redirection in Office 365 for federated users
- Special consideration for hybrid deployments
Live@edu
- Direct access URLs in Live@edu
- Customized URL using a CNAME record in Live@edu
- Customized URL using Web page redirection in Live@edu
Non-federated identity in Office 365
With non-federated identity, all users who have mailboxes in the cloud use Office 365–generated credentials to access their Microsoft Office 365 resources. You can create new user accounts and passwords for Office 365 users in the Office 365 portal. Alternatively, in Office 365 for enterprises, you can use directory synchronization to automatically provision users from the on-premises Active Directory. Either way, ultimately, credentials are generated and managed by Office 365.
Direct access URLs in Office 365
In this example, the Office 365 domain is contoso.com. The user accounts of the Office 365 users are in this domain.
Office 365 users can directly access their mailboxes at the following URLs:
- http://mail.office365.com
- http://outlook.com/contoso.com
Note As explained earlier, you can’t use "https" in the URL with mail.office365.com.
Top of page
Customized URL using a CNAME record in Office 365
When you create a CNAME record at the DNS hosting service for your Office 365 domain, you can provide users a customized URL to open their mailbox using Outlook Web App. For example, if your Office 365 domain is contoso.com, you configure a CNAME record so webmail.contoso.com redirects users to mail.office365.com. You can tell Office 365 users to access their mailbox at http://webmail.contoso.com. The CNAME record looks like this:
- Alias webmail
- Target mail.office365.com
The advantage of using a CNAME record for a customized URL is it’s easy to configure.
These are the disadvantages of using a CNAME record for a customized URL:
- It's not very flexible. A CNAME record can't directly point to a URL target such as http://outlook.com/\<domain_name>. The target must be a valid DNS host name, such as mail.office365.com.
- You can't apply SSL to the customized URL. However, even if you don't apply SSL to the customized URL, the sign-in page where users provide their credentials has SSL applied, and their credentials are encrypted at that point. In fact, access to all Office 365 services is protected by SSL, regardless of whether SSL is used in the URL.
Top of page
Customized URL using Web page redirection in Office 365
If you have a Web server that's publically accessible from the Internet, you can configure a Web site to redirect users to Exchange Online. For example, you can configure the Web site http://webmail.contoso.com to redirect users to http://mail.office365.com or http://outlook.com/contoso.com.
How do you configure the Web page redirection? That depends on the Web server you're using.
- For Internet Information Services (IIS) 7, see Configuring HTTP Redirection in IIS 7.
- For IIS 6, see Redirecting Web Sites in IIS 6.0 (IIS 6.0).
- For Apache HTTP Server, see Apache Module mod_alias: Redirect Directive.
These are the advantages of using Web page redirection for a customized URL:
- It's very flexible. You can configure the Web page to redirect users to a URL, and not just a host name. You also control how the redirection works. For example:
- Do you want the Web page to silently redirect users to Exchange Online?
- Do you want to briefly show users a customized status page before they are redirected to Exchange Online?
- Do you want to provide users an entire portal where they can access Outlook Web App by clicking a button or link?
- You can apply SSL to the customized URL. Note that if you do this, you have to decide what to do when users access the customized URL using http://. Do you want to automatically redirect them to https://? Or do you want the redirection to stop with an error stating that https:// is required?
The disadvantage of using Web page redirection for a customized URL is it can be more work to configure than CNAME redirection.
Top of page
Federated identity in Office 365 for enterprises
When you use federated identity in Office 365 for enterprises, users who have Exchange Online mailboxes can use their on-premises Active Directory credentials to access their Exchange Online mailbox and all other Office 365 resources. For more information, see Exchange Hybrid Deployment and Migration with Office 365.
Direct access URLs in Office 365 for federated users
In this example, the federated Office 365 domain is contoso.com. The user accounts and e-mail addresses of the federated Office 365 users are in this domain. For example, a user named Tamara Johnston has the e-mail address and identity tamara.johnston@contoso.com.
Office 365 federated users can directly access their mailboxes at the following URLs:
Note Federated users can't use http://outlook.com directly. The URL must contain the domain name, which helps determine where to send users for authentication.
Top of page
Customized URL using a CNAME record in Office 365 for federated users
When you create a CNAME record at the DNS hosting service for your federated Office 365 domain, you can provide users a customized URL to open their mailbox using Outlook Web App. For example, if your federated Office 365 domain is contoso.com, you configure a CNAME record so cloudmail.contoso.com redirects users to outlook.com. You can tell Office 365 federated users to access their mailbox at http://cloudmail.contoso.com. The CNAME record looks like this:
- Alias cloudmail
- Target outlook.com
The advantage of using a CNAME record for a customized URL is it’s easy to configure.
These are the disadvantages of using a CNAME record for a customized URL:
- The top-level domain of the CNAME record must match the federated Office 365 domain. For example, to use the CNAME record cloudmail.contoso.com, your federated Office 365 domain name must be contoso.com. You can't use the CNAME record cloudmail.fabrikam.com if your federated Office 365 domain is contoso.com.
- Be careful when you use subdomains in the CNAME record. For example, if your federated Office 365 domain is contoso.com, you can use the CNAME record cloudmail.contoso.com, but you can't use cloudmail.test.contoso.com. Likewise, if your federated Office 365 domain is contractors.contoso.com, you can use the CNAME record cloudmail.contractors.contoso.com, but you can't use cloudmail.test.contractors.contoso.com or cloudmail.contoso.com.
- It's not very flexible. A CNAME record can't directly point to a URL target such as http://outlook.com/\<domain_name>. The target must be a valid DNS host name, such as outlook.com.
- You can't apply SSL to the customized URL. However, even if you don't apply SSL to the customized URL, the sign-in page where users provide their credentials has SSL applied, and their credentials are encrypted at that point. In fact, access to all Office 365 services is protected by SSL regardless of whether SSL is used in the URL.
Customized URL using Web page redirection in Office 365 for federated users
If you have a Web server that's publically accessible from the Internet, you can configure a Web site to redirect federated Office 365 users to Exchange Online. For example, you can configure the Web site http://cloudmail.contoso.com to redirect users to http://outlook.com/contoso.com or http://outlook.com/owa/contoso.com.
How do you configure the Web page redirection? That depends on the Web server you're using.
- For Internet Information Services (IIS) 7, see Configuring HTTP Redirection in IIS 7.
- For IIS 6, see Redirecting Web Sites in IIS 6.0 (IIS 6.0).
- For Apache HTTP Server, see Apache Module mod_alias: Redirect Directive.
These are the advantages of using Web page redirection for a customized URL:
- It's very flexible. You can configure the Web page to redirect users to a URL, and not just a host name. You also control how the redirection works. For example:
- Do you want the Web page to silently redirect users to Exchange Online?
- Do you want to briefly show users a customized status page before they are redirected to Exchange Online?
- Do you want to provide users an entire portal where they can access Outlook Web App by clicking a button or link?
- You can apply SSL to the customized URL. Note that if you do this, you have to decide what to do when users access the customized URL using http://. Do you want to automatically redirect them to https://? Or do you want the redirection to stop with an error stating that https:// is required?
The disadvantage of using Web page redirection for a customized URL is it can be more work to configure than CNAME redirection.
Top of page
Special consideration for hybrid deployments
A hybrid deployment is a full-featured cross-premises messaging solution between Office 365 for enterprises and an on-premises Exchange organization. Some mailboxes will be in the on-premises Exchange organization, and some mailboxes will be in Office 365 for enterprises. On-premises mailbox users and Exchange Online mailbox users can't share the same Outlook Web App URL to access their mailboxes. However, you can use the on-premises Outlook Web App URL to educate Exchange Online mailbox users about the Outlook Web App URL that's appropriate for them. For more information, see the following topics:
- Configure Outlook Web App for an Exchange 2003 Hybrid Deployment
- Configure Outlook Web App for an Exchange 2007 Hybrid Deployment
- Configure Outlook Web App for an Exchange 2010 Hybrid Deployment
The recommended Outlook Web App URL strategy for hybrid deployments is a CNAME record in combination with the TargetOwaURL parameter on the Set-OrganizationRelationship
cmdlet as described in the hybrid deployment topics. The result is: when a user with an Exchange Online mailbox opens the Outlook Web App URL for on-premises mailbox users and attempts to access their mailbox, the login process stops and they’re presented with the Outlook Web App URL that they're supposed to use to access their Exchange Online mailbox. The Exchange Online users won't be automatically redirected to the URL for Exchange Online. They have to click on the link that's presented to them, and they also have the option to add the URL to their Favorites. Here's some additional guidance:
- The Outlook Web App URL for on-premises mailbox users must be different than the Outlook Web App URL for Exchange Online mailbox users. For example, if the URL for your on-premises mailbox users is http://webmail.contoso.com, use http://cloudmail.contoso.com for your Exchange Online users.
- Create the CNAME record as described in the Customized URL using a CNAME record in Office 365 for federated users section of this topic. For example, if your federated Office 365 domain is contoso.com, create a CNAME record for cloudmail.contoso.com that points to outlook.com.
- For the TargetOwaURL parameter on the
Set-OrganizationRelationship
cmdlet, specify a URL that contains the CNAME record for your Exchange Online mailbox users. For example, if the CNAME record for Exchange Online users is cloudmail.contoso.com, use http://cloudmail.contoso.com for the TargetOwaURL parameter value.
Direct access URLs in Live@edu
In this example, the Live@edu domain is contoso.edu. The Windows Live IDs of the Live@edu users are in this domain.
Live@edu users can directly access their mailboxes at the following URLs:
Note Currently, both URLs work equally well. However, future changes will most likely require that you use http://outlook.com/\<domain_name>. Why not get on board early?
Top of page
Customized URL using a CNAME record in Live@edu
When you create a CNAME record at the DNS hosting service for your Live@edu domain, you can provide users a customized URL to open their mailbox using Outlook Web App. For example, if your Live@edu domain is contoso.edu, you configure a CNAME record so webmail.contoso.edu redirects users to outlook.com. You can tell Live@edu users to access their mailbox at http://webmail.contoso.edu. The CNAME record looks like this:
- Alias webmail
- Target outlook.com
The advantage of using a CNAME record for a customized URL is it’s easy to configure.
These are the disadvantages of using a CNAME record for a customized URL:
- It's not very flexible. A CNAME record can't directly point to a URL target, such as http://outlook.com/\<domain_name>. The target must be a valid DNS host name, such as outlook.com.
- You can't apply SSL to the customized URL. However, even if you don't apply SSL to the customized URL, the sign-in page where users provide their credentials has SSL applied, and their credentials are encrypted at that point.
Top of page
Customized URL using Web page redirection in Live@edu
If you have a Web server that's publically accessible from the Internet, you can configure a Web site to redirect users to Exchange Online. For example, you can configure the Web site http://webmail.contoso.edu to redirect users to http://outlook.com or http://outlook.com/contoso.edu.
How do you configure the Web page redirection? That depends on the Web server you're using.
- For Internet Information Services (IIS) 7, see Configuring HTTP Redirection in IIS 7.
- For IIS 6, see Redirecting Web Sites in IIS 6.0 (IIS 6.0).
- For Apache HTTP Server, see Apache Module mod_alias: Redirect Directive.
These are the advantages of using Web page redirection for a customized URL:
- It's very flexible. You can configure the Web page to redirect users to a URL, and not just a host name. You also control how the redirection works. For example:
- Do you want the Web page to silently redirect users to Exchange Online?
- Do you want to briefly show users a customized status page before they are redirected to Exchange Online?
- Do you want to provide users an entire portal where they can access Outlook Web App by clicking a button or link?
- You can apply SSL to the customized URL. Note that if you do this, you have to decide what to do when users access the customized URL using http://. Do you want to automatically redirect them to https://? Or do you want the redirection to stop with an error stating that https:// is required?
The disadvantage of using Web page redirection for a customized URL is that it can be more work to configure than CNAME redirection.
Top of page