by Steve Galloway | Nov 25, 2014
In-Place Archiving eliminates the need for Outlook personal store (.pst) files and allows users to store historical messages in an archive mailbox accessible in Microsoft Outlook 2010 and later and Microsoft Office Outlook Web App.
In Microsoft Exchange Server 2013, In-Place Archiving provides users with an alternate storage location in which to store historical messaging data. An In-Place Archive is an additional mailbox (called an archive mailbox) enabled for a mailbox user. Outlook 2007 and later and Outlook Web App users have seamless access to their archive mailbox. Using either of these client applications, users can view an archive mailbox and move or copy messages between their primary mailbox and the archive. In-Place Archiving presents a consistent view of messaging data to users and eliminates the user overhead required to manage .pst files.
You can provision a user’s archive on the same mailbox database as the user’s primary mailbox, another mailbox database on the same Mailbox server, or a mailbox database on another Mailbox server in the same Active Directory site. This provides flexibility to use tiered storage architecture and to store archive mailboxes on a different storage subsystem, such as near-line storage. In cross-premises Exchange 2010 and later deployments, you can also provision a cloud-based archive for mailboxes located on your on-premises Mailbox servers.
by Steve Galloway | Oct 19, 2014
Office 365 and similar technologies provide a workaround to render the barbed issue of backups increasingly obsolete. In its place, high availability is the one overiding reason for businesses to relocate their email and data stores to solutions like Office 365.
The difficulty with backups is that really, the concept is fundamentally flawed. It is just that, until now, there has not been an alternative. Nor is this an end user problem; even network engineers struggle. For example:
1. it is not in people’s genes to run backups reliably,
2. data stores are so large in today’s knowledge economy that it is impractical to execute time consuming backups,
3. backups are out of date as soon as they are completed because new data already needs appending,
4. we never know if backups will work,
5. if we adopt the conventional guidance to test backups, it means destroying a good data store to test an unknown quantity,
6. even if users escape the first five traps, since it takes so long to record complete backups, it follows that it takes at least as long to restore them. So, in the event of disaster recovery, an organisation could potentially waste weeks and possibly months restoring terrabytes of data. Even network administrators would have nothing to do but watch the wheels on the tapes go round and round.
A few years ago, large organisations started approaching this problem from another angle. The thinking was that backups themselves were not as important as the availability of data to enable people to access information. Rather than “point-in-time” backups, engineers replicated or synchronised data stores in real time to other hardware, so that in the event of server or data failure, users could default to replicated services which ran in real time. This approach was labelled “high availability”. The approach gained traction as a model within organisational networks, and because the principle scales easily, it is an underlying reason for the success of today’s “cloud” services. Email is a critical application that depends on high availability services. Here is an illustration of how network administrators span “Database Availability Groups” in Microsoft Exchange to replicate email databases across multiple servers and multiple locations so that there is no single point of failure:
So what does this actually mean? In today’s terms, whereas a single point of failure like a server crash was once catastrophic, a server failure today usually means someone – usually an intern covering for his boss who has a more critical date with a sand wedge – will get around to a “dud” server within a few days while the network’s servers takes up the slack. So sophisticated are today’s high availability services that servers diagnose their peer appliances and invoke automated action to ringfence corrupted devices.
This is good news for small business, which has neither the desire to hire the required expertise to do this in-house, or the money to invest in hardware to do this in the first place.
Instead, businesses are turning to solutions like Microsoft’s Office 365, whose gigantic scales of economy are equalled only by the sheer size of its multi-billion dollar investment that provides data availability not in the order of two concurrent databases for users, but ten.
How does Microsoft do this? Office 365’s solution is built around a globally distributed core of data centres. By “data centre”, Microsoft means a facility of at least a hundred thousand servers. At this level, between then and a hundred such facilities are online at any given time. Underneath these kingpins sits a hierarchy of edge nodes and metro solutions which gradually disseminate data towards regions that users are localised in. Importantly, data transits Microsoft’s own fibre network until the last mile, which greatly improves prompt and clean delivery. This diagram shows how Microsoft’s topography works (click on the image to enlarge):
Office 365’s network stands apart from Microsoft’s own network, and the American, European, and Asian regions are interconnected.
So, where does a user’s data reside and is there a risk of data bottlenecks?
Data does not look like you would imagine it to be by the time it reaches a data centre, so the point is not so important as you might think. The biggest consideration – where users are geographically based – does not have so much to do with the hops required for data to reach devices, rather the considerations like data protection laws and practices that differ from region to region. Office 365’s provisions services like retention policies and data leakage to help local network administrators provision email and data management for end users compliantly.
So data is primarily situated within a user’s region for a variety of reasons and to improve availability, tools are provided to minimise information flow between users and data centres. For instance. when working on a Word document, the entire file is not written to storage every time a user clicks “save”: only changes are synchronised. Once data starts compiling, it is replicated to a mirror within the primary data centre, where point-in-time backups are kept in any event, and techniques are deployed to populate data between geographically remote locations. In this scenario, deleting documents by mistake is harder for end users to do because at least nine copies remain in place, and even when those disappear, there is still a point-in-time backup to recover from. This diagram illustrates the scheme (click on the image to enlarge):
Office 365’s Exchange email services operate a little differently, but again with high availability in mind for such a critical application. It is worth mentioning that although Office 365 for Small and Medium Business still vexes users with building their own email archiving, Office 365 Enterprise solutions include “inline” archiving which enables users to completely remove archiving from their desktop versions of Outlook. I will cover the implications of that in another article.
The biggest worry for business users is the thought of surrendering data to a third party. Yet, law practitioners and accountants whose authorising bodies require high standards of efficacy already use Office 365 because in terms of document discovery, data retention, and other factors, it is difficult to match Office 365’s services. Indeed, Office 365’s Exchange mail services are the only commercial solution at time of writing that satisfies Federal and EU requirements for departmental deployment “off the shelf”.
For more information about Office 365, Office 365 network administrator help, and trial subscriptions, please contact Steve Galloway on 07834 461 266 or Fred Dreiling on 07919 340 570.
by Steve Galloway | Aug 18, 2014
With effect from August 18th, ComStat is providing 100GB inline email archiving. Inline archiving is provided in addition to the 50GB limits established for individual user accounts.
Inline archiving is a technique that relocates arhived email from on-premises equipment to users’ allocated services at the data centre.
Typically, small business users archive email using Microsoft Outlook to a segragated data file that sits apart from their Outlook inbox, sent Items, and other current folders. Archiving helps to improve system runtime. However, archived emails continue to reside on users’ individual workstations, and archives can only be accessed from the workstation that the arhive is situated on. This leaves the risk of data loss in the event of hard drive failure or machine failure. Unless the archive itself has been backed up using .pst, the archive remains vulnerable.
In our experience, users are not comfortable with Outlook’s backup functions and email backup, whether by copying current folders or using archives, is generally not organised. Typically, users’ email records are usually about as historic as the lifetime of their machine.
ComStat’s email services for premium business users provides 50GB mail storage per user. There is a case to argue that archiving is not necessary at this level. However, users who connect to email services with mobile devices via telco connections may have trouble managing large volumes of email on mobiles, particularly where bandwidth is limited, where data transfer volumes may be an issue, and where smartphones are physically limited to lower capacities (8GB, 16GB, etc).
Inline archiving helps to reduce inbox sizes, while relocating historic archives to the managed data centre also means users can access their archive via a variety of devices.
Inline archiving is available to premium business users by default. Other users considering this service should talk through options with ComStat. Existing users who want to upgrade to this service would need a manual rebuild of their environment, so it is important to plan needs in advance of execution of service.