Problem : Although OWA is installed by default with the CAS role, there is quite a
bit we can do to manage this aspect of Exchange mailbox access. What
options do we have and what settings can we configure?
Solution : For the most part, you can manage OWA through the EMC (or EMS) and the
IIS Manager. You can configure many different settings to provide a
customized solution or a more secure solution for your OWA experience.
Often the challenge is to know those solutions exist and then where to
find them.
Configuring the OWA Properties in the EMC
To begin with, if you want to locate the settings within the EMC, perform the following:
1. | Open the EMC.
|
2. | From the Navigation Tree, expand the Server Configuration work center and click Client Access.
|
3. | From the Work pane, select the Outlook Web Access tab.
|
4. | Notice the OWA (Default Web Site) option. Select it and choose Properties.
|
This takes you to a dialog with six different tabs. Let’s consider these.
General
The General tab
provides information: the server name, website, OWA Exchange version,
and last date modified. In addition, however, are two configurable
options for the internal and external URL to access the OWA site.
Keep in mind that you might
want to use an HTTPS connection for the external URL because you should
use SSL for security purposes.
Note
It’s hard to say if
these settings are more than informational. Essentially, you can put
whatever you like in here, but it is the IIS settings and DNS settings
that come together to provide your URL. However, just in case, you might
want to fill out this information. The Help file is not much help in
either case.
Authentication
The Authentication tab, shown in Figure 1, provides the capability to define standard authentication methods for your OWA connection or forms-based authentication.
If you select a standard authentication method, you can choose:
Integrated Windows Authentication—
Requires that the user has a valid account and password on a Windows
Server. Users are not asked for their account information, but the
negotiation is handled between the server and client, which should be a
member of the same domain (or be part of a trusted domain).
Digest Authentication for Window Domain Servers— Transmits passwords over the network as a hash value. This provides greater security.
Basic Authentication (Password Is Sent in Clear Text)—
Before sending the credentials, they are encoded and sent to the
server. SSL is recommended to provide encryption of the process.
The default option is to use forms-based authentication, which avoids popup windows but provides a web-based form, as shown in Figure 2.
You can make changes to the type of information requested from the forms-based logon by selecting one of the following:
Domain\user name— This is the default arrangement and requires a user to put his domain and username in the logon. So a user named JDillon in the PrimaTech domain would type PrimaTech\JDillon.
User Principal Name (UPN)— This is usually the same structure as the email address. So, a person would type something like jdillon@primatech.com at the logon prompt.
User Name Only— Doesn’t
require the domain name be included in the logon process. You can
select the Browse button to choose the Logon domain from which users
should come.
Segmentation
The Segmentation tab is a
great way to quickly see all the features included with OWA. It’s also a
great way to enable or disable features for OWA. If you establish these
settings on all users, you can still use the Set-CASMailbox cmdlet to provide different settings for individual users if you like.
By default, all these
settings are enabled. The features that you enable or disable here apply
to all users who access their mailbox through the virtual folder OWA
off the server you are configuring the settings on. So, you can have
different OWA connection points that have different segmentation
settings if you like. The settings you can enable or disable include the
following:
Exchange ActiveSync Integration
All Address Lists
Calendar
Contacts
Journal
Junk E-Mail Filtering
Reminders and Notifications
Notes
Premium Client
Search Folders
E-mail Signature
Spelling Checker
Tasks
Theme Selection
Unified Messaging Integration
Change Password
Rules
Public Folders
S/MIME
Recover Deleted Items
Public and Private Computer File Access
As you saw in Figure 7.3,
you have the option to choose if you access the OWA from a public or
private computer. Depending on which you choose, there are settings you
can configure. The settings on these two tabs are the same. As you can
see from Figure 3, they relate to file access and WebReady Document Viewing.
To begin with, we have
the Enable Direct File Access checkbox. Along with it is the Customize
option, which enables you to make some changes in how direct file access
works.
Note
What is direct file
access? This feature provides users with the capability to have access
to read files that are in email attachments or on SharePoint libraries
and shared files that are connected with OWA.
With configuration
options, you can define both file extensions (such as .bmp) as well as
MIME types (such as image/bmp). To customize the process of handling
attachments, you can choose the following options:
Always Allow—
Click the Allow button to select which file types can always be
accessed without saving to disk. The options provided here will override
all other settings. If you say a file type is allowed but it is blocked
in the Always Block settings, it will be allowed.
Always Block—
Click the Block button to select which file types can never be
accessed. The options provided here will override the Force Save
options.
Force Save— Click the Force Save button to select which file types must be saved to disk before being opened.
Unknown Files—
Select the drop-down arrow to choose what should be done if a file is
unknown. You can Allow, Force Save (the default), or Block.
Another group of
settings is the WebReady Document Viewing checkbox. This allows known
document types (Word, Excel, and so on) to be displayed within the
client without the application installed on the local machine. This is
truly an incredible tool for those who travel and find themselves in
Internet cafes all the time; now they can view documents without having
to worry if the location has that application on the system.
In addition, now the
user doesn’t have to worry about saving the document locally to open it
(which can be a problem technically or from a security perspective) and
can read the document from the OWA browser.
By default, the
option Enable WebReady Document Viewing is enabled. You can choose to
enable the other setting Force WebReady Document Viewing when a
converter is available. This setting overrides the direct file access
settings for a document.
Selecting the
Supported button brings up a dialog where you can see all supported
document types and determine whether there are some you wish to add and
others you wish to remove.
Note
WebReady
Document Viewing has a limit of 5MB for files that it will display in
HTML. It also has some limitations on displays of certain advanced
Office 2007 charts and other application features. There is a way to
override the 5MB limit, however. You can enter the registry and go to
the HKEY_Local_Machine\System\ CurrentControlSet\Services\MSExchange OWA and create a new key called WebReadyDocumentViewing and create a DWORD setting called MaxDocumentInputSize.
You can then place the limit in KB and restart the World Wide Web
Publishing Service. Don’t make the setting too high, because you can
cause the CAS server to suffer performance loss.
The final two checkboxes
on these tabs are under the heading Access Files From the Following
Locations on Remote File Servers: with the options Windows File Shares
and Windows SharePoint Services.
Remote File Servers
The Remote File Servers
tab works in harmony with the direct file access settings because you
are configuring the servers that you want to allow access to for
clients. You can specify servers that are specifically allowed or
blocked access. If there are unknown servers, you can specify if they
are blocked or allowed, too. You can enter the domain suffix for sites
whose FQDN names are treated as internal by selecting the Configure
button.
The basic rule
is that only internal SharePoint Service servers and file share servers
can be accessed with remote file access. Internal servers can be
accessed by their host names or FQDNs. OWA uses a simple method to
figure out whether a server is internal. If the URL provided had dots in
it, it is considered external and not accessible (unless the domain
suffix has been added to the list of sites you can configure for the
domain suffix). If there are no dots, it is considered internal.
PS Note
There are two
primary sets of cmdlets to administering OWA. The first is the server
side to the configuration options, which is the OWAVirtualDirectory cmdlet (using various verbs such as Set, New, Remove, Get,
and so on). Although that cmdlet is geared toward the server
configuration side, the user configuration side for OWA is handled
through the Set-CASMailbox cmdlet.
Using the IIS Manager to Simplify the URL for OWA
It is common for
administrators to want to alter the process for users to log in to the
OWA site. One way to do this is to use the IIS Manager to alter the way
the site is accessed. Keep in mind however that IIS is different between
Server 2003 and Server 2008. In 2003, it is IIS 6.0. In 2008, it is IIS
7.0 (which is different to work with).
If you want to simplify the URL through Server 2003 IIS 6.0, perform the following steps:
1. | Select Start, Administrative Tools, and then select IIS Manager.
|
2. | In the Navigation Tree, expand the server, Sites, and Default Web Site.
|
3. | Right-click Default Web Site and choose Properties.
|
4. | Select the Home Directory tab.
|
5. | Make sure the radio button A Redirection to a URL is selected.
|
6. | In the Redirect To field, type in the directory (for example, https://www.primatech.com/owa).
|
7. | Then in the The Client Will Be Sent To field, select the option A Directory Below URL Entered.
|
8. | Then complete the configuration to the correct OWA folder from the Application settings.
|
Doing the same thing in Server 2008 under IIS 7.0 is not as straightforward. To redirect, perform the following:
1. | Select Start, Administrative Tools, Internet Information Services (IIS) Manager.
|
2. | Make sure you have Default Web Site selected.
|
3. | On the Features view of the Default Web Site, double-click Error Pages.
|
4. | In the Actions pane, click Edit Feature Settings, and under Error Responses, select Custom Error Pages. Then click OK.
|
5. | In the Actions pane, click Add and configure the following:
|
6. | Next, double-click the HTTP Redirect icon.
|
7. | Select the option Redirect Requests to This Destination: (shown in Figure 4), and type the absolute OWA URL: https://www.primatech.com/owa.
|
8. | Under the Redirect Behavior section, select the option Only Redirect Requests to Content in This Directory (Not Subdirectories).
|
9. | From the Status Code drop-down menu, select Found (302).
|
10. | Click Apply to save the settings.
|
11. | Then, you can run the IISRESET /noforce command in CMD for the settings to take effect.
|
Note
If you do not see the HTTP
Redirect icon, you might not have that service installed. Return to
your Server Manager and check to make sure this service is selected with
the other options you selected when you installed IIS.
Configure SSL and Certificates
When you install the CAS
role, a self-signed SSL certificate is created using the NetBIOS name
of the server. This allows you the capability to use SSL within your
internal network. (Note: SSL is enabled by default on your OWA
connections.) That certificate, however, is not qualified to be used for
external connections.
The client attempts
to connect, and the server presents the self-signed certificate with no
third-party validation. The client waits for the user to explicitly
trust that the connection is okay. Although it works, users are prompted
with certificate warnings, the browser address bar glows red
(indicating something isn’t right), and there might be problems with
mobile clients connecting. In addition, it doesn’t look professional.
You
need a third-party certificate. In the past, this would be a simple
process. You would contact any agency that offers them and then you are
off and running.
The difficulty here is
that two services require the certificate: OWA and the Autodiscover
service. So, you might begin to question whether you need two
certificates or whether you should have separate IP addresses.
You can employ many different solutions, and it is your choice in the end. Here are some of the solutions to the SSL dilemma:
Subject alternative certificates—
Not supported by all certificate authorities, this solution enables you
to use one certificate, one website, and one public IP address. If you
want to use mail.yourcompany.com, autodiscover.yourcompany.com,
and a group of other names, you can do that. After you have your list
of names, you can create a certificate request using the New-ExchangeCertificate cmdlet.
Two single-name certificates—
Here you would purchase one for Autodiscover and one for OWA. You would
need two websites: public IPs and pay the cost for two certificates.
However, it still might be cheaper than a multi-named certificate
depending on prices.
Single-name certificate with HTTP redirection—
In this case, you require two websites and two public IP addresses.
When the redirection occurs, the users will be asked if they trust the
redirected URL (which defeats the purpose somewhat).
Unified Communications Certificate—
One solution is to find a certificate authority that will provide you
with a Unified Communications Certificate (also called a Subject
Alternative Name Certificate [SAN]) with multiple names in one
certificate. So, you can request autodiscover.yourcompany.com,
mail.yourcompany.com, and other names you need.
Other creative solutions
involve complex configuration at times or simply leaving the self-signed
certificate (which isn’t a valid option for long).
After you have your certificate, what do you do next?
You use the Exchange Management Shell to import the certificate using the following command:
Import-ExchangeCertificate -path “path to the certification file”
Next, you need to enable it by typing
Enable-exchangecertificate
If you wanted to enable it for a variety of services, you can use the -services parameter with the IIS, POP3, IMAP, SMTP, or Unified Messaging (UM) services included.
You are next asked for a
thumbprint, which should have been displayed when you imported the
certificate. If you don’t see it, you can type Get-ExchangeCertificate and locate the thumbprint.
That
installs your certificate and enables it. You should be set, especially
for the next topic, ActiveSync, because ActiveSync does not work if you
are trying to use a certificate that is not trusted by the device.
