Using an iPhone for e-mail with Exchange Server

Whilst I’m not trying to suggest that the Apple iPhone is intended for business users (I’d suggest that it’s more of a consumer device and that businesses are wedded to their Blackberries or, more sensibly in my opinion, Windows Mobile devices) it does seem to me that there’s been a lot of talk about how it can’t work with Microsoft Exchange Server – either blaming Apple for not supporting the defacto standard server for corporate e-mail or Microsoft for not being open enough. Well, I’d like to set the record straight – the iPhone does work with Exchange Server (and doesn’t even need the latest version).

My mail server is running Microsoft Exchange Server 2003 SP2 and has nothing unusual about it’s configuration. I have a relatively small number of users on the server, so have a single server for secure Outlook Web Access (OWA, via HTTPS) and Outlook Mobile Access (OMA, via HTTP) and mailbox access (MAPI-RPC for Outlook, IMAP for Apple Mail, WebDAV via OWA for Entourage). I have also enabled HTTP-RPC access (as described by Daniel Petri and Justin Fielding) so that I can use a full Outlook client from outside the firewall.

It’s the IMAP access that’s the critical component of the connection as, whichever configuration is employed, the iPhone uses IMAP for communication with Exchange Server and so two configuration items must be in place:

  • The server must have the IMAP service started.
  • The user’s mailbox must be enabled for IMAP access.

Many organisations will not allow IMAP access to servers, either due to the load that POP/IMAP access places on the server or for reasons of security (IMAP can be secured using SSL, as I have done – Eriq Neale has written a step by step guide on how to do this for Windows Small Business Server 2003 and the process is identical for Exchange Server 2003).

In addition, firewalls must allow access to the Exchange server on the appropriate TCP ports – IMAP defaults to port 143; however secure IMAP uses TCP port 993. SMTP access will also be required (typically on TCP port 25 or 587). Using telnet to test port access for IMAP and SMTPYou can confirm that the ports are open using telnet servername portnumber.

Note that even if the connection between the iPhone and Exchange Server is secure, there are no real device access controls (or remote wipe capabilities) for an iPhone. Eriq Neale also makes the point that e-mail is generally transmitted across the Internet in the clear and so is not a secure method of communication; however it is worth protecting login credentials (if nothing else) by securing the IMAP connection with SSL.

Interestingly, the iPhone has two mail account setup options that could work with Exchange Server and experiences on the ‘net seem to be varied. IMAP should work for any IMAP server; however there is also an Exchange option, which didn’t seem to work for me until I had HTTP-RPC access properly configured on the server. That fits with the iPhone Topic article on connecting the iPhone to Exchange, which indicates that both OWA (WebDAV) and HTTP-RPC are required (these would not be necessary for pure IMAP access).

The final settings on my iPhone are:

Settings – Mail – Accounts – accountname
Exchange Account Information Name displayname
Address username@domainname.tld
Description e.g. Work e-mail
Incoming Mail Server Host Name servername.domainname.tld
User Name username
Password password
Outgoing Mail Server Host Name servername.domainname.tld
User Name username
Password password
Advanced – Mailbox Behaviors Drafts Mailbox Drafts
Sent Mailbox Sent Items
Deleted Mailbox Deleted Items
Advanced – Deleted Messages Remove Never
Advanced – Incoming Settings Use SSL On
Authentication NTLM
IMAP Path Prefix
Server Port 993
Advanced – Outgoing Settings Use SSL On
Authentication NTLM
Server Port 25

(Advanced settings were auto-configured.)

A few more points worth noting:

Introduction to Microsoft Small Business Server 2003

A few weeks back, I attended a Microsoft Event which was supposed to provide a technical overview of Microsoft Small Business Server (SBS) 2003. I was a bit disappointed with the quality of the event (and it looks like I wasn’t the only one) but it did at least give me a chance to see SBS, a product to which I have had very little exposure, mostly because my work tends to be with medium and large corporate environments and SBS is aimed at smaller businesses.

Despite its small business focus, SBS does seem to have quite a following and there were clearly many people in the audience with significant experience of the product – some of the links at the end of this post may also be useful for further information.

The principle behind SBS is the provision of an environment which runs on a single server, encompassing many of the facilities which would more typically be spread across a number of servers in a corporate environment, but which remains easy for a small business to deploy and manage. This does cause some complications (e.g. likely resource conflicts from the presence of SQL Server and Exchange Server on the same physical server) and also means that some of the product versions on which SBS is based are not the latest versions available as a standalone product (e.g. ISA Server 2000 – not 2004).

SBS is available in two editions – standard and premium. Both versions have the same base components (Windows Server 2003 Standard Edition, Exchange Server 2003 Standard Edition, Windows SharePoint Services Business Intranet, routing and remote access services, mobile user/device support, remote web workplace, shared network resources, backup/restore and task based management), but the enterprise edition is extended to include ISA Server 2000, SQL Server 2000 and FrontPage 2003.

From a management perspective, SBS is intended to allow a small business to be self-sufficient, with separate Administrator and Power User management consoles allowing easy management of users and computers along with wizards to assist in backing up and restoring data (including monitoring and reporting). Remote access is simplified with a number of wizards and the remote web workplace (http://servername/remote/) whilst intranet creation is handled with the WSS-based business intranet (http://servername/companyweb/), e-mail capabilities are provided through Exchange and enterprise edition users have access to SQL Server databases and improved internet security through ISA Server (SBS standard edition includes the standard Windows Firewall, which may be adequate for many small businesses but might not be flexible enough for others – having said that, I would probably place standard edition behind an Internet router with its own firewall capabilities).

Overall, SBS looks good, but the co-hosting of so many components on a single device (and Microsoft’s deliberate restrictions on scalability) mean that there are many gotchas to watch out for. To find out more, check out the following links:

Grabbing screenshots using the Microsoft virtual machine remote control client

I just discovered this and think it’s really useful…

I’m in the process of documenting a client’s server configuration, using a virtual machine with a VPN connection to the client’s network and then a remote desktop protocol (RDP) connection to their servers. Because the VPN is within a virtual machine, I’m constrained by the limitations of the Microsoft virtual machine remote control (VMRC) client and thought I could only take full screen screenshots, using VMRC’s Remote Control | Special Keys | Send Print Screen menu commands. What I found (completely by accident) is that if I use the mouse to send the print screen command, the whole screen is captured; however, if I use the keyboard (Alt+R | right cursor | down cursor | carriage return) it acts like an Alt+PrtSc, and only the contents of the active window are copied to the clipboard.

I’m not sure if this is true for all clients (I haven’t tested further), but my setup was:

  • Windows Server 2003 SP1 host.
  • Virtual Server 2005 (v1.1.465.0 SE).
  • Windows XP SP2 guest (with virtual machine additions 13.206 installed), VPNed into the client’s network using the Cisco Systems VPN client (v4.6.02.0011) and then RDPed into a Windows 2000 SP4 server (RDP client v5.1.2600.2180).