The newest version of MDaemon will be available for download on Wednesday, September 5th. The new release sees a number of new features to help IT administrators and end users alike, such as:
  • Message ticketing support
  • Consolidated Mobile Device Management (MDM) interface and ActiveSync policies
  • Hijacked account detection
  • Document sharing, drag & drop attachments and custom logos in WorldClient
  • Traffic compression to improve Outlook Connector performance
View the PDF briefing document here for more information. As soon as it's available you'll be able to download the latest version of the installer from our web site here.

Another week, another set of new features to look at in the beta version of MDaemon version 13. Let's look at one of the more useful business features of MDaemon, the ability to capture email arriving on group email address such as sales@ and support@, and storing them directly into public folders. This feature allows a group of sales or support staff to monitor the public folders and take ownership of the emails, sharing the workload.

One of the more common customers support calls i get relates to MDaemon suddenly sending vast amounts of spam email. This floods the outbound Internet connection and everything crawls to a halt. Secondary to this the server's public IP address can get listed on various external SMTP blacklists which the customer then has to request removal from.

So on to part 2 of my look at the new MDaemon 13 beta... I mentioned ActiveSync policies in my last post, well version 13 also sees the addition of one extra small, but very nice feature, in the ability to simplify the self sign-up process for mobile devices using the Autodiscover process. By removing the necessity to know the public DNS name or IP address of your MDaemon server, all a user now needs to connect their mobile device is their email address and password.

Over the last few weeks I've been experimenting with the latest Beta editions of MDaemon version 13 and thought it'd be beneficial to share some of the great new up and coming features you can expect to see in the release. Just before I wet your appetite with the first of them - don't forget, if you're interested in getting involved in the MDaemon beta test process you can apply to join the community by registering here. 

We have recently seen an increase in customers wanting to bring a large selection of PST files into their MailStore archive.  It's quite common for people to create local PST file archives of their own email and historically this was a common way to reduce the data within the mailbox on their mail server. The problem we see is that over time many users build up multiple local PST files and as these are scattered around on various client machines it gets very difficult and costly to keep them all backed up.  If you also consider in this scenario there is also no way for users to search each others archive it makes it very difficult to meet compliance requirements.

As part of ongoing improvements to our own network, I recently revised the way we approach backing up the SQL database that underpins our main company Web site. We currently host the web and SQL server in a local data centre and were taking off-site daily backups using a combination of BackupAssist and the Rsync add-on. This was adequate for restoring a snapshot of the website or database to the previous day, but I wanted to improve the frequency of our backups given how often the database is changing as we take orders throughout the day. Luckily BackupAssist was there to help!

I came across an issue on a support call the other day I thought worth sharing as it's bound to be something a few of you will see too.
The customer I was talking to was using the Windows imaging engine in BackupAssist to back up both their system drive 'C:' and a large data drive 'D:' (used for every day document storage etc.).
This was working just as expected and backups were updating quickly to a local USB hard drive when the inevitable happened - they had a local hard drive failure and of course wanted to perform a bare metal recovery from the last good image backup.

In the last couple of weeks I've come across a few customers with MailStore installations where they've experienced corruption of their archived data due to either a damaged disk, RAID failure or power outage for example. All of these situations are of course completely outside of MailStore's control but they're ones where the only practical recovery method is to rebuild from a previous backed up version of the MailStore data.

I often speak to users of Exchange alternative MDaemon who are wondering why they've suddenly started receiving a larger volume of spam than usual. When I take a look at their installations it's not uncommon to find a secondary mail server in place with its own MX record. It's this second delivery path that can be the root cause of the problem and it's not unusual for the customer to be blissfully unaware either, as quite often they're configured by the DNS provider or their ISP automatically.