In 2004 Google announced that it was building a messaging service called “gmail” that would allow users to have 2+ GB of online storage available for each user, as part of their “Infinity+1”
storage plan storage plan. Shortly after Google announced their gmail service, Microsoft and Yahoo matched the 2+ GB offer on their hosted service platform.

The result? Today almost all free web based email services offer 2+ GB of online storage for their email users. This then started discussions in the corporate world mainly at the C-level, as many CEO’s and CIO’s thought that “If Google can do it for free then why am I fighting my IT department for another 50MB?” This in turn made for a lot of anguish throughout IT departments around the world.

Exchange patch levels are very critical in an environment that has front-end OWA servers. The most important concept you need to realize is that the front-end servers are a proxy server to the Exchange back-end servers when using OWA. So when introducing a new Exchange server into an Exchange organization with front-end OWA servers there is a chance that the Exchange patch levels will be out of sync and OWA will fail with a "Loading" message for any user on the new Exchange server. We ran into this challenge first at a large financial services customer. Our take on it was we couldn't update all the front-end servers in a timely manner to match the new back-end server that was introduced. So we applied the workaround and waited for the next maintenance window to apply the proper exchange patches to the front-end servers. To apply the workaround for this issue review the following:

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 MSExcangeIMAP4
• 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

Thanks for the introduction Keith, I remember the polar bear kidnapping incident well and it still makes me laugh to this day when I hear that story.

I wanted to post my first blog this week to introduce myself and talk about some of the exciting challenges ahead. First of all I have to say that I am delighted to be part of the Azaleos team, Azaleos has gathered a group of very talented and motivated engineers to deliver world class solutions that can be delivered in a unique way to our customers. I look forward to the challenges ahead and especially look forward to working with our customers to improve our solutions to meet your needs.

Our team continues to grow here at Azaleos as we continue to strive to serve our customers with managed services excellence, seven days a week, 24 hours a day. One of the more recent additions to our team is Lee Dumas, who I anticipate will soon be a key contributor to this blog site with facts and fun about Exchange 2007.

I had the chance to meet Lee Dumas about 8 years ago when I worked at Microsoft and led the team that shipped the Team Productivity Update for BackOffice 4.5, also known as “Polar”. At that time, Lee was leading up the Exchange Dogfood lab, where frequent Exchange updates were tested on the product group – Microsoft VP Brian Valentine’s practice of “Dogfooding” -- prior to releasing bug fixes and new features to customers and the partner community.

This is a cross posting from Microsoft Technet forums.

We too at Azaleos are having this same issue at a customer site undergoing an upgrade from Exchange 2003 to Exchange 2007.

In this customer, MAC clients using MAIL 2.1.1 worked just fine with Exchange 2003.

However, when we performed the upgrade, the same MAC client could download mail message headers from Exchange 2007, but on accessing body content 90% of the time the client would just hang and time out with the message:

I had the opportunity yesterday to listen to an panel at Interop, one of the best remaining industry conferences, on the topic of “The Exchange Game”. This session discussed issues regarding Archiving, Business Continuity, and Migration to Microsoft Exchange 2003 and 2007. Led by Byte and Switch magazine, the panel included a Systems Integrator, a speaker from Microsoft, and a current Exchange customer, Zumiez.

One of the universal topics agreed on by all of the speakers is that there is a need for archiving around the Exchange store: to help with migration, to help with compliance, and to help with storage management. I agree with these points, and think that IT organizations need to figure out how to manage storage better – for storage management, for archiving, for disaster recovery and business continuity.

The AutoDiscover service is a brand new feature for Exchange 2007. The service allows new Outlook 2007 clients to have their profiles automatically generated using nothing more than a user’s email address and password. The information here can be found elsewhere with greater depth but there really doesn’t seem to be any source that paints a complete and succinct picture about what an Exchange Engineer will face when facing the necessary configuration.

AutoDiscover will return to the client configuration information such as the name of their mailbox server, Outlook Anywhere (RPC/HTTP) info and connection protocol. The service has much greater function and is actually an integral part to the functionality to an everyday user on Outlook 2007.

Recently we discovered an issue with Exchange Search on our Exchange 2007 server. A user encountered a problem while trying to search within the mailbox using Outlook Web Access (OWA). At the top of the page the user was shown a message stating that "results will take a long time to appear because Microsoft Exchange Search is unavailable. Results will not include matches in the e-mail body."

The user quickly asked our team to enable this feature which raised eyebrows because Exchange Search is installed and enabled by default. Initial Crawls and indexing is triggered by the creation or migration of a mailbox. The arrival of a message will only trigger an update of the index. This lead me to believe that if an initial crawl of mailbox results in a corrupted index, the updating of the index upon new messages arriving will not correct the corruption and will make this feature unavailable on a per-user basis.