Exchange 2010 Architecture: Microsoft's Adam Glick Talks About EAS

You've probably seen the fancy Exchange Server 2010 Architecture Poster put out by the Microsoft Exchange Server team last October and which you can download from the Exchange Team Blog. Many admins have wondered how to get a printed copy of the poster. Well, Windows IT Pro subscribers will be receiving a full-size, full-color reproduction of the poster with the March 2011 print magazine, courtesy of the Exchange team.

I've recently had the opportunity to talk with several members of the Exchange team to get a deeper technical understanding of some of the features represented on the poster, and I'll be presenting those interviews for you here. First up is Adam Glick, a senior product manager on the Exchange team, who spoke with me about the role of Exchange ActiveSync (EAS) and other techniques in Exchange for controlling smartphones and other mobile device connections.

BKW: To start with, can you just give us a good, basic definition of EAS—what it is and what it does?

Adam: Exchange ActiveSync is a protocol for syncing your email and PIM information. That's kind of the easy, succinct way to put it. What that really means is that you get—we called it AUTD, Always Up-To-Date—that's what we called the feature when we rolled it out. That was in the Exchange 2003 SP2 timeframe.

When people were taking their phones and trying to connect to email servers, they were using things like POP or IMAP, which are polling technologies. So their phone, every 15 minutes or 30 minutes, whatever they set it to, would go and grab that information. And we've changed that by making the ability for the server to just send the mail to the phone directly when it's there, and that connection can be maintained. So the way that ActiveSync does that is by using the technology in the modern version of ActiveSync called a hanging sync. What it does is there's actually some intelligence that says, "How long can you keep a connection open before it gets shut down by a firewall, by the carrier, by the device?" So basically it tests it, and then it sets the time that it will wait to keep the connection open to that time. So It figures it out and whatever that timeframe is—let's say it will keep the connection open for 30 minutes before it closes it off and drops the connection—so at 29 minutes, it will basically send a ping and say, "Hey, I'm still here," and reset that clock.

It always keeps the connection open without really using any data across that line. Because that connection is open, it's able to send messages across. So as soon as the email server gets an email or a calendar invite or an update to a contact, those are immediately sent out to the Exchange ActiveSync device. So that was a novel way to make sure that you had real-time email and PIM capabilities while making sure that you weren't constantly using data or making users wait 15 minutes to get that information.

The pieces that go beyond email are the ones that really separate it from POP and IMAP, which have no email or contacts capabilities. In the modern versions of ActiveSync, you also have Tasks and Notes, and then obviously additional metadata things like marking something as high importance or putting IRM \[Information Rights Management\] protection on a message. All these are things that are unique to Exchange ActiveSync and not available in other mail-linking protocols that people tend to use. That's kind of a fast overview of Exchange ActiveSync, why people use it, what the value is, in terms of technically.

In terms of market space, people use it because it's an openly licensed standard. If you buy any smartphone that's on the market, there's an Exchange ActiveSync solution for it, and in most cases that Exchange ActiveSync solution is built in. So if you go down to AT&T, or T-Mobile, or Vodafone for that matter, and you take a look at their smartphones, the only ones you'll find that don't have it built in are in most cases the BlackBerrys, which have two third-party solutions that are available, and obviously BlackBerry has its own solution that they provide users \[BlackBerry Enterprise Server—BES\].

So it's a fairly universal standard. For IT pros, it also provides additional benefits that other mail-syncing standards don't provide around policy control. We've talked before about the ability to block and limit what comes into an enterprise, but policy control is about controlling the devices that you choose to allow into your organization. These policies are things everywhere from ensuring that people use a PIN, how long that PIN is, how complex it is—is it just numbers or is it numbers and letters? Is there encryption enforced on the device? Is the main memory, is it a storage card, if storage cards are allowed? Do you allow certain other functionality on the device—for instance, can you Bluetooth tether to the device? Can you use the device to tether to a computer?

These are features that we built in based around the questions asked from IT pros who were concerned with people circumventing corporate networks. So when people ask, you know, what does tethering have to do, or what good is blocking Bluetooth, the reason was because there was concern from IT pros. We talked to them: "How are you worried about these phones when they come in your enterprise?" They said, "Well, I know how my network is protected. I've got my firewall. I've got my monitoring systems in place. But if someone takes one of these phones and tethers it to their work computer, all of a sudden they have a totally different channel that they can take information from that I have no eyes on." And so you can have the ability, if you wanted to, to lock those things down—that's where a lot of these policy pieces came in.

Same thing with blocking cameras. For certain organizations, they wouldn't allow cameras in at all, and when camera phones started to get popular, it became a big concern. We said, hey, we can always put a policy on them. Phones can be connected, you're going to allow that device, but the camera doesn't work. You can effectively create that same outcome. Certain organizations want that, certain ones don't.

There are 52 policies in total. About 49 of them are exposed to users. The others are used by just the server itself. These policies are what IT pros told us were what they needed to secure their organizations. We think of organizations all the way from people who just let in everything, they don't care, to organizations that want to lock out stuff, that are very security-conscious. We talk to them about what they need. You don't hear it as much anymore—but there used to be a big debate around policies. People used to say, "I have so many policies—you've got 25, I've got 40. You've got 45, now I've got 65." So there was this kind of arms race about policy numbers. People didn't stop to ask which features are the ones the people actually need.

The way I usually communicate this to people is that policies are like pounds: More isn't always better, and you always want them in the right places. So we talked to our IT pros and said, where are the places that you needed, what are the things that you actually want? By doing that, we avoid some of the confusion with certain other organizations that would say, "We're just going to put in every policy under the sun." That actually became a confusion point for a lot of IT pros. So our goal was, let's make this simple for people to administer, powerful to give them the control they want, and free enough to let users make the decisions about what devices they wanted while protecting IT pro infrastructure. That's probably the quick overview of it all.

BKW: Within the last couple of years, there's been a real explosion of consumer-oriented devices, with users asking IT departments to support those devices. How is user choice of devices affecting what policies IT pros are asking for?

Adam: We've seen the same trend of the consumerization of IT, and it varies by organization. But we do see a growing number of people bringing devices in, which we think is great because one of the things with ActiveSync in being licensed across all devices is that it's what Gartner calls the de facto standard. Everyone looks at ActiveSync, and if you've got Exchange ActiveSync, then you know you have the capabilities there.

From the IT standpoint, what we saw probably starting a year and a half ago or so was real concern that as you had this explosion of the Exchange ActiveSync devices on the market that the level of security control they provided was wildly different. So organizations were forced into these situations of either putting out a lot of rules—that they only support X devices and blocking people from being able to use anything else—or supporting them, and essentially going below where they were comfortable in terms of their security threshold—being forced to kind of reevaluate where they draw the bar.

What we've seen over the past year and a half is that pendulum is swinging a little back. Organizations have been asking \[vendors\] for those features and things that have not been meeting the bar for what they considered necessary—to put those feature sets in. We've been working with vendors as well to say these are things that we know are important so let's talk about how we get them into your implementation.

We've seen organizations start to realize the value of the data that's on these devices as more and more users get them. If you roll back a few years, you had 12 to 20 percent of users \[on mobile devices\], depending on the organization, the size, who their users are. Now it's predicted that a year, two years from now, it's going to be 50 percent of all users. So you're seeing a real shift in terms of the number of them, and so the concern about the data that's stored on them, how much storage space, is starting to become real, and the desire to control those pieces is real for IT pros. We already provide those controls. But getting the EAS licensees, the device manufacturers, to build those in—we work closely with them. They're also hearing it from the IT pro community, that they want those pieces.

So you're seeing the pendulum flip backward toward giving organizations control. I think we'll continue to see that movement. We saw it go really far to one end, and I think we'll see it move—well, we have seen it move back, and I think we'll continue to see it move back. People will look for more and more solutions that are not painful for users but allow organizations to be able to control the assets that they know are available on these devices.

As you see these stories about someone losing a device, and there's all sorts of information on it—that scares us, and rightfully so. They're looking to protect those things. I think they'll find the middle ground. I think the device manufacturers will bring \[their level of protection\] up. We're working with them.

We've also spent some time putting together things like the resources that we have online with Exchange ActiveSync about which devices or which operating systems actually support which features, to educate IT pros. One of the biggest questions we got was, "Oh my god, there's all these things out there, I don't even know what they support." Maybe the manufacturer tells you, maybe they don't. Trying to answer those questions was a real big question mark and still somewhat of a pain point for IT pros. We have a number of steps that we're working on to help IT pros along that path. The first step was putting together the wiki page and putting that out there so that the community could share the information they have, we could put in the information that we have, and people could have some sort of resource to make informed decisions for their organizations.

BKW: Right, I've seen the wiki page, that's the "Comparison of Exchange ActiveSync Clients" page on Wikipedia, which is a really useful resource. One of the biggest pain points still for IT pros, which is highlighted when you look at the chart on that page, is that some of the biggest features they need aren't being implemented by all the device makers—even when they are available to be used by the mobile OS. Why is it that some of the handset makers aren't using all of the policies that they're licensing?

Adam: Exchange ActiveSync at the moment is a patent license. So what that means is that once they license the package to use the protocol—all the documentation is publically available already—we don't control what they do. We can't mandate: You must do this. We talk to them about what we know are the needs of our IT pro community, but it's their product, and they make the decisions about whether they want to implement something or not. If you take a look at, say, just the last three years of the space, you can see there's a consistent move by all of the players, all of the Exchange ActiveSync licensees, to add more of those enterprise features—and when I say features, not just features in terms of end-user-exposed features but policy control features.

If you take a look across the spectrum, the easiest example would be that encryption showed up on the iPhone—that was a big deal for Apple in unlocking some of their enterprise pieces. Google, although they didn't tout it in their announcement this week, Honeycomb added encryption APIs for the first time into Android. Obviously, Windows Mobile had encryption back in the Windows Mobile 6.0 days. As you look at it, these pieces tend to come in, they tend to trickle in. If people want to make a big deal about it or not is more of a marketing decision on their part. But there is a consistent movement over the past three years to add more of these features.

I hate to use Apple as an example, but they're an easy one that everyone is familiar with. Every release that they've had of their operating system since the second one, which introduced Exchange ActiveSync, has added more Exchange ActiveSync features for policies. Android ever since 2.0 has done it. Obviously, Windows Phone and Windows Mobile have had ActiveSync since the get-go. Palm's first update, when they came out with their first update to WebOS after they were bought by HP, was an EAS update.

We see people come out with a device, they get feedback very quickly, and with every update we see them adding those features in. Sometimes people are limited, sometimes doing some of these things, doing them right, is a difficult programming challenge, depending on what their platform is and what things are built in to it. But what we've seen over time is that every one of them keeps adding these pieces because this is what enterprises want.

BKW: I know you might not be the best person to answer this question, but I have to ask: Why isn't EAS better implemented on Windows Phone 7? I've seen a lot of complaints about features such as device encryption not being supported, and as a result businesses not being able to implement the platform.

Adam: I obviously really like my Windows Phone 7. In terms of what decisions the Windows Phone team made for what pieces they built in to their initial release and what pieces they didn't, it's really a question for the Windows Phone team. I'm not involved in those discussions. All I can do is speculate, and that's not very useful. I've seen the feedback, and I know they've heard the feedback as well. I can't talk about what their roadmap is or what their decision making process is.

BKW: Sure. One of the other things I know you wanted to talk about was blocking by UA string. What is that?

Adam: So, UA string is "user agent." When people think about mobile being a significant way that data goes in and out of their enterprise, they look for ways to be able control that. The Allow/Block/Quarantine list is certainly our most advanced, most recent way to put that control in. The ABQ list uses information that's passed along by the device. In some cases, there are some people who try to cheat that. What people usually don't cheat is when somebody uses a web browser. When you send across HTTP headers, there's a thing called user agents, and the user agent identifies what device you're using. This is pretty important for mobile devices because it tells websites to format their pages in mobile-friendly designs.

HTTP is part of the protocol that some of the EAS traffic goes across so we also get a user agent string. Some people, rather than taking a look at a device family or device type as reported in Exchange ActiveSync, want to be able to filter by how the user agent string of the phone identifies itself. This is useful when people want to do things like not filter an entire device out but filter out by a particular version. User agent strings tend to give even the version number. Say for instance you had a Nokia E72 and you wanted version 4.0 to be allowed because it had a new fix in it, but version 3.5 didn't meet the requirements of the organization so you want to filter that one out. If you want to be able to do that, using user agent filtering would be a way that you could do it. So it's another way to give organizations control of what devices come in and out, and you can control based upon version number as opposed to taking a look at just what the device is and how it reports.

Adam (cont.): It also allows you to look at other things. Sometimes devices by the same manufacturer will all just say the same thing. You might see something like "motodroid." Motorola makes several Android-based devices—which device is it? Maybe you want to allow ones that are running version 2.1 or 2.2, but you don't want to allow ones that are running 1.6. Something like that. So user agent string filtering gives people the ability to block devices upon that particular criteria—another set of criteria to block or allow devices.

That's something that's applicable to Exchange 2010 but also earlier versions of Exchange because the filtering doesn't actually happen at the Exchange layer. It happens at other layers in their infrastructure—either at their Microsoft Internet Information Server layer through an ISAPI filter or a plug-in, or through their ISA server, filtering there. This is also the place where people can do filtering based on IP address. There are certain services out there that use a data center or a network operations center to connect to people's mailboxes to pull mail out, but they pull mail without pulling policy or controls. It's another way that people try to circumvent IT pros. You want to be able to stop those folks and say that if you're going to connect to mail, you're going to pull this information. We need to be able to control it. You can block by IP address, which is the same way you'd normally do it based on a firewall.

BKW: So, thinking about the Exchange architecture poster, where in the Exchange architecture are EAS controls? Where do they come into play?

Adam: All of the Exchange ActiveSync functionality lives in the Client Access server, the CAS server. Give me a second and I'll grab a copy of the poster. Normally I have it ingrained in my head, tattooed on my skin. I'm wearing long sleeves today so I can't see it. As I pull out the poster here, CAS is at 6 o'clock, right below dead center. And you can see that they talk about Allow/Block/Quarantine, which is part of that, and then some of the client-based features we haven't talked about in the Outlook Mobile updates.

We chose for the poster not to deal with any of the things that were already existent. So for instance, if you had the Exchange 2007 poster, you would see a bunch of these policy pieces because that's the point in time when those pieces were actually added to the protocol. The poster focuses on only new pieces of information. We know remote wipe is incredibly important to IT pros, but it's been a part of Exchange ActiveSync since Exchange 2003 SP2.

BKW: You talked at the beginning about getting feedback about the type of controls people want. Is that still ongoing? Are there new requests coming in? Or is EAS pretty stable at this point?

Adam: I'm always talking to IT pros. I literally talk with them every week. Sometimes I will ask them for particular things. A lot of times I will leave it open. What are the issues they are most interested in, what are the things they want to talk about? They don't ask for a lot more in Exchange ActiveSync at this point. The last time someone asked me something, someone asked, "Can I sync my Notes?" And in Exchange 2010, we actually added that. So I said, it's been there in the protocol. Now it's a matter of getting one of the clients to build it.

Exchange ActiveSync is certainly stable, but I wouldn't say we wouldn't rev it in the future. We're always looking at what are the needs, what are the other things that make sense to put into it. There's more a focus right now on enabling people's functionality and on looking at ways we can do things differently. So for instance, one of the things that we are focusing on right now is how do we make sure that we can give IT pros the ability to only wipe the Exchange data versus wiping an entire device.

BKW: Currently, that's not something that's possible?

Adam: At the moment with Exchange ActiveSync, there are ways that you can do it, but it's normally through doing things like buying an application that's Exchange ActiveSync–enabled. So that application doesn't have access to the APIs to wipe an entire device—it only has access to its own data. So that's how some organizations do it, some applications do it. But we're looking at if there could be a way that we can do this from the Exchange server. Now, some organizations may like that because users won't get angry when a phone get's wiped. On the flipside of that, some organizations may be concerned that data will be kept because maybe someone got an email attachment and they saved it off to an SD card, then they removed it. So, we wiped your email program, all the email's gone, but they took that attachment. Or they copied and pasted out contacts, or a set of phone numbers, or sales data. So by not wiping the devices, there's also the concern about data leaking.

BKW: Those are obviously some thorny problems that someone is going to have to deal with.

Adam: What I've seen is that different organizations are looking at that issue and reacting to it differently. And I would expect that to probably continue, that more security-conscious organization will take a more holistic views of managing the entire device, versus less security-conscious ones will be more comfortable being more flexible with the data but still getting higher levels of protection.

BKW: Exactly. If you're letting people bring their personal devices into the organization, those people are going to have an expectation that you're not going to wipe their devices. But those organizations are probably the ones that are less security-conscious to begin with.

Adam: Yes.

BKW: Anything else you'd like to add about EAS at this point?

Adam: I think that's all for today. That's a pretty broad brush we painted with, but I kind of tried to paint the big pictures here.

BKW: Exactly, nice job. Thanks, Adam.

Related Reading: