Shortly before VMware Partner Exchange, Microsoft Certificate Services in my long-in-the-tooth lab domain died and unfortunately took a handful of integrated services with it. One of those dependent services was Microsoft Exchange 2010. After attempts to repair and later rebuild and restore the Microsoft CA failed, I decided the time had finally come to ditch the boche.mcse Windows Active Directory domain which I originally built when Windows 2000 and Active Directory first launched. There were a number of other lingering issues with the domain which I haven’t been able to repair and the time investment and frustration really wasn’t worth it. I had been waiting for a catalyst in addition to a block of weekend time and today was the day.
I had been hosting Microsoft Exchange Server since version 5.5 and although I had accumulated quite a bit of experience over the years in building, migrating, and maintaining a small Exchange environment, the truth is Exchange has gotten way too complex and bloated for me to keep up with. Being a VMware guy, I’ve had the itch to give Zimbra a try since the acquisition. It seemed like a win-win solution: Ditch the complexities of Exchange and replace with a VMware messaging solution. So after building the new domain this afternoon Exchange 2010 was retired and Zimbra 6.0.13.406 was born.
Zimbra is incredibly easy to set up, especially when deploying the appliance version in .OVF format hosted on vSphere 5. I was up and running with incoming and outgoing email in very little time. One area I was concerned with when replacing Exchange with Zimbra was the integration and end user experience. Zimbra ships with an HTML Outlook Web Access like interface which can be used for processing mail on a regular basis. Would I lose the ability to use Outlook as a mail client or mobile device compatibility? The answer was no on both accounts. In addition to the web interface, I can continue to use Outlook 2010 connected to the Zimbra server via IMAP. This is just about as easy to set up as attaching Outlook to a native Exchange environment. Outlook detects the mail services provided by Zimbra and negotiates an IMAP configuration. Done.
Configuring Zimbra Mobile wasn’t as straight forward but I was able to piece together the steps. Zimbra’s documentation is decent but in some areas it feels explicitly vague, lacking step by step configuration detail. With Outlook and the web client functioning well, the last step was to integrate Zimbra with my mobile devices: the iPhone and iPad. These are the steps I followed:
Log into the Zimbra Collaboration Suite Appliance web console (https://<f.q.d.n.>:5480/). On the Zimbra Administration tab, change the pull down box from All addresses or Accounts to Profiles.
In a default out-of-box deployment, there should be just one profile named ‘default’. Modify that profile by enabling Mobile Sync on the Zimbra Mobile tab. Save the changes to the profile.
Now that we have Mobile Sync enabled in a profile, we can apply that profile to each Zimbra user who needs messaging access from their mobile handheld. Going back to the Dashboard tab, change the pull down box from Profiles to Accounts. Modify the account in which you’d like to grant Zimbra Mobile access. On the General Information tab for the user account, uncheck the box labeled ‘auto‘ and then begin typing the first few letters of the profile name of ‘default‘ in the Profile box. After the first few letters of the profile are typed, the default profile name will appear and that can be selected with the mouse. Now save the changes.
Now it’s time to configure the iPad and iPhone to connect to Zimbra Mobile. The first step is to create a new mail account. The type will be Exchange.
I found configuring the account with Zimbra Mobile easier than with Exchange 2010. Provide the following values:
2. Email – this should match the email address tied to the account in Zimbra.
3. Server – this will be the f.q.d.n of the Zimbra server. By default an SSL connection over port 443 will be attempted which Zimbra supports. You can optionally specify an alternative port. For example, I could come in externally over port 8080 and then have that translated by NAT to port 443 and sent to the Zimbra server. Without a port defined, 443 is implied.
Domain – not required with internal Zimbra authentication. If authenticating with LDAP integration, this field would likely need to be populated.
4. Username – the name tied to the account in Zimbra.
5. Password – 12345
Description – not used in Zimbra Mobile configuration. It’s merely a differentiator for the account on a mobile device which may have multiple accounts set up.
If things are working correctly, you’ll be able to tap the blue Next button and you’ll be prompted to verify the synchronization of all three types of items: Mail, Contacts, and Calendars. Once the account configuration is saved you’ll also see an additional slider showing that SSL is ON (the default).
Next up is to configure my wife’s Kindle Fire. I don’t expect any issues there.
I see that you use and alternative port(8080). but what happens when you are inside your network? is the port fwd working internally too?
In that example, that’s why I point the handheld at the perimeter router (natrouter) at port 8080. Whether internal in my house, or external at the coffee shop, natrouter will take the traffic in at 8080 and forward it internally to the Zimbra server on port 443.
Maybe its worth mentioning that out-of-the-box Zimbra Network edition 7.2 is installed in HTTP modus. To turn on the SSL on 443 run command “zmtlsctl https”.