iPhone

Configuring IMAP for iPhone Sync with Microsoft Exchange 2003 - Clustered Configuration

| | | |

Currently we have customers asking how to setup IMAP in an Exchange 2003 clustered environment for iPhone use. Exchange 2003 by default disables IMAP4 which is what the iPhone supports. I want to stress that IMAP4 should never be enabled without using SSL! Sending information in clear text is not recommended. I will be referencing the IMAP4 port 993 later in this article. I will step through the different actions taken for Exchange 2003 clusters.
Enabling IMAP:
On the Exchange 2003 Cluster nodes you will need to go to each and enable the “Microsoft Exchange IMAP4” service. Typically if you are using a clusterd back-end you have a front-end server that will need to have IMAP enabled also.

Configuring IMAP for iPhone Sync Microsoft Exchange 2003 - Non-Clustered Configuration

| | | |

The iPhone has arrived and the corporate world is now starting to configure their existing messaging infrastructure allowing employees to sync up their iPhone’s.
I want to stress that IMAP4 should not be enabled without using SSL! Sending information in clear text is not recommended. I will be referencing the IMAP4 port 993 later in this article. I will step through the different actions taken for a non-clustered Exchange 2003 system.
Enabling IMAP:
By default, IMAP4 is disabled on Exchange 2003. If your organization has one or many Exchange 2003 servers(front-end and back-end) you will need to go to each one and enable the “Microsoft Exchange IMAP4” service.

Configuring iPhone and IMAP access for Microsoft Exchange 2007

| | |

The release of a little known device called the “iPhone” caused quite a bit of talk about how it fits into an enterprise-class messaging environment. There is little argument over the popularity of the iPhone and its inevitable arrival into the corporate network whether well received by IT administrators or not. To support a device that does not support Exchange ActiveSync such as the iPhone, administrators may have to turn on IMAP functionality.

Exchange 2007 brings about a lot of changes for IMAP4 from prior versions of Exchange. IMAP is no longer provided to exchange by IIS but is now fully incorporated into Exchange on the Client Access Server role. Unlike in Exchange 2003, IMAP cannot be administered via a GUI like Exchange System Manager. All configuration is done from the Exchange management command shell. In this first article, I will step through a straightforward configuration of IMAP for an Exchange 2007 system. In the second, upcoming part I will walk through the steps needed to enable IMAP for the entire organization.

Accessing Messages from an IMAP-enabled Device

The first thing we need to do is enable the IMAP service on our Client Access Server role. The following commands will enable and set the service to startup automatically:

  • Start-service -identity MSExchangeIMAP4
  • Set-service –identity MSExchangeIMAP4 –startuptype Automatic

Exchange 2007 was designed with security as a priority and thus all features are set secure by default. IMAP4 is no different.

By default, IMAP requires TLS and uses port 993. We can change this if we choose to do so however, most devices and applications support secure IMAP. By changing the loginType attribute from SecureLogin to either PlainTextLogin or PlainTextAuthentication, we open up the standard port TCP 143. NOTE: Again, for security reasons, avoid this configuration unless you absolutely MUST open up port 143.

Because we are using SSL/TLS to encrypt the communication between the device and Microsoft Exchange we need to make sure are certificates in are in good order. If you choose to use a FQDN (eg. imap.company.com) that differs from the Certificate, or if you use a self signed certificate, the user will be prompted that the certificate is invalid each time a connection is made, which can be annoying.

Some devices will fail without the option of trusting the invalid certificate. For example, if you wanted to use imap.company.com you would need to create a certificate with an internal/external Certificate Authority or it could be part of a Unified Communications certificate in the Subject Alternative Names. Assuming that the proper certificate is in the local computer personal store, we can apply the certificate to the IMAP service using the following shell command.

  • Enable-exchangeCertificate –Thumbprint [thumbprint] -Services IMAP

After the above steps, IMAP should now be fully functional on our Client Access Server role. However, at this stage IMAP has only provided a device such as the iPhone a means of receiving messages from Exchange. We still can not send messages from the device.

Configuring SMTP Services to enable sending Messages from an IMAP-enabled Device

The next step is to provide a means to submit outgoing messages from a device such as the iPhone. Outgoing messages will use the SMTP protocol to send the message.

Unfortunately we cannot submit our messages to any SMTP server that we choose, as most SMTP servers are configured to not trust, or relay content from an unknown client. We must use a mail server that allows us to authenticate so the server can trust the client. Many companies may have a mail server provided to them by their ISP that automatically trusts any client on their network but it is often best to provide the means to relay mail for your users.

Many organizations have an Exchange Edge server that is exposed to the internet and is easily reached. Unfortunately, the Edge role cannot authenticate a sender because it cannot contact Active Directory. There are a myriad number of ways you can provide SMTP relay but for most Exchange 2007 organizations the best method is to provide access to an Exchange 2007 Hub Transport role.

All Hub Transport roles have a pre-configured receive connector called Clients for users to relay mail. This connector is set to listen on the standard client SMTP port of 587 and not 25. This connector also requires TLS. By default for security purposes, many Exchange 2007 options, including this one, are not enabled.

In this case, the Clients connector does not allow messages from an address that is in the authoritative domain so we must grant the Authenticated Users session the permission to bypass this restriction. Run this command within the command shell on the hub transport servers:

  • get-receiveconnector Client | add-adpermission -user AU -extendedrights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

Syndicate content