We’re still running Zimbra at work and it’s still providing us with what we need as a collaboration suite. Unfortunately, we’re running on Leopard Server and still stuck on version 5 due to Apple’s unwillingness to fix the bugs in their server software.
Which is why we’ll be migrating from the Xserve to an Ubuntu server*. I have a conference call with Zimbra’s Professional Services people to begin the planning of the migration. I put the call into them due to the fact that we’re migrating hardware and software at the same time, as well as upgrading the storage system that mail resides on. Looking forward to the challenge and keeping my fingers crossed that all goes well.
Just a quick note:
We rolled out Zimbra back in October to our 2,000+ users with some last minute account insanity. Aside from quickly adding over one hundred last minute accounts, the roll out was a success. We’ve had a few issues since then, but nothing major and all issues were addressed by Zimbra’s support team within a reasonable amount of time.
So far it seems to be a hit with most of our staff and I’m extremely happy with our decision. If you’re looking for an email system, I definitely recommend checking them out.
September 13th, 2008
dave
One of the first problems I had to resolve after installing Zimbra, was how to keep Zimbra’s internal LDAP directory in sync with our Open Directory server. This problem was compounded by the fact that out of the box, all Zimbra mail boxes have to be provisioned by hand. Granted, there are command line tools and scripts that can be used to batch provision accounts but who wants to manually put together scripts to do the bulk provisioning? Authentication and GAL lookups from an external source are working beautifully so far and to me, Zimbra’s lack of an auto-provisioning from an external directory feature is almost insane.
Currently there is an RFE in Zimbra’s bug tracker for such a feature, but that doesn’t help those of us who could use a solution now.
After a great deal of searching through the forums and bug tracker, I literally stumbled across Bug 14772 – include zmexternaldirsync in build. It’s a discussion about including a Perl script called zmexternaldirsync in the Zimbra builds. From what I can tell, the team was getting it ready to include it in a build and then decided against it. I grabbed the script and documentation and fiddled around with it and got it working.
And now I’m posting it here to (hopefully) make someone else’s life a little easier.
WARNING: This script is provided as-is. The author of this blog is not responsible for any potential damage it may do to your install. The author of this blog is also not responsible for supporting this script. Be aware that any future Zimbra updates could break this script. I doubt it’s supported by the Zimbra team since it isn’t included in any of the available builds (AFAIK). Use it at your own risk!
With that said… I’ve been using it since earlier this year. So far it’s auto-provisioned new mail accounts for every new user I’ve added to our directory server. It’s made my job a lot easier than I thought it was going to be. It’s survived two software updates and an OS/hardware migration. It’s everything that should’ve been included with Zimbra to help system administrators maintain user accounts.
When I first set it up, I was running Zimbra on an Xserve running Tiger server (10.4.11). I had to install the Perl modules referenced in the spartan documentation. I also had to modify the script itself – I’ll be honest, it’s been so long I can’t remember what I had to change and I was bad about keeping notes… I think it was a case change in three lines of the script. I’ve included my modified script in the zip file to save you the time and trouble. I’ve set the script up to pull the cn from our directory and set that value to Zimbra LDAP’s displayName value… I’ve found it handy to have full names in the account listing screens. I just finished migrating to a newer Xserve running Leopard server (10.5.4) and haven’t run into any problems with the script so far. If I do, I’ll post them here.
zmexternalsync.zip (67 KB)
One of the projects I’m involved with at work is implementing a new email system. We’re going to be moving approximately 2100 users from Squirrelmail to the Zimbra Collaboration Suite. As part of the transition we’re not going to be moving user’s mail, instead choosing to go the fresh slate route. All of our users will still have access to their old mail for some time to get what they really need out of their mailboxes. We’re also going to be moving completely away from using mail clients, opting instead to have our users access their mail through the ZCS web UI and utilize all of it’s features. We didn’t make these choices lightly, but honestly our users have a habit of using their email for jokes, shopping, and more jokes – none of which I feel like moving. As for the mail client decision – anyone who’s ever migrated 3GB worth of email from one computer to another can probably see where we’re coming from.
In terms of the user experience, moving from Squirrelmail to Zimbra is akin to trading in a Ford Model T for a Dodge Viper. Zimbra has a beautiful AJAX UI that, while being easy on the eyes, is also extremely functional. Users essentially have all the functionality that they would expect from a locally installed client. One nice thing about Zimbra is that you’re not locked into using the AJAX interface – you can choose to use a standard HTML interface which is a stripped down version of the UI, but still a million times better than what we’re moving from.
One of the things I’m hoping to do with this blog is provide information on our Zimbra implementation that other admins may find useful. I’ve spent hours trying to find solutions to problems we’ve run into already (syncing Zimbra’s internal LDAP server with an external OD server and auto-provisioning new email accounts for instance) and if I can save another admin the hassle, I’ll be satisfied that I accomplished something.