stressfree - server

BIMserver and the potential of server-side BIM

David — Thu, 26 Feb 2009 10:20:39 +0000

We are now at a stage where a computer's speed and network connection are no longer significant process bottlenecks in digital architectural design. As a consequence the need for efficient digital collaboration tools within the architecture, engineering and construction (AEC) industry is a growing requirement. The BIMserver project from TNO and the University of Eindhoven is exploring how collaborative design can be improved through the combination of Building Information Model (BIM) and open source server technologies. Unlike conventional, workstation-based CAD software, BIMserver stores BIM data within a dedicated server where it can be accessed by all members of the design team simultaneously. Whilst conceptually not a new idea, the project is the first to move beyond the research lab and be promoted as software (almost) ready for production deployment within AEC organisations.

What is a BIM server?

BIM in its most general sense is a collection of 2D, 3D and textual data that when assembled within a computer’s memory creates an accurate and detailed representation of an architectural project. Like its predecessor CAD, BIM data is typically stored in a digital file (or files) where it is accessed directly by complex, workstation-based applications such as Revit and Microstation. In contrast a BIM server stores all design data internally and exposes its information to client applications through a series of well controlled and documented interfaces. This has a number of practical and technical advantages, the most significant being all client applications read from, and write to, the same digital model. In comparison when using a file-based BIM it is up to each participant to ensure they are working on the latest revision of the project’s files. Additionally by centralising the flow of data a BIM server enables near real-time collaboration as changes to the model are reflected on all clients each time their view of the data is refreshed from the server.

A functional overview of a BIM server ecosystem (click to enlarge)

Another important characteristic of a BIM server is that the building model exists as a live entity, distinct from the client applications that interact with it. This means client applications are simpler to write because they do not need to know how to comprehend an entire digital model, they simply need to ask the BIM server for the subset of information that concerns them. For example using a traditional file-based BIM an application that counts the number of doors in a design needs to parse the file, construct an in-memory model, and then count the door instances. In comparison a BIM server handles the parsing of the digital model, all the client application needs to do is construct a query that asks how many doors the design has. Another benefit of a live BIM is that the server can automatically respond to outside events such as scheduled processes or changes to data hosted by external services. For example the BIM server could monitor the pricing and availability of materials used in the design and automatically update the model to reflect these variations. The end result is that instead of being viewed as a static, “dumb” file, the migration of the Building Information Model into a server would create a far more dynamic and accessible project resource.

Why BIM servers are not common place

The use of computers within the AEC industry stemmed from the increased affordability of single-user workstations during the 1980s and 90s. This emphasis on workstations was due to the visually intensive nature of the AEC workspace and the slow networks of the time which could not efficiently communicate such data. In comparison many other industries had already adopted centralised mainframes and mini-computers as core computing platforms well before this desktop revolution. This different pattern of computer adoption has had a significant effect on how AEC software has evolved relative to industries with a history of centralised computing. Rather than relying on a large, server-based infrastructures, tools such as CAD were optimised to run on independent workstations with few, if any ties to external digital services.

This small but significant characteristic has had a profound influence on the evolution of CAD, BIM and how AEC professionals digitally collaborate. As other industries have encouraged consolidation of data around servers and the Web, the AEC industry has instead sought faster workstations to enable the building of more detailed models. Whilst this high-powered, but isolationist strategy has enabled excellent static outcomes, it has come at the expense of a team's ability to efficiently collaborate digitally. This inefficiently stems from the interoperability issues which exist between different applications, and the inherit shortcomings of software designed primarily for use on standalone workstations. For example whilst the majority of CAD and BIM software enable collaborative workspaces, this usually involves partitioning off an area of a model so only a single person can make changes. But as CPU and network performance has begun to exceed demand, researchers and product managers are exploring how collaboration can be improved through the use of centralised BIM servers.

BIM as a Service

The idea of a centralised service that hosts core business data has been a central facet of software architecture since the introduction of mainframes and the client-server paradigm. In the workstation-dominated AEC industry, centralisation is limited to file servers that provide convenient locations for BIMs when it is not being worked on in isolation. However from a collaboration perspective it is far more economical to access and modify a centralised BIM because it is easier to ensure the currency and validity of its data. A centralised model also reduces interoperability concerns as the interactions between client and server are limited simple transactions, for example 'read this' or 'write that'. In contrast a standalone piece of software must correctly comprehend an entire data file, and if modifications are made, write its contents back in exactly the same way. This has proven to be a very demanding problem to solve for relatively simple office documents, but when taken to the level of complexity of a BIM, the task becomes almost impossible.

There have been many AEC research projects that have implemented a client-server architecture for collaborating on CAD or BIM models. Unfortunately for a variety of reasons none have made the transition into mainstream AEC use. Perhaps the most notable of these was the IFC Server from the VTT Technical Research Centre. The project was an Internet-based model server that built upon two significant standards, the Industry Foundation Classes (IFC) building data format and the SOAP web services protocol. Leveraging these existing industry standards made the task of creating software clients simpler because developers could reuse existing knowledge, documentation and tooling. Unfortunately the project never got beyond the research lab, but five years on many of its concepts are alive and well within BIMserver.

BIMserver - Industry meets Research

BIMserver is both an open source model server project and a collection of European organisations committed to developing the concept further. The project lead is Léon van Berlo of TNO, a non-profit organisation established in the Netherlands to encourage innovation within small and medium businesses. Working as a scientific partner is the University of Eindhoven, whilst both the CSIRO and VTT are investigating ways in which to take part. Alongside these research institutions, nine businesses have expressed an interest in making compatible client software and others are simply keen to explore the potential of the server in practice. In an effort to foster broad adoption and encourage developer involvement BIMserver is free and its code released under the GPLv3 open source license. This is relatively unique for the AEC software industry, where closed source licenses and high per-user licensing costs, especially for BIM software, is the norm.

A collection of screenshots from BIMserver 0.1RC2 (click to enlarge)

An underlying theme of BIMserver is to establish a platform that can be used in a variety of situations and software developers can build upon. This philosophy extends to the code itself which is written in Java, a robust and popular language amongst businesses and casual programmers. The application itself can then be deployed to any modern Java web application server, or run as a standalone program using the light-weight Jetty library.

“The technology we are using is based on the latest stable technology. We are using the Eclipse Modeling Framework, BerkelyDB, Tomcat, Jetty, Java, et cetera. This is done to get BIM from IFC (read: Step) into the ‘normal’ world of everyday programming. When that is done every ‘dorm-room programmer’ can work with BIM and IFC (instead of having to learn the Step language first). This could (we hope) be a enormous driver for the adaptation of IFC and BIM.”

Léon van Berlo, TNO

An important factor in these technology decisions is they are all vibrant, open source projects, allowing the BIMserver team to effectively ‘stand on the shoulders of giants’. This makes the tasks of development and support simpler because there exists an extensive knowledge base around the server’s fundamental components. Also from a business standpoint it is reassuring that if BIMserver or one of its dependent projects should cease to exist, the organisation can continue to operate and extend upon the existing open source code.

Deploying and using a BIMserver

The benefit of being written in Java is that BIMserver can be run on any platform that supports Java 6 such as Windows, Mac OSX and Linux. In a production environment BIMserver should be deployed within a Java web application server, for example Tomcat, JBoss or GlassFish, as these provide optimised and scalable web engines. Once operational client applications interact with the BIMserver through a SOAP web service interface that implements the Building Information Exchange Protocol (BIEP). BIEP is a new protocol from the Open Source BIM Initiative which combines the best of the Sable and oBIX projects. Whilst slightly concerning that BIMserver is implementing a new protocol rather than reusing something that exists already, considering the immature nature of this market it is not uncommon or necessarily wrong.

Client-side BIM applications will access the server’s data natively or through third-party plug-ins which translate responses from the BIMserver into instructions the host application understands. The quantity and quality of the client application support will be the determining factor behind BIMserver’s success in the long-term. AEC professionals are primarily interested in efficiently achieving their allotted work using reliable tools they understand. If adoption of BIMserver requires a significant toolset change, or the use of software that is slow and unreliable, the initiative will ultimately be rejected. Unfortunately for BIMserver proponents this poses a chicken and egg dilemma; third-party support hinges on demand, but server deployments will not occur until applications support it. Given this situation perhaps the best long-term yardstick of BIMserver’s success is whether or not it can garner support from one of the major BIM vendors. If this commitment can be achieved then it will almost certainly mark a tipping point in both adoption and third-party client support.

Beyond the SOAP interface’s computer to computer communication there is a limited web interface for the manual management of the BIM models stored on the server. As the project matures this side of BIMserver will be developed, plus extra functionality can be added through the installation of licensed plug-ins. Compared to a file-based BIM the benefit of a web interface is that it enables ubiquitous access to the underlying project data. Whilst in its infancy, over time many tasks related to the consumption of BIM data will no doubt be possible via the Web, for example checking that onsite construction drawings are the latest version. From a collaboration standpoint this is very significant because currently access to file-based BIM data is restricted to those with access to the file itself and the desktop application needed to read it.

Alongside the complex SOAP interface is a limited collection of REST web services. Unlike its often unwieldy and over engineered cousin SOAP, REST web services are easier to understand and use within applications on the desktop or web. REST is a new web service standard, but it has been implemented using proven HTTP concepts and existing technologies. Due to this simplicity and ubiquity REST is fast becoming the dominant standard for web service-based information exchange on the Web. With this in mind it is important that BIMserver has strong support for REST, not only because it is easier for developers to use, but it is also a more appropriate choice for the data communicated by a BIM server.

The Technical Challenges Ahead

The initial release of BIMserver is promising from a conceptual and technological standpoint, but it has a long way to go before mainstream deployment within AEC organisations can be considered. Of highest priority is the growth of the BIMserver documentation and developer community so that third-party software vendors can seriously consider adapting their software to work with it. Beyond growing the ecosystem the server at its core also needs to go through several iterations to expand its feature-set and establish itself as a robust and scalable platform.

“I'm saying it's okay to ship crap - I'm not saying that it's okay to stay crappy. A company must improve version 1.0 and create version 1.1, 1.2, ... 2.0. This is a difficult lesson to learn because it's so hard to ship an innovation; therefore, the last thing employees want to deal with is complaints about their perfect baby. Innovation is not an event. It's a process.”

Guy Kawasaki
How to Change the World: The Art of Innovation

There are three technical areas the BIMserver team need to focus on during these forthcoming iterations; design versioning, scalability and robustness.

Design Versioning

Version control management is an important topic for architectural collaboration or any line of work which relies on comprehending changes to generated content over time. Strangely whilst the AEC industry has checks and balances to monitor design revisions, these are generally manual processes such as file naming standards and revision spreadsheets. In contrast within the field of software development the use of version control systems such as Subversion and Git are not just common place, they are a necessity given the complexity of computer program code. If implemented well the inclusion of a sophisticated design versioning system within BIMserver and its client interfaces may help spark a revolution in digital architectural version control. Unfortunately version control and conflict resolution is a complicated subject which may take years of testing to perfect, but the first product to do so will hold a compelling, and lucrative, competitive advantage.

Scalability

When deployed in production a BIM server will be the digital hub for an AEC organisation’s project information. In order to fulfill this role the service must be capable of scaling to simultaneously serve large numbers of client connections and store vast quantities of data. Appreciating that peak demand will always exceed the capacity of a single computer is the most important aspect of scalability. Hence the components of a BIM server (web interface, processing logic and storage) must be loosely coupled so that they can be easily distributed across multiple computers. Architecturally this is a straightforward task, but getting this to work reliably without severely impacting performance is a challenging, and at times complex process. Fortunately BIMserver’s ability to be deployed within a Java web application server is beneficial in this regard because there is a large knowledge base built around scaling such services. This being the case there are still many application design and coding decisions that can act as scalability bottlenecks.

Robustness

If a firm with a large number of employees is to depend on BIMserver the software needs to demonstrate it can perform reliably under a range of situations and over long periods of time. Most importantly each transaction that occurs between a client and server must be guaranteed because in the context of the architectural project the information exchanged is potentially very valuable. If a single transaction were not to be processed correctly, for example the realignment of a wall, this could have significant and potentially costly ramifications if it was not detected and corrected. During the course of BIMserver’s life such errors will undoubtedly occur, so it is important that a support infrastructure is in place to rectify problems and alert other BIMserver users of their existence. To facilitate such robustness many open source projects have two or more branches of code; a stable, professionally supported release, and a development package in which new features are added and tested. Establishing this infrastructure is vitally important for business adoption, but whether those currently driving BIMserver are capable of undertaking all these responsibilities is yet to be seen.

Is the AEC industry ready?

BIMserver, like any innovation, is concept now in search of its actual audience and problem space. In such a situation the use of open source is wise because it allows potential users to test the software in a variety of situations without having to commit significant resources. This exploration process will highlight aspects of the architectural design process that will benefit from BIMserver and scenarios where its application is unsuitable. Whilst it is difficult to say what these will be, there are broader issues around the BIM server concept in practice which need to be overcome before mainstream adoption can take place.

The most challenging of these issues is whether architectural practice can be sold on the idea of a BIM server and whether the cost of its demonstrated benefits can be justified. A paradigm shift to server-side BIM is a difficult proposition given it must overcome decades of momentum and investment in file-centric workflows. It is harder still when most AEC organisations are still grappling with the transition to BIM and how this will actually benefit their practice. BIMserver’s open source strategy mitigates this somewhat because it allows experimentation without commitment, but at some point actual marketing will need to be used to influence opinion. Here again this will probably rely on a major BIM vendor adopting the concept (once proven) and pushing it through their various marketing and distribution channels.

Beyond actually selling the concept is the hurdle of getting AEC organisations to make room for its implementation within their limited I.T. budgets. Unfortunately this is problematic because most architectural professionals consider the majority of their income is from digital content created on their desktops. This workstation-centric culture means managers will not hesitate to spend $5,000 or more workstations or BIM licenses, but to compensate investments in server infrastructure are comparatively small. Getting companies to appreciate that implementation and support of a business critical BIM server is not a low cost exercise will also pose its own set of issues. Much to the ire of hard-pressed I.T. staff, production BIM servers will behave quite unlike file servers, and given their complexity will undoubtedly require more support.

Conclusion

The successful introduction of BIM servers could revolutionize digital collaboration and the use of BIM within the AEC industry. The BIMserver project is a very good step in the right direction, but it faces a daunting mountain to climb if it is to move from a niche research test-bed into a mainstream piece of AEC infrastructure. The first step in this process is identifying what industry sectors are best suited for BIM server deployment and the benefits it will actually generate. BIMserver is ideally suited for this role because it is open source and can be tested without commitment. Whether the BIMserver ecosystem can achieve critical mass and gain the support of at least one major BIM vendor will be interesting to watch. It is certainly a very promising concept, but whether the big fish bite will be the difference between a nice idea and revolutionary product.

Mac Serve anyone?

David — Sun, 20 Aug 2006 04:02:43 +0000

Probably the biggest untapped server market out there is at the small business level (two to twenty people). At the moment there are a number of Small Business Server (SBS) solutions in this market from a number of companies:

The desktops are the servers

Using Windows file sharing, Samba and Bonjour the business configures their own little desktop-based server for file and print sharing. Thanks to semi-intelligent Internet gateways from the likes of Linksys/DLink that handle DNS and DHCP setting this sort of thing up is relatively easy. Whilst ugly this is probably the most common file/print/Internet sharing solution in most non-tech related small businesses. Unfortunately when things go wrong they can really go very bad, I've seen a number of desktop-servers go belly up because of Internet spyware and viruses.

Microsoft Small Business Server

Micorosft Small Business Server is the most widely used dedicated small business product and by and large Microsoft have (unfortunately) done a pretty good job on it. It is fairly pricey but relatively easy to setup. Microsoft technicians are a dime a dozen (mainly because MSCE's come in cereal boxes these days) which is important because being a Microsoft product it is bound to break thanks to funky software design or rushed out critical security patches. Another positive is that as Windows is the dominant platform support for printers is all but guaranteed.

Linux Small Business Servers

Companies like ClarkConnect produce very tidy small business server alternatives based around Linux. By and large these are pretty good software products that are relatively straightforward to maintain but can be difficult to setup if you are not a semi-experienced Linux head. Products like ClarkConnect have a great feature-set and when they work things go really well but as there is a lack of decent affordable Linux technicians or concise MSDN-like knowledge bases problem solving when things go wrong can be a hit or miss affair.

Novell Small Business Server

Novell do very good 'enterprise' software but compared to the Linux and Microsoft SBS alternatives their SBS offering is too complicated as it is essentially their enterprise software shoehorned into a constrained licensing system. If you know Novell's products and have access to a highly trained (and expensive) Novell engineer who understands Netware or Linux, eDirectory and BorderManager you'll have a system that runs for years without any problems. Unfortunately the overwhelming majority of businesses out their don't have access or the money to pay for such a resource which puts a solution like this beyond their reach.

Where's Apple?

Apple make great consumer level hardware/software but are like fish out of water when put into an enterprise environment. Even their XServe/XSan products are not for general enterprise use and are specifically targeted at the multimedia professionals who tend to favor Apple products. Apple do not have a product that targets the small business server market which is an area where it looks like they could stand to flourish especially as their desktop/laptop sales in this market grow.

OSX Server is a stable, easy to setup and configure server-level operating system. What is planned in Leopard, like calendar sharing, network search and improved Windows Domain support looks like it will be made even better. OSX Server would be ideal in the small business arena as it is easy to setup and can be maintained by non-technical staff with little training. It offers the reliability of a Unix operating system and services like Samba with the ease of use granted by Windows SBS.

Unfortunately OSX Server can only run on Apple hardware and therein lies the problem. The only reasonable hardware platform in a small business environment is the Mac Mini. XServe is just too big for small businesses, it is like hitting a nail with an overpriced sledgehammer. Even the new Mac Pro's are too big and expensive for the low-end server market. Small businesses are not prepared to pay for a high-powered desktop with all the latest bells and whistles just to put it in a corner and treat it like a low-cost Dell. Arguably second-hand Apple gear like a PowerMac or Cube is a great choice but then you run into maintainability concerns plus no-one wants to put their business critical data on a second hand, out of date server if they do not have to.

Supersize the Mac Mini to fill a product void

That leaves the Mac Mini as a viable candidate but size is its major drawback. Performance-wise it is the ideal fit for a small business server where top of the line CPU or graphics performance is not a factor. A larger Mac Mini (for arguments sake called a Mac Serve) capable of fitting three 3.5" SATA hard drives and four sticks of RAM would suit most small businesses expansion needs. The only other hardware addition to the Mac Serve would be an extra ethernet port to handle DSL/cable modems and preferably some extra USB ports to accommodate all the office printers that seem to accumulate.

Cost-wise there would be no reason why it would not be too much more than a standard Mac Mini given the basic hardware and manufacturing similarities. If a Mac Serve/10-user OSX Server bundle cost US$1500 it would be a pretty hard combination to say no to given its ease of use, compact size, features and competitive price when put against Microsoft SBS on a Dell server. What's more the Mac Serve would work out of the box and could in theory be setup by non-technical users who just know they want to share files and printers on a dedicated (and good looking) server that sits out of the way on a shelf.

It is a shame that the chances of something like this coming out are tiny and the likelihood of being able to run OSX Server on non-Apple hardware even lower. It looks like a great small business capable operating system but given the fact it cannot be deployed in offices economically to compete against Microsoft or Linux alternatives it will just stay in the realm of multimedia professionals and Universities, oh well, I guess we can always dream.

Large file support with an Unslung NSLU2

David — Mon, 14 Aug 2006 04:03:57 +0000

I have written previously on how cool the little NSLU2 is as a customisable NAS device. I have set mine up as a little backup device, it silently backs up my server files (using rsync), creates tar files from all the files and then presents these archives to Retrospect on my Mac for backing up to external media and taking off-site. Unfortunately the default 'ls' and 'tar' programs that come with the Unslung distribution do not support large file sizes or long filenames to fix this problem download the far more up-to-date versions using ipkg:

# Whilst logged in as root (or use sudo)
ipkg install coreutils
ipkg install tar
mv /bin/ls /bin/ls.old
mv /bin/tar /bin/tar.old
ln -s /opt/bin/ls /bin/ls
ln -s /opt/bin/tar /bin/tar

Running these commands will replace the outdated programs with their newer counterparts which results in far smoother backups.

Migrating to and using Scalix 10

David — Mon, 31 Jul 2006 00:15:29 +0000

Last week this post on my local Linux user group got me rethinking email servers. The last time I did this was about six months ago when I made the move away from Hula onto Zimbra. At the time I looked at Scalix 9 but was deterred by its need for X-Windows during the install process and the overwhealming amount of installation documentation that came with the 100+mb download. I decided to go with Zimbra because it offered a text-based installer and some very nice looking UI features on the webmail client.

Unfortunately over time I have become tired of Zimbra for a number of reasons:

The installation essentially takes over the host operating environment and installs its own version of popular open source applications like MySQL and Apache. Consequently keeping up with security patches involves upgrading the entire mail system which is no straightforward task.
Zimbra is very resource intensive and takes what seems like forever to initally load and shutdown. This seems to mainly revolve around their management tools which store all configuration information in an LDAP database and dynamically build the traditional configuration text files on loading.
Because most configuration information is stored in the LDAP datasource making configuration tweaks by editing the traditional text cofiguration files is not possible. Instead you must read through the Zimbra administration documentation to identify LDAP attributes to tweak in order to achieve the intended output. This is frustrating and not very transparent when things go wrong.
The webmail interface is slow to operate and load (especially for dial-up/slow DSL users). After about three months I disabled the webmail interface and began using Roundcube's php IMAP frontend. There was a loss of functionality but at least performance was smooth on any connection.
Because of the way Zimbra sets up its own services it is hard to integrate it successfully into an existing environment. I only have one IP address and port 80/443 is forwarded through to my LAMP server. After a great deal of experimenting I could not get the LAMP server to natively host the Zimbra webmail client, instead I had to resort to using a nasty mod_proxy configuration (which probably attributed to the slowness for external users).
Zimbra does not offer Outlook/iSync connectors for its open source users, in order to get access to these connectors you must pay many $$$ a year in licensing costs. In small installations this is just not cost-effective.

Scalix 10 on the other hand addresses many of the shortcomings I found in Scalix 9 and Zimbra.

It ships with a console based installer which is a welcome sight. Rather than providing its own stack it integrates into your operating systems existing applications (Sendmail, Apache, Cyrus-SASL and even Java if you want). This makes keeping your server up to date with the latest security patches a lot easier and upgrading to the latest and greatest Scalix release less of a concern.
The webmail interface is based entirely in Java (running in Tomcat) and can be easily setup to be accessed from an external web-server (such as a dedicated LAMP box) using mod_jk.
Scalix even in the free Community Edition version offers 25 free Outlook Connector licenses which makes it practical for use within small businesses.
Rather than storing all configuration data in an LDAP datasource most configuration occurs in the standard text files for the system with a little bit of tweaking taking place in the /var/opt/scalix/ directory. This makes tweaking a lot easier as information found on the Web can be directly applied to Scalix.
There seems to be a great deal of support available for Scalix ranging from the comprehensive bundled documentation and Knowledge Base through to the Community Forums and Wiki. Between those four sources of information I haven't yet found a problem that has not been able to be resolve.

Installation

I installed Scalix on a virtual Xen instance which contained a minimum install of SUSE 10. After accepting the license agreement the installer ran through a system and dependency check. At this point it returned a nice list of changes I needed to make to the system before installation could occur. This mainly revolved around the installation of some packages and a tweak of the /etc/hosts file in order to reduce the risk of confusion later on. It also gave me a warning about memory which would be easily solved later on by giving the Xen instance access to more server memory.

Console installation (click to enlarge)

Once the dependencies were met Scalix happily installed. At the end of the process I was asked if I wished to install included versions of Java/Tomcat or use my own. I opted to use the bundled versions out of simplicity and on looking at the configuration files after the installation I can see it is a straightforward job if you wish to change your mind and use a different JVM or J2EE server once things have gone into production.

With Scalix, Java and Tomcat installed, the server reconfigured and the basic admin account setup all the services were started and the installer finished. It was the moment of truth so I fired up a web browser and made my way to the Scalix administration console.

Server administration via SAC (click to enlarge)

Disabling mod_deflate because of Firefox 1.5 on OSX

At this point I came across my first issue and it was not really with Scalix. For some reason Firefox 1.5 for OSX on my Mac cannot handle content compressed with mod_deflate very well. Consequently the Scalix administration interface took forever to load. Switching to a different browser fixed this problem but as Firefox was my default browser I decided to disable mod_deflate for the time being.

This involved tweaking Scalix's Apache configuration files. In doing so I was pleasantly surprised to find that the Scalix installer had been very neat and courteous when making its modifications. I have seen a number of applications make horrendous system configuration changes but Scalix was a good server citizen. It had added three extra .conf files into /etc/apache2/conf.d and each were well named and commented. The installer had also modified the /etc/sysconfig/apache2 file to add the jk and deflate modules to Apache and this change too had been performed in an appropriate manner. I disabled the configuration file in /etc/apache2/conf.d associated with mod_deflate, restarted Apache and everything worked as expected in Firefox.

Adding user accounts and doing basic system maintenance

Using the web-based Scalix Administration Console (SAC) it is possible to perform all the basic mail administration tasks like adding/deleting users and monitoring mail queues. The console is designed to enable the management of multiple mail servers but the functionality available through it is not as extensive as other administration interfaces I have used. For example there are no options to edit what mail services (pop/imap/smtp/webmail) start on boot or modify details about a particular service (like port numbers, security settings, etc). Changes like this are possible but it requires console-based editing of configuration files. Personally I do not see this as a bad thing but if you are pro-GUI administrator making the switch from Exchange or Zimbra you will probably be disappointed.

User administration (click to enlarge)

When creating user accounts you can select whether the account is Premium (Outlook, IMAP, POP3), Standard (IMAP/POP3) or Internet (Webmail only) which is a nice touch. The Community Edition of Scalix allows only 25 Premium accounts, any more than that and you must upgrade to a paid-for version. Upgrading to a different version of Scalix is as simple as purchasing a license and entering its details into the SAC. This means a Scalix Community Edition server can be installed, tested and demoed at zero-cost and then painlessly upgraded if and when the server goes into full-scale production.

Scalix server statistics (click to enlarge)

Migrating existing mail

Scalix provide a suite of tools for seamlessly migrating users from Exchange which is their core target audience. Unfortunately as I was not running Exchange I could not test these out. It seems like the standard way of migrating non-Exchange mail onto Scalix was through the manual creation of user accounts and then transfer of mail using the Perl-based imapsync tool. There maybe a smarter way of doing this but the Scalix documentation I found did not provide any hints.

Imapsync is a very functional piece of software but it is a little troublesome to setup if you are not used to Perl. It requires a number of libraries that by default are not installed with Perl but fortunately are all available in CPAN. Once the tool is running migration was straight-forward but it is important to set the --setinternaldates flag so that migrated mail retains the original arrival time (otherwise everything will get listed as turning up on the same day). The process does take a while and is fairly resource intensive, running the imapsync process from a third computer during a time when mail activity is low is recommended.

Using Scalix

With the user accounts and mail transferred it was now a case of using it. The Webmail interface works very well and is a lot snappier than Zimbra's. It is also relatively straightforward to configure Webmail to be routed through an intermediate server providing other Web services. Doing so requires some understanding of mod_jk which is a bit of a dark art though not as bad as regular expressions or mod_rewrite. Fortunately the installed Scalix configuration files are well commented and provide even mod_jk novices with enough insight that setting configurations like this up should not be too much of a problem.

Webmail interface (click to enlarge)

There was a weird bug with Scalix and OSX Mail's Kerberos implementation. On setting up an IMAP account in Mail the application automatically sets itself to exchange passwords using Kerberos but this does not work (my guess is an incompatibility between the two implementations). This issue can be solved by changing the authentication encryption to MD5 in Mail. The weird thing is when setting up Scalix as an SMTP service Mail automatically sets encryption to MD5 and works quite happily without further user input.

Scalix with Outlook

I do not use Outlook but I was interested in trying out the Scalix Connector for Outlook. Setting up the connector was more than a simple case of pointing Outlook to Scalix and telling it that it was actually Exchange. The process required the installation of a Scalix Connector package on the Windows client and then migration of the standard Outlook account to a special Scalix-enabled version. Fortunately all of these tasks can be automated to enable network roll-out but I found the documentation just a little bit too light in places to feel really comfortable about what I was doing. Once setup the results were pretty impressive, 99% of all the Exchange functionality is available using the connector and it appeared to be very fast and stable.

The Outlook connector and webmail (click to enlarge)

Shortcomings for the non-technical administrator

By default Scalix does not ship with any anti-virus or anti-spam software. There are numerous pieces of documentation on how to set these things up but it revolves around making configuration file changes using the console. Here again Exchange administrators will not feel too comfortable and would probably prefer the Web-based check box functionality of Zimbra when it comes to setting up anti-spam and virus services. But if you are prepared to get your hands a little dirty the end-results will be a lot better, more flexible and most importantly when things go awry you will have a better understanding of what exactly is going on.

Conclusion

For those administrators out there that do not want to mess with complex console work Scalix is not for them. Installing and configuring Scalix will take more time than Exchange which will offset some of the licensing savings. However once it is up and running it is very stable and flexible system with all the power of Exchange without the licensing, security and reliability concerns that come with Microsoft software.