Getting out-of-office users securely connected to Exchange

With more users working on the road and from smartphones, here's how to connect them safely to their email, calendars, and contacts

Working out of the office is standard practice these days. But how do you support those users with secure connections? No matter what version of Exchange you use -- 2000, 2003, 2007, or 2010 -- I've come up with a formula to help you remember what you'll need to make the connections happen smoothly.

1. Choose an out-of-office connection method

First, there are several key ways to connect, including through a Web browser using Outlook Web App, through a mobile device using an ActiveSync connection, through Outlook over the Internet without a VPN connection (called Outlook Anywhere, formerly known as HTTP over RPC), and through POP/IMAP connectivity.

[ Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report. | Keep up on the latest Microsoft and Windows news with our Technology: Microsoft newsletter. ]

The decision is not as easy as I thought. Some companies, for example, do not allow ActiveSync connections. The reason? Everyone shows up with a different device type, and they all have different levels of ActiveSync control possibilities. Rather than fight with folks about their mobile device of choice, these companies just deny access altogether -- an interesting approach. Providing standardized mobile devices to all company employees is another possibility, but most users believe their mobile device is an extension of themselves and don't want to be tethered to company policy on its use (or misuse, in some cases). Considering the amount of data you can pull down to your modern smartphone, you can see how this might be a huge security risk for admins.

2. Configure your out-of-office method

The moment you install Exchange 2007 or 2010, you have out-of-office capabilities already set up for Outlook Web App and ActiveSync connections. Outlook Anywhere still needs to be enabled and POP/IMAP services need to be turned on, but for the most part you are easily up and running with any of these methods.

The configuration is typically handled through the virtual folder settings, which are, happily, not accessed through the Internet Information Services (IIS) Manager. I say "happily" because ever since IIS 7 came out with the new interface for managing IIS, I get lost finding configuration options. With Exchange, you don't have to open IIS unless you plan on configuring SSL for Outlook Anywhere or POP/IMAP.

Everything else is done through the Exchange tools and, more specifically (if you are working through the GUI Exchange Management Console), under Server Configuration and the CAS role settings, where you'll find the virtual folder settings that allow you to configure important aspects like authentication for Exchange. Here you can make adjustments from an OWA connection that uses forms over to a Windows Integrated connection. The same is true with other out-of-office connection settings.

3. Ensure client access

There are two keys to smooth client access. The first is making sure your DNS settings both internally and externally are configured properly so that people trying to access Exchange through a browser or mobile device (or other method) can do so. The second is ensuring you have certificates that confirm the server is who it says it is. That may seem like a security aspect -- and it is on a deeper level -- but it isn't directly connected to anything the user will note as security.

Essentially, you can use the self-signed certificate that comes with Exchange for some connections (like OWA), but users will then have to accept and trust that cert when they try to connect. It's not the most professional way to deploy the services, so you might look to a PKI internal certificate services setup using an in-house server or through a third-party trusted certificate authority. My personal opinion? The third-party certificate authority approach is easy and cheap (and won't give you headaches setting up a PKI server).

Exchange 2010 has a great new wizard that walks you through the certificate request. By working with a trusted certificate authority vendor like GoDaddy or VeriSign, you can obtain the cert, install it on the server, and provide your users a trusted connection that is verifiable (behind the scenes) by the certificate authority. You can use a wild card certificate (* or a Subject Alternative Name (SAN) certificate to ensure the different access methods are secure.

4. Validate access

You can validate connectivity easily by setting up the out-of-office solution and testing to see if you have any problems accessing from whatever browser, mobile device, and Outlook/mail client will be used, depending on which out-of-office form you've selected. In most cases, you will have multiple forms selected.

However, when your connection fails -- which happens more often than we'd like to admit -- you can perform some great validation tests through either the Exchange Management Shell with its test cmdlets or through a site called the Exchange Remote Connectivity Analyzer. The latter is a free tool provided by the Microsoft Exchange team to help you to validate your configuration and/or locate areas that are misconfigured.

5. Establish security settings through policies

Most of the security you will apply is handled on Exchange's Server Configuration level by working with your virtual folder settings under the Client Access role or through the Organization Configuration level through the Client Access role. It's under that Organization Configuration level or node that you will find your policy settings for Outlook Web App connections and ActiveSync. You can create many policies, but you can apply only one OWA policy and one ActiveSync policy to a specific user. It's best to figure out the various roles your company has for users and set up specific policies for each role. Next, determine which users have which roles and, thus, apply the appropriate policies.

These policies allow you to configure quite a bit in terms of functionality for users. For example, through the OWA policy settings you can enable or disable certain features. Let's say you don't want users to access their calendar in OWA; you can create a policy that disables calendar access, then lock down the calendar for affected users.

The same is true of the ActiveSync policies. You can configure more than 50 settings that enforce passwords and password policies, as well as allow or deny access to phone features like the camera or browser. These policy settings let you do the heavy lifting of securing your environment, but use them sparingly, so you're not tying users into needless knots.

6. Consider the future BPOS (aka Office 365) as a possibility

You may think, "Wow, this is more involved than I would like," though in my opinion, Exchange 2010 makes the process so much easier. But if you're looking for alternative solution to in-house Exchange, I recommend you consider Microsoft's cloud-based Business Productive Online Standard (BPOS) suite, which allows for connectivity through OWA, ActiveSync, and more, and it doesn't require any configuration on your part. Granted, your control is limited, but if you really need connectivity and not ultimate command and you are in a smaller environment, it's a good approach. And keep an eye out on its forthcoming sucessor, Office 365, which looks like it mght even bemore capable.

By the way, this week I'm speaking at TechMentor in Las Vegas, with the majority of my sessions focused on Exchange. That may have something to do with my recently being awarded the Microsoft MVP status. It's nice to be welcomed into the sacred fold of Microsoft MVPs for my community work in Exchange.

This article, "Getting out-of-office users securely connected to Exchange," was originally published at Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in networking and Windows at

Copyright © 2010 IDG Communications, Inc.

How to choose a low-code development platform