No, Not That Kind of Remote Access
Most of you Exchange folks are probably thinking, "This guy's an idiot; Exchange has great remote access." You're only partially right. Exchange does have decent remote access through protocols like POP3 and IMAP4, and Outlook Web Access (OWA) is definitely a nice tool, especially OWA 2000. But those types of remote access don't really give you your full mailbox. POP and IMAP are strictly for e-mail (and public folders, in the case of IMAP); OWA provides access to your calendar, but not really the full capabilities you get with Outlook. I don't know of anyone who can honestly say, "Oh, yeah, I gave up on regular Outlook; OWA is enough for me." OWA's lack of an address book look-up feature -- a perfectly reasonable lack, by the way, given the time it would take to transfer that kind of data to your Web browser -- makes it unsuitable for most users' full-time mail needs.

So what kind of remote access am I talking about? The real kind: Full Outlook access to everything Exchange has to offer, just like you'd get from the corporate LAN. Only remotely.

Past "Solutions"
OK, it's not like it's impossible to use a remote copy of Outlook to access Exchange. You just have to set up a virtual private network (VPN) connection to the corporate LAN, right? Sure, it works great because a VPN makes it seem as if the remote computer is really connected to the corporate LAN. You're not really achieving remote access; you're faking out the client so it doesn't think it's remote anymore. One problem with doing so is that Outlook tries to pull entire messages down when you open them, and for long messages, that can take a while. VPNs also encrypt everything, which reduces your effective bandwidth and makes the mail experience even less fun.

So why can't Outlook and Exchange do better?

The Real Problem
The real problem is that Outlook does its work through MAPI, Microsoft's Mail Application Programming Interface. And, sadly, MAPI uses RPCs, or Remote Procedure Calls, to do its work. Practically every Microsoft product in the universe uses RPCs for something or other; it's a very flexible protocol and really enables things like Distributed COM, or DCOM. DCOM, by the way, is a big part of MAPI's magic, too.

The problem is that all this DCOM/MAPI/RPC stuff is great for a local area network where bandwidth is high, latency low, and security isn't a concern. Over the Internet, though, RPCs just don't work out. There are a multitude of technical reasons -- which I don't have room to go into here -- that make RPCs an excellent protocol for LANs and a horrible choice over the Internet.

Okay, I will go into one technical detail: Exchange uses an RPC endpoint mapper. Basically, your client computer calls up Exchange on a predefined TCP port, like 135. Exchange then sends back a message telling your client to make its session connection on a completely different port, the RPC endpoint. Exchange can use dozens of different ports at once, and it distributes clients across them to help the server handle multiple connections more efficiently. This endpoint mapping is absolutely impossible for firewalls to deal with; You'd practically have to open up every hole in the universe. You can hack the Exchange server's registry to force all endpoints to go to a port you define; I don't recommend it, though. Yes, it makes Exchange traffic easier to pump through a firewall,but it also seriously reduces server efficiency.

Anyway, the fact is that Exchange 2000 Server and earlier could only provide MAPI access over RPC. That means you just couldn't use Outlook to connect to an Exchange server over the Internet. Not reliably, anyway, and certainly not securely. VPNs solved the problem because they make the remote client appear to be on the local network; my only beef with VPNs is that they can be a major pain to set up and maintain, and that they don't work with every ISP in the universe. I get my Internet over satellite, for example, from DirecWay (www.direcway.com), and VPNs are pretty much out of the picture without jumping through some amazingly complicated hoops.

So what's a better solution?

Titanium
The next version of Exchange, call it Titanium, Exchange Server 2003 or whatever else you'd like, has something its predecessors lack: Magic, otherwise referred to as. RPC over HTTP. This lets your computer neatly bundle RPCs inside easy-to-transport HTTP packets, which as we all know fly across the Internet smoother than Teflon. If you'd like the gory details about RPC over HTTP, go here (I warn you, though, it's pretty developer-centric stuff).

Now, RPC over HTTP isn't something you get for free from Titanium. Far from it, in fact. You have to have a special mix of software to make it all work: Titanium must be running on Windows Server 2003, and you have to be using Outlook 11 -- still in beta -- on Windows XP Pro, Service Pack 1. So this isn't a solution that'll be immediately available to the whole universe, but in my mind it's definitely a reason to take a good, hard look at these newer products, especially if you're in an environment that values remote access to Exchange.

To activate it on the client end, you'll have to dig a bit in Outlook's 11 e-mail settings. First, open your account properties, and then click on More Settings. Click on the Connection tab. At the bottom of the tab, there's an item called Exchange over Internet, which is where you turn on RPC over HTTP and configure a proxy, if necessary. This will all be grayed out unless you're running the right combination of software on both ends. Right now, my Titanium Beta 2 software is running on Windows 2000 Server, so no RPC over HTTP for me.

HTTP is easy to pass through a firewall; it's simply port 80. You can even use it on your LAN, so you can configure your users to work one way, and they always will (you'll need to publish your Exchange servers' names through public DNS, of course, so your remote users can find them). HTTP is easy to secure, too: Just slap an SSL certificate on your server and you've got up to 128-bit encryption, for free, with no further configuration. Nothing could be simpler.

Credit Where Credit Is Due
By the way, Outlook 11 itself contributes some hidden features to make RPC over HTTP more effective. In every prior version of Outlook, the client had to maintain a nearly constant connection to the Exchange server over RPCs. Even minor network hiccups could result in Outlook hanging while timing out looking for the server. I can't tell you how often I've been at Microsoft's campus and listened to otherwise polite Microsoftians swear at a hung copy of Outlook. Outlook 11, however, defaults to an offline condition, only synchronizing with the server every so often. This is, of course, what pretty much every POP3 and IMAP4 client has done since the beginning of time, but it's new and much appreciated in Outlook. Basically, your mail stays on the server, but a copy of it lives on your local computer, too. Outlook 11 works off of that local copy for the most part, and occasionally contacts the server to see what's new. If the server isn't available right then, Outlook 11 quietly shrugs its shoulders and tries again later.

Outlook 11 can also be configured to only retrieve message headers first, allowing it to quickly build your Inbox list even over a slow dial-up connection. Once the headers are in, it starts pulling down message content and file attachments. This behavior isn't noticeable on the corporate LAN because it all happens so quickly, but it's really sweet when you're dialed into your ISP from a hotel room that only works at a whopping 28kbps. The new message header feature is transparent and automatic, unlike previous versions' dedicated "work with message headers" mode.

This whole offline thing, along with message headers, really helps to accommodate the inherently disconnected nature of the Internet. It basically means that properly-configured remote users can use Outlook 11 just as they would from the office network, which is a huge, huge deal.

I Just Can't Wait!
This RPC over HTTP thing is going to be huge. Well, for a while, anyway. Eventually, I'd expect a lot of these problems to go away as Microsoft integrates more .NET Framework and Web Services stuff into Exchange. Things like SOAP (which used to be an acronym but now officially doesn't stand for anything) were built to do what RPC over HTTP does, and they do it with a lot more style and a lot less fuss. In the meantime, though, RPC over HTTP promises to solve a whole raft of issues, make full remote access to Exchange a zillion times easier, and generally improve the quality of life for Exchange users 'round the world.