Inspired by recent TechNet sessions and User Group meetings, where I heard expounded the wonders of Windows Mobile 6, and its close integration with Exchange Server 2007, I bought a top-of-the range mobile phone, an HTC TyTN11, (specifically because it ran WM6,) and entered into a contract (something to do with a racoon, though the significance is unclear to me) with a mobile telephony company. This is something I’d never bothered with before; I’d had a mobile for several years, but a pre-paid one, normally kept switched off and the number not given out (i.e. purely for me to make calls from). But, with the promised instant availability of my emails, my calendar (which I’d never previously used, preferring a pocket diary), my contacts list (ditto) and my tasks (ditto, also), I decided finally to join the 21st century.
And it works! It really is very impressive. Emails arrive at the mobile rather sooner than they appear on my desktop. Selecting a contact from the list offers me the choice of ringing them automatically – one click – on any of the phone numbers listed, of sending them an email or an SMS text message, of browsing their web page, or even, from their address details, of sending them a boring old letter (the only bit not automated). The calendar facilities are also impressive, though of less use to me – I rarely have so many appointments that keeping track of them is a problem – but still, being able to store all the details of an appointment, time, location, agenda, attendees and contact details (if not already stored as such) in one place is handy. Tasks work much as expected, but I don’t really have much use for them, not yet, anyway.
But it has not been straightforward getting the thing working. As so often, the documentation available is frankly rotten. Most (though not all) of the problems I encountered were conceptual. If I had known in advance how the thing was supposed to work, many of the difficulties would never have arisen. As it is, it has taken me much study, much experimentation, and no less than two support incidents with Microsoft (out of my precious TechNet/MSDN annual quota) to resolve the difficulties. I don’t believe I’m especially thick, so others are likely to hit similar problems. And that is the point of this article.
The treatment is in two parts, how to install and configure it, and how it actually works.
Installation and Configuration of Exchange ActiveSync.
I am not going to attempt a general treatment covering all cases; this is a blog, not a white paper. I state only how I set it up and got it running.
The first requirement is to set up the necessary certificates. The Exchange Server (Client Access role) probably already has a Web Server SSL certificate installed (I don’t mean the self-signed thing which gets installed automatically for illustrative purposes, and which your first action should be to delete!), as this is necessary to run Outlook Web Access (which every Exchange installation surely uses?). If it hasn’t, this must first be installed; the subject is adequately documented (see, for example, ‘M/S Exchange Server 2007 Unleashed, ISBN 0-672-32920-4, chapter 23). This same certificate is also used by ActiveSync. The mobile must hold the certificate of the root authority by whom that SSL certificate was issued, otherwise it will not be able to trust it. If it was issued by a public CA, then that is probably already present (but check – Start/Settings/System/Certificates/Root). But if the certificate is from your own CA, (as it should be – ActiveSync is, like OWA, a really compelling reason for running your own PKI,) you need to install the root certificate on the mobile (and those of any subordinate CA(s), in the case of a multi-level structure). I simply copied the certificates to a storage card, and plugged it into the mobile, opened File Explorer and clicked the relevant files, whereupon the certificates installed automatically, to the relevant store.
Then ActiveSync must be configured on the Exchange server (Client Access role). The Exchange Management Console approach is easier to describe, but it can of course equally well (or better) be done from the Exchange Management Shell. SSL must, however, be configured from (and the SSL certificate originally installed using) IIS Manager: for the virtual directory Microsoft-Server-ActiveSync, ensure that the Directory Security settings have anonymous access disabled and basic authentication set, that SSL is required, with 128-bit encryption, and that client certificates are ignored. I encountered a quirk here. I always set up the default website, i.e. the inetpub\wwwroot directory, on a drive other than the system drive, as this is more secure. When Exchange is installed, it automatically configures the virtual directories OWA and OAB to point to the relevant locations within the …\Program Files\Microsoft Exchange Server\Client Access\… structure. But, strangely, the Microsoft-Server-ActiveSync virtual directory was set to point to the relevant structure but the wrong drive – the drive was taken to be the same as the default website. The problem was easily corrected, once recognised – you get the message ‘Server could not be reached, 0x80072EE7’ – but was certainly a surprise.
Configure the Active Sync properties: EMC/Server Configuration/Client Access; select the relevant server and then the ActiveSync tab. In the properties, General tab, specify the External URL (the internal URL should already be set correctly to https://<FQDN server name>/ Microsoft-Server-ActiveSync). This should be the same host-name as used by OWA when connecting from the Internet, typically mail.company.com, so the external URL will be https://mail.company.com/Microsoft-Server-ActiveSync. Authentication is basic and client certificates are to be ignored. (There is also provision, in the Remote Servers tab, to specify block and allow lists; I haven’t had occasion to use this.)
Then an ActiveSync Policy must be configured. EMC/Organization Configuration/Client Access create a new Exchange ActiveSync Mailbox Policy and delete the default one. On the General tab, give it a name and do select the Allow non-provisionable devices box. (This is a bug – Windows Mobile 6 devices are provisionable, but if this box is not selected, the mobile will fail to synchronise, and will display the unhelpful and misleading message ‘Your account in Microsoft Exchange does not have permission to synchronise with your current settings. Error 0x85010004’. This cost me a lot of aggravation, and a support incident. Expect a bug fix at some point, but, for now, just check the box!) Select Windows File Shares, Windows SharePoint Services as required.
On the password tab, select the appropriate options. I recommend:
Require password (surely no argument about that?)
Require alphanumeric password, with at least 2 complex characters
Do NOT enable password recovery
Require encryption on the device
Require encryption on the storage card
Do NOT allow simple password (again, surely no argument?)
Number of failed attempts – 8 is reasonable
Minimum password length – at least 8
Time without user input… – 60 (minutes – the maximum)
Password expiration – 30 days is reasonable
Enforce password history – 10 is reasonable (range is 0-50)
I personally disapprove of password recovery, as it necessarily involves other people knowing/being able to get at the password, which in my opinion negates the whole point. The option to specify the time without user input before password must be re-entered is interesting, and gave me a lot of trouble before I determined precisely how it works, and will be explained in the next section.
On the Sync Settings tab, I don’t have any strong feelings. I include 2 weeks of past calendar items and 3 days past email items, and allow sync while roaming, HTML email and downloading of attachments, with no limits on message or attachment size, but I wouldn’t argue against other selections. One important (conceptual) point to note is that nothing is said about Contacts or Tasks. This is simply because both are automatically available and there is nothing to configure.
On the Device tab are a lot of interesting options about which I again have no strong feelings, and allow them all. You may well wish to be more restrictive on such things as removable storage and Bluetooth.
On the Advanced tab I allow the browser but nothing else. You certainly shouldn’t want to allow users to add applications onto enterprise mobiles.
Having defined the ActiveSync Mailbox Policy, it then needs to be enabled for all relevant mailboxes. EMC/Recipient Configuration/Mailbox: for each mailbox, enable ActiveSync and specify the policy in the Mailbox Features tab.
Finally, you need to configure the firewall. I use ISA Server 2006, a product I hold in the highest regard, and especially well suited for publishing servers such as this. For present purposes, the Exchange book mentioned above has an entirely adequate exposition of the subject in chapters 13 and 23. You need to create a firewall rule by running the task Publish Exchange Web Client Access, exactly the same as for OWA, and using the same certificate (which you will have imported from the Exchange server – all adequately covered in the book).
The DirectPush technology used by ActiveSync relies on long-running HTTPS requests. The KB article 905013 defines a number of registry setting recommended to enable these. In practice, I found that my ISA server machine had all the recommended values already, by default, but you may like to confirm this for yourself. Beyond that, I have nothing useful to add on the firewall.
How ActiveSync Actually Works
(Not the technology, you understand, long-running HTTPS requests and so on – that is adequately documented – but how it’s presented and how you use it. Conceptual stuff, that is, and it gave me a lot of trouble.)
Many of the settings configured in the Exchange ActiveSync Mailbox Policy are also configurable from the mobile, and the interaction between these gives rise to some unexpected effects (unexpected by me, certainly). In some cases, the policy settings override those of the mobile, so that it is no longer possible to configure them on the mobile. Thus, for example, if the policy specifies a strong alphanumeric password, then that’s what you’ve got to use. Likewise, if there is a timeout after a period of inactivity on the mobile, there is no way this can be disabled. But in other cases, the policy provides only a default value, which can be partly or wholly overridden from the mobile.
‘Partly overridden’ applies to just one setting, as far as I am aware, the time value applying if ‘prompt if device unused for’ is set. If this option is not set in the policy (thus ‘unlimited’ as far as the policy is concerned), a range of values is offered on the mobile, up to 24 hours, or it may likewise be unlimited. But if a value is specified in the policy (and the maximum allowed is 60 minutes) then this acts as a maximum; a lower value may be specified on the mobile but not a higher one, and the range of available values displayed extends only up to this maximum. When I first got ActiveSync working, I found that the mobile required me to input the password after only 1 minute of inactivity, and you can easily imagine how infuriating that was! What had happened was that I had previously had a value of 12 hours configured on the mobile, and the policy, being applied for the first time, finding a value that it didn’t recognise, set it to zero. Resetting the policy to unlimited had precisely no effect, nor did a soft reset of the mobile. A valid value, once configured, is persistent, and zero (interpreted as 1 minute) is obviously always less that any maximum! At least that is what I think happened; it only happened at that first synchronisation. I can repeat the experiment, clearing the value on the policy and setting a value of 24 hours on the mobile, then reapply the policy with a value of 60 minutes, and the value on the mobile gets reset correctly to 1 hour, with only lower values available. It all sounds simple enough now I understand it, but it took quite a while and much aggravation to pin down.
The policy values for past calendar items (I set it to 2 weeks) and past emails (I set it to 3 days) can be reset on the mobile to anything the user wants. This I think is reasonable – they are only advisory, good defaults, but there is really no reason why the user should not be able to get more, unlike the timeout value, above, which is a security setting and it should definitely not be possible to override that.
I have my emails structured in a hierarchical set of folders under the inbox, and also under sent items. Incoming mails arrive in the inbox and, if I wish to keep them, at some point I move them to the appropriate folder, to keep the inbox manageable. Ditto for sent mails. The mobile displays the same folder hierarchy. However, ActiveSync only ever synchronises to the inbox. Thus, if a new mail has arrived (and been immediately synched down to the mobile), if I then (on my desktop machine) move it to another folder, and resync, that mail disappears from the mobile inbox, but does not reappear in the corresponding subfolder. The only use of the folder structure on the mobile seems to be to allow mails to be moved from the inbox to a subfolder (after which they are visible in that subfolder and absent from the inbox) but on the next sync, the similar move is carried out on the server, and the mails disappear from the subfolder on the mobile. The email sync options include the time period for which to sync emails, typically for the last three days. Only emails which arrived within that period are synched to the mobile inbox. As time passes, mails disappear from the mobile inbox, as they become more than 3 days old, or whatever. This is reasonable. As noted above, this value can be changed on the mobile, to override the value set in the policy.
I have deliberately left the above paragraph as I originally wrote it. In fact, as a colleague who kindly reviewed this article pointed out, the folders to sync can be configured on the mobile (only, not in the Exchange policy,) in Outlook/Menu/Tools/Manage Folders. A small prize is offered to the first person who can point to that piece of information anywhere in the documentation! Quite likely I would have found it myself – eventually – by trial and error. By default, only the (top level) Inbox is selected, not even Sent Items (so if you create an email on the mobile, it disappears as soon as you send it – though it does appear momentarily in the outbox!) I choose to sync to Sent Items as well; it’s not really necessary in other cases as the messages will almost always be older that the 3 days for which I sync.
When I first got ActiveSync working, I was getting emails and calendar data synched (although there were at that time no entries in the calendar), no tasks were appearing on the mobile (unsurprising as there weren’t any), but no contacts were appearing either, and that was worrying, as there were several of those. As noted earlier, contacts and tasks do not appear in the policy sync settings because there is nothing to configure – they’re available if wanted, and that’s that. Looking at the Sync Options screen on the mobile, four categories of data are offered, Contacts, Calendar, E-mail and Tasks, and all are selected to be synched by default. It was only after I’d worked out how emails are handled, as detailed above, that I was able to solve this problem. As with emails, my contacts were structured in folders, and there just happened to be none at all in the Contacts folder itself. (There may well be an error in Outlook here. If you select the Contacts folder, right-click it and elect to create a new folder, the Create New Folder screen displays it as if it were to be created as a subfolder under Contacts, but when created, it appears under My Contacts as a folder at the same level as Contacts, i.e. a flat structure, not hierarchical.) Moving all my contacts into the actual Contacts folder solved the problem.
What I was trying to do here, grouping the contacts as business, friends and family and so on, is actually better achieved by using categories within the contacts folder, whereby the contacts can be assigned to one or more categories (thus a particular contact could be both a business contact and also a friend!) and the entries can be displayed either as a single list or split up by category (with some contacts appearing more than once if appropriate). (There are several other display options available, but this is the most generally useful one.) The trouble with categories (and probably why I’d never noticed them before) is that they are configured quite counter-intuitively. Thus, to create a new category, you must select an existing contact and edit the entry, selecting Categorize from the Edit menu, and then All Categories. Only then, in the strangely named Color Categories screen, (there are eight default categories associated with different colours,) do you see the option to create a new category. Press New and name the category (you also get the option to associate a colour with it if you really need to). You will find that the contact you originally selected has been automatically made a member of the new category, so deselect this if that is not what you want. This stuff is simply weird! The new category does not appear in the contacts list until it actually has some members (that at least is reasonable). Having created the category, it is then straightforward to add contacts to it; simply right-click the contact, select Categorize and click the appropriate category in the list. (But to remove a contact from a category you have to right-click the contact, select Categorize then All Categories, which displays the complete list with that contact’s memberships ticked, and clear the appropriate tick).
Configuring categories on the mobile is rather simpler. Again, you need to select a contact from the list and edit it. There is a field Categories; click this and a list of categories appears, which already has a New button, so creating a new category is rather more straightforward (again, if you create a new category, the contact you have selected is automatically selected for that category). There are, by default, four categories already present – Holiday, Personal, Seasonal and Training. You can display the mobile contacts either as a complete list or by single category by selecting Menu/Filter and then the category (there are a few other display options also).
More weird stuff: Category information synchs from Exchange to the mobile, but not completely vice versa. (However the Outlook Colour categories do not appear on the mobile, nor do the four default mobile categories appear in Outlook. So really, category sync applies only to user-defined categories at either end.) Categories defined on the mobile sync to Outlook in that they appear when the contacts are listed by category. If a contact in such a category is right-clicked, Categorize selected then All Categories, the mobile-defined category appears in the list, but marked ‘(not in Master Category List)’. If you try to add another contact to that category, you can’t – it doesn’t appear in the (Master Category!) list.
So categories are useful, but the whole area is an appalling bodge – the sort of thing you might have found in Windows 95, or find on Unix systems today. It really is a disgrace.
As I said at the beginning, once you know how it works, it works. But getting to that point has been a real drag.
The respected colleague who reviewed this article thought it rather harsh. Perhaps it is, but, I think, deservedly so. Once working, this is a really excellent product, immensely useful, and it has revolutionised my attitude to the mobile phone, which I now keep switched on and carry with me everywhere (I still use it only rarely to make a call, even less frequently to receive one, but I use it all the time to send and receive emails). The market for it is immense. It should be utterly trivial to install and configure. And in fact it isn’t difficult, once you know what you’re doing, but the quality of the available documentation is so abysmal that it must be seriously impeding adoption of the product.
I fear I am becoming a real bore on this subject. In many fields (PKI being a glaring example on which I have sounded off many times before) the available documentation is okay once you know what it’s about (and are therefore in less need of it), but utterly hopeless from the point of view of someone coming new to the subject and trying to learn about it. There really is no compelling reason why this should be so, and I publish my articles in the hope of making a small contribution to rectifying this deficiency.