Concepts and Management of Outlook Web App and ActiveSync
In this post, first, we will explain virtual directories and how they are related to the CAS services.
Next we will help you understand Outlook Web App (OWA) and ActiveSync features.
Last, we will use a Scenario to help guide us in the creation and application of OWA and ActiveSync policies.
Scenario: OWA and ActiveSync Management
First, we will help our IT team gain a greater understanding of OWA and ActiveSync.
Next, we will perform the following OWA management tasks:
Adjust the authentication for the virtual directory to allow for Integrated Windows authentication. This allows for single sign-on for internal clients.
Disable WebReady Document Viewing for the virtual directory.
Create an OWA policy and apply it to a researcher user “Alex Heyne” that will ensure he only uses OWA Lite.
Finally, we will do the following ActiveSync management tasks:
Block “Unknown Servers” from the virtual directory.
Create an ActiveSync policy and apply to all users in the Chicago OU.
Virtual Directories
Web applications are represented by virtual directories that point off toward physical folders.
For example, Exchange Outlook Web App has an OWA virtual directory that points off to a literal folder on your system.
You access the virtual directory through its virtual directory name, not its physical folder name (although the two may be the same.)
You can see virtual directories in IIS and also quickly find the physical location on your system through the Properties of the virtual directory.
Although you have default virtual directories created for you when you install the CAS role, you can create additional virtual directories if you like.
In the EMC, go to Server Configuration -> Client Access. Here you will find owa (Default Web Site). Looking at the properties of OWA, we can see both the internal and external URL’s, as well as a number of tabs used to configure OWA.
Click Image to Enlarge
Each of the options in the tabs is part of IIS on the client access role. For the most part, if you want to see the location of the virtual directories and their physical location on the server, we would need to open ISS:
Click Image to Enlarge
Here, take note that some of the sites are considered Virtual Applications (highlighted in red), as opposed to Virtual Directories (highlighted in green). Sometimes you’ll need to use IIS to configure things like SSL.
But for now, lets look more into OWA in the EMC.
Virtual Directory Settings vs. Policy Settings
Virtual directory settings are made through the Server Configuration node
Some virtual directory settings are only found under the Server node, whereas others may be configured in a policy as well.
Policies are created under the Organization Configuration node
Policies override virtual directory settings
There are default OWA and ActiveSync policies create
Only one policy (one for OWA and one for ActiveSync) can be applied to a mailbox at a time and if no policy is applied, the virtual directory settings apply.
Understanding OWA Features:
Virtual Directory Property Tabs:
General
Authentication
Segmentation
Public and Private Computer File Access – WebReady Document Viewing
Remote File Servers
Policy Setting Tabs:
General
Segmentation
Public and Private Computer File Access – WebReady Document Viewing
Note: Public and Private Computer File Access provides two tabs but you cannot have different settings on each one.
In the EMC -> Server Configuration -> Client Access -> OWA Settings for this virtual directory.
General Tab: shows internal url and external url (informational) -config is actually in DNS
Authentication Tab: Use forms-based authentication. Logon format – Domainusername is secure but not completely secure without SSL.
Use one or more standard authentication methods:
-Integrated Windows Authentication. The client computer has to be a member of the same domain or in a trusted domain.
-Digest authentication for windows domain servers (users have an account in AD)
-Basic authentication (password is sent in clear text). Can be used in a secure way if you use SSL.
Segmentation Tab: you can determine if you wan to enable or disable certain features.
For example “Premium Client” is the full version of Outlook Web App. You can choose to use a “Lite version” of OWA. You can force the lite version of OWA for users of Firefox or Safari. You can disable things like Instant Messaging and Text Messaging.
Public Computer File Access tab:
-Direct File Access – determines how files will be allowed or denied access. If you connect on a “Public” computer, you can enable or disable the ability for users to open file attachments. Direct File Access allows you to allow or block or Force Save of even unknown files.
-In the Private File Access tab: same exact settings as above.
WebReady Document Viewing: allows OWA documents to be converted to HTML and shown in the browsers. You can force docs to be changed to HTML before being opened in a supported application.
You may not want a certain document to be shown in the browser. This provides an opportunity for users to view the document at least even if they don’t have a supporting application.
Remote File Servers Tab: you might want to allow or block file servers here. You can enter the domain suffixes that should be treated as internal.
You have an opportunity to use Policies to override the settings placed on the virtual directory settings.
Under Organization Configuration -> Client Access role.
Provide a new policy name. Enable/disable features -> New. Now after creating the policy, go back and open up the policy. You will have more features available now that the policy has been created. It’s important to consider these items again. If you do not enable direct file access, users will not be able to download attachment files.
Once the policy has been created, you need to apply the policy. Take for example, you wish to apply a new policy to an individual user. Go into Recipient Configuration, pick the mailbox, go to Mailbox Features tab -> Select OWA ->Properties. Now you can choose an OWA mailbox policy to take precedence over the virtual directory settings.
Outlook ActiveSync Features:
Virtual Directory Property Tabs:
General
Authentication
Remote File Servers
Policy Setting Tabs:
General (Allow non-provision-able devices -this allows mobile phones to sync even if they do not support policy settings)
Password
Sync Settings
Device
Device Applications
Other
Note: Some features require Exchange Enterprise Client Access Licenses for mailboxes that have policy setting restrictions
Go to the EMC ->Server configuration -> Client Access -> Exchange Activesync tab properties.
Password tab -> many options here for passwords (length, expiration, require encryption, etc.)
Sync Settings -> Include past calendar items, Include past email items, Allow Direct Push when roaming (you can force it so that roaming users will not get Direct Push). Allow attachments.. etc.
Device tab -> Allow removable storage, allow camera, allow wifi, allow infared, allow bluetooth etc.
To block unknown servers from the virtual directory (by default is allow), go to the EMC -> Server Configuration -> Client Access -> Exchange ActiveSync Tab -> Virtual Directory Properties. Go to the Remote file servers tab -> Unknown servers by default is set to allow. OWA has the ability to access file shares and SharePoint libraries. If there are no dots in a URL a user clicks, it is considered internal. If there are one or more dots in the URL, then it will only be considered internal if the domain suffix has been added to the configuration.
The following Exchange Management Console Shell commandlet will apply a custom activesync mailbox policy to the OU Chicago:
Get-Mailbox -OrganizationalUnit Chicago | Set-CASMailbox ActiveSyncMailboxPolicy “ASChicago”
So in this post, we reviewed:
The feature settings for Outlook Web App and ActiveSync
Both virtual directory settings (found under the Server Configuration node) and policy settings (found under the Organization Configuration note)
Made virtual directory adjustments and created policies and then applied those to users within our organization using a powershell commandlet.
A good majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com
In this post, we will review the purpose of the Client Access Server (CAS) Role in Exchange 2010.
We will discuss the following CAS Role aspects:
Outlook Web App
Exchange Active Sync
Outlook Anywhere
POP3 and IMAP
The Availability Service
The Autodiscover Service
Take for example the scenario: a Team Meeting to Discuss CAS role
The more mobile your users wish to be, the more the CAS Role comes into focus
You most likely will have mobile users that want to connect to Exchange using their browser, mobile, smart phone or tablet, through Outlook or some POP/IMAP oriented mail application
The role of an administrator is to ensure connectivity from any remote location, and that connectivity is provided without compromising security
The Evolution of CAS
Exchange 2000/2003 didn’t have CAS servers, they had “Front End” servers
– With “Front End” servers, internal clients connected with Outlook using MAPI. MAPI is “Messaging Application Program Interface” – it allows you to send email with Outlook. MAPI is the protocol Outlook uses to connect with Exchange. Internal Outlook clients connected directly to Mailbox servers using MAPI over RPC.
– External clients used the “Front End” as more of a proxy that could handle RPC over HTTP (for Outlook Anywhere), HTTPS (for Outlook Web Access, or OWA), and POP/IMAP. Clients connect in, provide credentials, and the Front End server would decide which mailbox to connect.
Exchange 2007 introduces the CAS role which is more than a proxy server but offloads a significant amount of the load that the mailbox servers typically handled
– Internal MAPI clients still connect directly to the MB role. In 2007, The Client Access Role started to handle middle tier of a three tier application (the logic tier).
Exchange 2010 introduces a new service (MSExchangeRPC) so that the CAS Role is “true” middle tier. It now takes on the brunt of the work that the MailBox Role had to do in the past.
The Exchange 2010 CAS Role is Middle Tier
In Exchange 2010, the CAS Role handles both external and internal connections to the Mailbox role; with the exception of Public Folder connections. So whether they’re coming from OWA or Outlook inside the LAN, they will both go through the CAS Role.
MAPI and directory connections are handled by thte CAS server now, relieving a ton of load off the Mailbox server role, and ultimately increasing the number of concurrent connections to a Mailbox server (in Exchange 2007, we had 64K and now we have 250K).
By offloading the CAS features, now we have a lot more responsibility with CAS, so we need to ensure load balancing and CAS Array concerns as well as security concerns are met.
CAS Role Aspects
Outlook Web App: Allows you to access email through a web browser (including IE, Firefox, Safari and Chrome). This used to be called “Outlook Web Access”. The biggest change that users appreciate is that it works in different browsers on the same level. It is handled by the CAS Role and IIS
Exchange ActiveSync: Allows you to synch your data between your mobile device or smart phone and Exchange – There are varying levels of ActiveSync support in devices and one key security element is remote wipe, which is not available for all devices.
Outlook Anywhere: Allows you to connect to your Exchange Mailbox externally using Outlook (RPC over HTTP) without going through a VPN connection. Its great for Outlook at home with the “In-house” experience.
POP/IMAP support – Mail clients other than Outlook (e.g. Mozilla Thunderbird/Live Mail) that connect with POP or IMAP are supported through the CAS role.
Availability Service: Shows free/busy data to Outlook 2007/2010 users.
Autodiscover Service: Helps Outlook clients and some mobile phones to automatically receive profile settings and locate Exchange services.
Looking at the Exchange Management Console:
Under Organization Configuration, you can make changes to the Client Access Role:
At this point you have two options, modify the default policy of Outlook Web App Policies or the Exchange ActiveSync Mailbox Policies.
As an administrator you can control functionality of the user experience and even the devices connecting to the CAS.
Is modifying the following options a good or bad April Fools joke to play on your User’s smart phones?
Click Image to Enlarge
Click Image to Enlarge
Maybe not such a good idea to mess with these…
Client Access under the Server Configuration Node in the EMC, provides us with much more configuration options.
Some of the different tabs located here are:
Outlook Web App – Config changes to owa Default Web Site
Exchange Control Panel – connected with IIS ecp default web site
Offline Address Book Distribution – If you recall we talked about the OAB now being distributed through web services
Outlook Anywhere – in a future post we will hit the “Enable Outlook Anywhere…” feature and go through it’s configuration.
So in review we’ve explained the purpose of the Client Access Server roles, discussed the different CAS features, and toured the EMC locations for working with the Client Access Service.
A good majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com
