by Mark O'Hare
Mimecast can confirm that its services are secure and unaffected now, and in the past, by the recently reported OpenSSL vulnerability known as the Heartbleed Bug or officially CVE-2014-0160. Mimecast has never used OpenSSL to provide TLS/SSL encryption. There is therefore no need for customers to take any action on their accounts related to the Heartbleed Bug. If you have any questions about your account, please contact customer support.
by Orlando Scott-Cowley
Today we’re pleased to unveil both a new Mimecast for Mac native app and a major upgrade to our popular Large File Send (LFS) service.
Mimecast for Mac
We know that today’s office has a mixture of PCs, Macs and mobile devices, and IT managers often have to battle to support the same level of email continuity and security, as well as archive access across all these platforms. With this in mind, we developed the new Mimecast for Mac app – it delivers the capabilities and ease of use previously only available to customers using Microsoft Outlook for Windows or the Mimecast web portal.
The new native app allows Mac users to search their personal email archive, effectively manage their spam and gain access to their full email account when Exchange goes down – enabling them to continue working normally. And, to help ease the burden on over-stretched IT administrators, Mac users can now be managed alongside existing Windows users from within the same central Mimecast Administration Console making their integration seamless and straight-forward. A video explaining the Mimecast for Mac app can be found here.
Large File Send Upgrade – Enabling Secure Collaboration
LFS allows users to send files up to 2GB securely and directly from within Outlook or the new Mimecast for Mac app. It’s a simple matter of attaching the large file as normal and pressing send – Mimecast does the rest.
LFS allows users to securely send and receive files up to 2GB in size directly from within Outlook or the new Mimecast for Mac app.
Before this, file size limitations put in place on Exchange by the administrator or by Office 365 made this difficult. To send large files, users were often forced to leave the safety of the corporate network by resorting to consumer file sending services in the cloud. Alternatively, IT administrators had to invest in complex and expensive specialist equipment on their network. Users became frustrated and their productivity was impacted. LFS puts a stop to that.
Today’s update makes it possible for the recipient of a large file sent by LFS to work on it and then use the same service to send it back securely, whether they are a Mimecast customer or not.
LFS enables collaboration on files, even when the recipient is not a Mimecast customer. They can send files back to the originator by simply dragging and dropping the files into a secure portal. The originator is then notified that new files are available to download. The shared files remain secure, on the Mimecast archive, and anti-virus and content-scanned throughout. Once the large file exchange is complete, the link expires.
IT administrators value the service because it also means, aside from the file remaining safe on the corporate archive at all times and subject to their security and content controls, it completely bypasses their infrastructure. It doesn’t impact network performance or weigh down email servers. It sits in the Mimecast cloud and is shared from there.
In addition, the new version of LFS features an improved user interface and offers the sender the option to turn off or on the access code required to download the file.
LFS gives users the functionality they need to perform their daily tasks and IT departments can rest easy knowing they are back in control of valuable corporate data. We think that makes everyone a winner.
If you’d like to find out more about the new version of LFS, a video explaining the service can be found here.
Both the new Mimecast for Mac app and upgraded version of LFS are available now.
by Orlando Scott-Cowley
We’ve only been in the New Year a few weeks and it’s quickly becoming clear that 2014 is the year of the cloud. Even the committed laggards or cloud refuseniks are being compelled to move some services into the cloud.
But you would expect us to say that of course. As in all things, there’s always another point of view to consider. One of our older posts on the value of the cloud received a challenging comment that warrants a response. This comment gave us all the opportunity to reconsider why a commitment to cloud services makes sense for customers of all kinds and sizes, even those within regulated industries.
Barriers to cloud adoption have been broken down – initial reticence regarding data ownership in the cloud has been met with credibility built by vendors
The comment challenged our stand on the cloud:
“…Regulation may require certain data controls/protections/audit trails which a Hosted product can’t provide and Exchange (Windows Server Standard plus Exchange software, backups, redundant power, etc.) remain cost prohibitive….”
Initially I was just going to post a response to the comment, but as it has been some time since the original post, I thought that it was worth bringing this discussion right to the top of our blog. Thank you John for taking the time to comment on the post – I hope this post acts as an update, a reassertion of our belief that the cloud is actually more and more an ideal solution specifically for companies of all sizes dealing with the additional pressures of regulatory control.
Most Mimecast customers face these issues. So why is the cloud the solution to their needs?
In the world of email, these industries have high demands on storing and accessing their data – they need sophisticated e-discovery capabilities, granular legal hold functionality, centralization of archives and rigorous compliance capabilities. They have a heavy security requirement too, of course.
The bottom line is that neither on-premise or cloud archiving solutions address these demands perfectly. But what is clear is that in terms of centralization of data, cost to the business, and time to implement, cloud has and will continue to be the better option. And it’s these powerful values which are driving business as a whole towards hosted services, including finance and legal.
As far back as 2011, data were beginning to emerge about this wholesale shift to cloud services. At that point, about one-fifth of companies had already moved their email archiving to cloud or hosted options, away from on-premise. In the same study a significant number of those maintaining capacity in-house had experienced failures in hardware and software implementations, and one third had lost emails – possibly as a result.
Also, remaining barriers have been broken down.
Initial reticence regarding data ownership in the cloud has given way to proof of credibility built by vendors providing well-trained engineers and experts available to support the service. These services offer parity with traditional options. For example, in the case of archiving, email should be stored in its original format mirrored to multiple locations. In addition, written into a vendor’s SLA should be a guarantee that the customer’s data will only be stored within appropriate jurisdictions, to ensure compliance with the regulations imposed in some sectors.
So to answer the original question, is the cloud always the solution? The answer is actually in a few cases it may not be for everyone. But as cloud services continue to mature, these exceptions will become few and far between.
by Clint Boessen
Microsoft has changed the way Offline Address Book (OAB) Distribution works over previous versions of the product to remove a single point of failure in the Exchange 2007/2010 OAB Generation design. While this new method of generating and distributing the Offline Address Book has its advantages, there is also a disadvantage which can result in a breach of privacy especially in multi-tenant environments. In this article we will be looking over how OAB Generation worked in the past as opposed to how it works now highlighting both the good and the bad.
Back in May 2009, I published an article entitled “How OAB Distribution Works” which has received a large number of visits and can be found on my personal blog under the following URL link. This article explains in detail the process behind OAB Generation in Exchange 2007 and 2010 and I highly recommend this read to anyone who is not familiar OAB Generation in previous releases of the product.
If you have not read the above article, let’s quickly summarise. In Exchange 2007/2010 every OAB has a mailbox server responsible for OAB Generation. The mailbox server responsible for OAB generation would generate the OAB according to a schedule and place it on an SMB share under \mailboxservernameExchangeOAB. The Exchange 2007/2010 CAS servers responsible for distributing this Offline Address Book would then download the OAB from this share to a folder advertised through Internet Information Services (IIS). Outlook clients then discover the path of the IIS website through autodiscover and download the files located under the OAB IIS folder through HTTP or HTTPS. If you need to gain a more in-depth understanding of this process again I encourage you to read the blog post above.
Now the problem with the above design is every OAB has one Mailbox server hard coded to be the server responsible for performing OAB Generation. The whole point of Exchange Database Availability Groups is to allow mailbox servers to fail and have databases failover to other mailbox servers which is a member of the same Database Availability Group. This presents a single point of failure. In the event the server responsible for generating the OAB was to fail, this OAB generation process would not failover to another server as the OAB is hardcoded to use that specific mailbox server as the OAB generation server. This means until an administrator brings back the mailbox server which failed or moves the OAB generation process for the specific OAB to another mailbox server, the OAB in question will never get updated.
To fix this in development of Exchange 2013, Microsoft needed a method to allow any mailbox server to fail without disrupting the OAB generation process, after all this was the whole idea behind Database Availability Groups – the ability to allow mailbox servers to fail. Instead of spending development time on putting together a failover technology around OAB Generation, Microsoft decided to incorporate the OAB Generation process into Database Availability Groups. This means instead of having one mailbox server generate the OAB and share it out via SMB, the Exchange 2013 server hosting the active mailbox database containing the Organization Mailbox is now the server responsible for generating the OAB. In fact in Exchange 2013, the OAB is now stored in an Organisation Mailbox so in the event a mailbox server fails or a database failover occurs, the OAB will move along with it. This architecture change has removed the OAB generation single point of failure which caused problems for organisations in previous releases of the product.
Whilst Microsoft removed the single point of failure from the generation process of the OAB, they introduced a problem with the distribution process. In previous releases there was a service running on CAS servers known as the Exchange File Distribution Service, a process which downloaded a copy of the OABs from various mailbox servers performing the OAB Generation task and placed the OABs in a web folder available for clients to download. This allowed companies running multiple OABs to provide NTFS permissions on the OAB folders to restrict who is allowed to download the OAB. This is especially useful in Exchange multi-tenant environments to ensure each tenant is allowed to only download the address book applicable to their organisation.
In Exchange 2013 Client Access Servers the Exchange File Distribution Service has been removed and the Exchange 2013 CAS now proxies any OAB download requests to the Exchange 2013 mailbox server holding the active organisation mailbox containing the requested OAB. The Exchange 2013 CAS finds which mailbox server this is by sending a query to Active Manager. As the Exchange 2013 CAS no longer stores each OAB in a folder under the IIS OAB directory, companies can no longer set NTFS permissions on the folders to restrict who has permissions to download each respective OAB. It is also important to note that inside each organisation mailbox there is no means provided for organisations to lock down who can download each OAB through access control lists. This introduces privacy issues for companies who offer hosted Exchange services as it presents a privacy breach. Someone who knew what they were doing and has a mailbox within the Exchange environment could download OABs from other organisations and in result gather full list of employee contacts for data mining purposes. Microsoft’s response to this threat documented in the multi-tenant guidance for Exchange 2013 is for hosting companies to “monitor the OAB download traffic” – in other words there is no real solution to prevent this from happening.
For more information about the Exchange 2013 OAB distribution process I strongly recommend the following article published by the Exchange Product Team.
Clint Boessen is a Microsoft Exchange MVP located in Perth, Western Australia. Boessen has over 10 years of experience designing, implementing and maintaining Microsoft Exchange Server for a wide range of customers including small- to medium-sized businesses, government, and also enterprise and carrier-grade environments. Boessen works for Avantgarde Technologies Pty Ltd, an IT consulting company specializing in Microsoft technologies. He also maintains a personal blog which can be found at clintboessen.blogspot.com.