Archive for October, 2008

Managing Windows Domains

October 26, 2008

With the removal of Exchange and MS Office from the company we then wanted to look at the Domain Controllers. While a lot of Open Source systems have the ability to integrate into Active Directory, it always appeared to be a little complicated and fraught with problems. However, to get Single Sign On working, you need a single directory master. Zimbra includes OpenLDAP as one of it’s components, so we decided to bite the bullet and migrate the Windows desktops off the Windows Domain and onto a Samba domain instead. This would then give us a greatly reduced cost base as well as the ability to have the same username and password within Windows, Zimbra, RT etc etc.

Installing Samba was a little complicated, there are any number of HOWTOs out there to follow and while initially there was a big learning curve, it got easier quickly. Zimbra contains a very explicit HOWTO for integration between Samba and LDAP so while that took a little thought it also worked without too much heartache. It also meant that integration with the various systems were a little easier to debug as well.

Once we had followed the HOWTOs it was a simple matter of migrating the workstations to the new domain. Samba v3 is modelled on the pre Active Directory technology, so the whole process is a little more manual than with the latest Windows technology. However, v4 of Samba promises to include all that functionality in which will make things a lot less manual.

It did mean that we now could reuse 3 Domain Controllers (and not have to purchase Client Access Licences for all the users to be able to connect to the domain controllers with) and save the subsequent licencing costs. Creation of a new user account now occurs within Zimbra, but the login scripts have to be manually set on the Samba server. Telling Samba to obey the pam restrictions on the server ensured that home directories would be created automatically however.

The two biggest issues we encountered:

  1. Until a recent version of Zimbra, if someone changed their password within Zimbra it would not be reflected on the Windows machines. This is now rectified, via an extension, but did require user education.
  2. Samba inexplicably removed a feature by which we could filter the ldap searches on active users, without replacing it with anything similar. As a result I have not been able to find away to disable ex employees from being able to log on just by setting their account status in Zimbra. This is just plain stupid. Instead I have to write a script to check the Zimbra status and apply the same to the Samba statuses. Really, really irritating. If we weren’t saving so much money on the Windows Servers, I would seriously reconsider going to samba again. The workaround is such that if a user gets disabled inadvertently (i.e. they type their password in incorrectly and get locked out) then I need to re-enable them twice.

Leaving the negatives aside, Microsoft makes you buy Windows Server and then Client Access Licences to be able to use the server. Then more licences for anyone wanting to log in to the server (and I swear you have to be a rocket scientist to understand the Terminal Services licencing documentation). It all adds up. Samba is more stable than Windows, fast and works well. Other than the inability to hook into LDAP correctly which I did create a workaround for… Lets hope v4 works better in that respect.




Managing Customer Communications

October 22, 2008

We sell our products over the Internet and our customer service is likewise managed predominantly via email. When I started at the company we had a several support addresses which were sent directly to a staff member’s Inbox. These were then forwarded on to individuals within the team to answer. Obviously this was an appalling state of affairs as there was no real way to track workload, whether the customers were happy with the responses and generally no management oversight as to what was happening. It also meant that there was very little consistency in responses as everyone basically re-wrote their responses every time. Not very efficient.

As a result we had a look around at ticketing systems that we could use to manage the customer correspondance. Because we were dealing with end customers, a traditional CRM system didn’t really meet our needs. We do not have a long history with most of our customers – instead dealing with product questions, returns etc. We wanted something more lightweight, but still capable of being able to track customer history if necessary and provide management reporting etc. Any solution we look for now also has to integrate with LDAP. Zimbra uses LDAP internally and provides extensions to allow for single sign on. This will allow us to manage user accounts centrally.

Having used Zimbra, we now had some Linux expertise in house (more on this later) and decided to trial Request Tracker. This is a Web based tool that receives emails sent to specific addresses and delivers them to Queues set up within the system. It also has an FAQ Management system (RTFM) which integrates with Request Tracker allowing our staff to formulate standard responses to common questions. This saves time and effort. You can define arbitrary queues, and groups of users, permissions assigned to a user/group/queue combination. It is an incredibly powerful tool and because it is written in perl easily extensible (if you know perl). It supports a multitude of databases ensuring that it is likely to support a database  you are already using.

Of course, as with a lot of Open Source systems, this is also the major problem as well. Because *everything* is configurable, it means you have to configure everything. They options are mind numbing. Once it is set up, you should not have to play with the permissions too much more, but if you do, be ready to start scratching your head for a while. In addition to this, because the system is so easily extensible, some functionality is not easily available unless you write some perl code. For instance, it makes sense to define a single automated response, rather than trying to create 20-30 of them for each queue, but if you do that, there is no obvious way of stopping a particular queue from using the global one. Unless you write some perl code. There are also some extremely odd artifacts in the user interface – for instance, when replying to a ticket, rather than having the recipients checked and allowing you to uncheck people who shouldn’t receive the reply, instead everyone is unchecked and you have to explicitly click on the ones who should not receive the replies. A usability expert would have a field day with that one.

While RT integrates partially with LDAP, it will not take the group membership from LDAP, so you still have to manage every user in two places. This is painful. The other integration issue we have yet to address is to tie in customer tickets with our internally developed system to manage customer profiles etc. Ideally these would be linked. We plan on revisiting this when we look at ERP implementation.

So is RT a good solution? Well it is certainly very powerful and if you can live with the geekyness (and have perl expertise in house), I would recommend it. For us, I would drop it in a minute if there was a more user friendly solution out there. Any suggestions?



Email strategy

October 15, 2008

Having decided to migrate to Open Office, we then needed to decide what we were going to do with regards our Email. Everyone had been using Outlook, connected to the Small Business edition of Exchange. This worked reasonably well except for the fact that Exchange didn’t have a built in Spam filter which resulted in hundreds of Spam emails being delivered per day to various people within the organisation. There were also Desktop support issues with Outlook; when the pst files get larger than 2 Gig corruption is likely to occur which did factor into our thinking. The Small Business edition of Exchange had several key limitations for us including a limit on accounts and also total file storage. This meant that we could not keep our email centrally (and hence backed up) and were about to run out of users. We needed to find a replacement.

Our basic strategy is to migrate as much as possible into Web based applications. This reduces desktop support costs as well as hardware costs (eventually – when we have no desktop applications required any more). As such we went looking for a Web based email solution. We had a look at a variety of solutions and eventually settled on Zimbra. This looked to be extremely full featured with a Web interface that was exceedingly close to that of Outlook (2003) which the users were already used to.

Running through our due diligence on the software we even discovered that Microsoft themselves could find little to criticise (see: Microsoft’s curious infatuation with Zimbra). With Zimbra being Open Source, we downloaded it and trialled it with some of our users to find it worked, very very well. It has built in anti-spam which immediately cut down on a huge percentage of the Spam received, while providing a usable interface for most of the users.

One user didn’t like the fact that messages were marked as read in the preview pane (this was subsequently fixed by Zimbra in their v5 release) and for users that had to download attachments regularly, it was slightly less well integrated with the Desktop than Outlook was. However, the increase in efficiency as a result of the Spam solution more than made up for that. With the v5 release, the cross mailbox conversation view is astonishingly good and everyone who has used it has commented on this. It is far better functionality than we have see in any Desktop app. An additional benefit is that the same interface is available when travelling as within the Office (without requiring a VPN to be set up).

While we started off with the Open Source version, we migrated over to the Network Edition after 6 months – mainly because we had migrated critical emails from the Desktop PST files that Outlook had used to ensure that we had backed up email on the server. This resulted in a much larger Email store than anticipated and with the Open Source edition, we only had offline backups which started taking in excess of an hour to run. Migration to the Network edition allows us to have online backups which makes life much easier. It also cost far less than upgrading to the full version of Exchange.

The upgrades for Zimbra are excellent – it is being actively worked upon and each new release brings us functionality that we find useful. The latest version (as of October 2008), v5.10 apparently provides automatic translations courtesy of Yahoo – which for our Customer Service team is of major interest. We shall be testing this shortly.

I would like to find a downside to our transition to Zimbra, but the experience has been great. We can highly recommend it. While there was some initial resistance to migrating away from a desktop email client, a year later everyone is using the Web interface smoothly.