The worst possible time to define your uptime and availability requirements for an Exchange environment is when that environment is unavailable.  No email administrator wants to hear “We need this working within 2 hours” when they are looking at a dead server that is going to take all night to recover.

Uptime and availability should be defined within an SLA, or Service Level Agreement.  An Exchange Server SLA should exist in all organizations, even those that provide their own internal IT services.  The SLA is between the IT supplier or IT department and the rest of the business, and clearly defines what is an acceptable downtime or outage of the Exchange environment.

Why Are SLAs So Important?

The existence of an SLA supports many facets of the design and operation of the Exchange Server environment.

Budget – When a business defines their service level requirements they are making a commitment to providing the funds necessary to deliver those service levels.  An SLA is one of the best pieces of leverage the IT department has to secure those funds and implement an appropriate Exchange system.  Without the backing of an SLA the IT department may struggle to get approval for Enterprise server licensing, multiple servers for clustering, and other high availability components.

Server and Network Design – Exchange Server environments are designed to meet defined SLAs.  Certain uptime expectations can only be met with the right server design.  A business that is willing to go a day without email would not need the same infrastructure deployed as a bank that can’t go more than 15 minutes without email.  Clustering, redundancy, site-to-site failover, are all design points that would be included or excluded based on the SLA. Continue reading Exchange Server SLAs, and Why You Need One

Ten years ago we measured mailbox sizes in megabytes.  A 20mb mailbox was adequate.  A 100mb mailbox was a luxury.

Today we measure mailbox sizes in gigabytes.  A single message in today’s email communications could easily consume the entire mailbox quota of a decade ago.  We’re sending more email, bigger email, and keeping it longer.

Email server products such as Microsoft Exchange Server have responded to this growth in storage needs with support for more processing power, more efficient database schemas, and improved performance on storage hardware.

In fact, most of the storage performance gains of the last 4 years have been in the efficiency of the Exchange Server product itself, not in the performance capabilities of storage hardware.  Hard disks are getting bigger, but they aren’t getting faster.

As we become more reliant in the ability to retain and access email data quickly it is no surprise that we are storing more and more of it in our mailboxes.  This increase in email storage reveals some new bottlenecks in IT systems – the ability to adequately back the data up.

Backup Challenges

Backups are experiencing similar growing pains to disk storage.  Tape speeds and capacities increase through new generations of the technologies, but when disk speeds and network speeds don’t increase with them there is only so much throughput that you can achieve.  Eventually many larger enterprises reach a stage in which a nightly, full backup of the Exchange system is not possible within the backup window.

Three key technologies have surfaced to help enterprises manage these growth issues with email storage:

• Archiving
• Synthetic Backups
• De-Duplication

Archiving

Email archiving usually involves moving older, less frequently accessed data from the primary storage to a secondary storage system.  The secondary storage system may be built in to the email server, such as Exchange Server 2010’s archiving feature, or it might come in the form of a third party product that integrates with Exchange. Continue reading 3 Technologies for Improving Backup Efficiency for Growing Exchange Environments

Backups are one of those things in IT that most people know are very important, but not everyone treats them that way.

More times than I care to remember I have entered a disaster recovery situation for an email system in which the recovery options are limited because either:

• The backups hadn’t been running and no one realised
• The backups hadn’t been running and people knew but didn’t do anything about it
• The backups had been running but had never been tested

I can tell you that the worst possible time to put your backups to the test is during a real disaster situation.

Take a look at your current email backups and ask yourself these questions.

Are the Backups Running?

Even if you know that the backups have been set up and scheduled you still need to know whether they are actually running.  It is not a nice feeling when you open up the backup history of a server and see that every backup job has actually failed.

Good backup software includes alerting options for the outcome of a job.  Set these options to send email reports to the people responsible for checking the backups.  It is also advisable to have a weekly or monthly summary report sent to other people such as managers so that they can verify that the backups are being done.

Are the Backups Successful?

Not only do you need to know whether the jobs are running, you also need to know what the outcome of the backup job was.  Obviously the goal is a successful backup job, but in the real world backups will fail from time to time.

Have a response and escalation process in place for any failed backup jobs so that they are investigated immediately that day.  If the problem can’t be resolved, or a consecutive day’s backup also fails, escalate the problem to a senior administrator or seek vendor support.  Some environments can tolerate a single failed backup but the risks grow exponentially with every subsequent failure.

Are the Backups Protecting the Data You Think They Are?

It might not occur to everyone to check not only the successful outcome of the backup job, but also verify that the job is backing up everything you intend it to.  No backup software will report that it failed to backup something it isn’t configured to backup in the first place. Continue reading Are You Sure Your Backups Are Working?

The end of the year is upon us, and for most of us this means time off from work to celebrate Christmas with our families and take a much needed break.  But before we shut down our computer and head out the door there are a few extra things that email admins need to think about.

Patches and Security Updates

Before taking an extended break is a good time to double check that your email servers are up to date with the latest security updates.

This includes updates for the server operating system, the email server application, and any other components on the servers such as backup agents, faxing software, and antivirus agents.

Even if your patching is automated it might pay to manually apply the latest updates now so that any problems that arise can be dealt with while you are still at the office.  You don’t want to get a phone call while you’re relaxing because the server was knocked offline by an automated update.

Backups

A lot of businesses use the end of the year to take a full backup of systems to store as a long term archive.  This is best performed while you are still available to assist with any issues and make sure that the backup is 100% successful and can be relied upon later for recovery if necessary.

At the same time some businesses halt their backups over the holidays if no staff will be present to change backup tapes.  For Exchange servers it is important to ensure that enough transaction log space is available for the server to run without backups for a week or more.

Support Calls

Nothing is worse than getting phone calls on your holiday for simple questions or problems.  If the business is still operating over the Christmas period and you might get phone calls from the Help Desk or on call staff then you can save yourself from being bothered by putting the right documentation and systems in place. Continue reading Christmas Checklist for Email Admins

As companies and organizations grow in size, departments internally supporting the business grow as well. IT of course is one that must scale to accommodate business needs. If your department is small, it’s very likely that you know how all the components in your IT infrastructure are configured, what they are, what they do, and so forth. You know not only which servers host what resources, but know about the configuration of users in Active Directory, you may be responsible for provisioning those users, and for setting them up with VPN access, server access, and other actions unrelated to configuring the user in Exchange or giving them a mailbox as well as a login. You may be thinking, “Of course, Clemmer, but doesn’t everyone know about all the elements in a network and how the interrelate with email?”

Well, in larger organizations both operational responsibilities and security policies make the separation of duties for IT staff a reality. What does this mean? Well, the person who manages the firewalls and configures rules to allow email traffic between company sites or business units is very likely not the same email admin who is going to configure the SMTP connector or inter-site replication. The staff member that gets information from human resources and provisions accounts is likely not the same staff member that builds out hardware for servers, or configures desktops or notebooks for the new users. The security staff that manage proxies, load balancers, network anti-virus solutions and other security solutions are not the ones that will perform tuning and regular maintenance to your email servers, in most all cases. If you have backup and storage managed by a separate group in the IT staff, they may or may not know the specifics of backing up an Exchange database or server.

Continue reading Is Separation of Duties in IT a Help or a Hindrance?

In Part 1 of this series I explored the backup requirements for each of the Exchange Server 2007 server roles.  In Part 2 I demonstrated Mailbox server database backup and recovery, and then in Part 3 I demonstrated the backup and recovery process for Hub Transport and Edge Transport servers.  In this part 4 of the series I will discuss the backup and restore process for Client Access servers.

The Client Access Server Role

Client Access servers perform a similar role to that of “front end” servers in previous versions of Exchange.  The Client Access server is responsible for all non-MAPI connectivity to Exchange server data.  In other words, anything that is not a Microsoft Office Outlook connection to a mailbox or public folder is handled by the Client Access server.  This includes Outlook Web Access, ActiveSync, and Exchange Web Services.

The nature of this role is such that it relies on Microsoft IIS to make these services available.  Because of this the Client Access server is one of the more complex when it comes to backup and recovery.
Continue reading Exchange Server 2007 Backup and Recovery Part 4 – Client Access Servers

One of the least exciting yet most important parts of an Exchange administrator’s job is making sure that the Exchange Server environment is properly backed up.  Throughout my career I’ve spent many long nights with customers who have suffered a failure of an Exchange server and discovered that their backups are unreliable or even non-existent.  In this series I will discuss Exchange Server 2007 backup and recovery and demonstrate some actual disaster recovery scenarios that I have encountered on the job.

What to Back Up on Exchange Server 2007

To understand what to back up in an Exchange Server 2007 environment you must first consider the server roles that you have deployed.  In the most basic Exchange Server 2007 deployment the Client Access, Hub Transport, and Mailbox server roles are installed.  In more complex environments more than one of each of those roles might be deployed, the Mailbox server might also be clustered for high availability, and other roles such as Edge Transport and Unified Messaging might also be in use.

In addition to the Exchange server roles there are also considerations such as the Active Directory (a pre-requisite of any Exchange environment), client data such as PST files or POP3 mailboxes, and any server-based anti-spam system that is deployed.

All Exchange Servers

Generally speaking all Exchange servers in an organisation should have their local file systems and System State data backed up.  However because Exchange Server 2007 stores much of its configuration in Active Directory you can recover some server roles without needing to have backed up any data at all.

Continue reading Exchange Server 2007 Backup and Recovery Part 1 – What Needs to be Backed Up?

In-the-cloud storage got a setback last week when both HP’s and Yahoo’s online storage services were shut down for good. HP’s Upline has had a rocky past, with the young service having experienced numerous problems and delays, and reports of malfunction and inappropriate access. Of course, there is no shortage of other cloud vendors taking their place–and the ads are full of “Do you need an alternative to Upline” come-ons.

We’re still hearing rumors, and most recently, “confirmed rumors”, that Google’s Gdrive is ready to roll. Gdrive sounds revolutionary in design. It wil supposedly offer unlimited storage–allowing you to actually store the entire contents of your hard drive in the cloud. Local and online files are synchronized through a web interface so for example, you could start working on a project at the office, and then later on pick it up at an Internet cafe–or even on your smartphone. Gdrive will also be integrated with other Google applications and services. The security ramifications are immense though, and there’s as of yet no word as to how security would be provided. I’m not so sure I would want my entire hard drive replicated in the cloud. Also, it would seem doubtful that users who have to comply with various regulations regarding storage and backup would be able to take advantage of it, but we’ll wait to see on that one.

Before moving to an online backup environment, it would be important for a corporate user to review their data retention policy and any compliance requirements they face, and make a judgment as to whether in-the-cloud backup could adequately meet those policies and requirements.

Recently I had an opportunity to meet with an associate and email administrator in New York City named Lisa Bruno.  She and her team are involved in a Lotus Notes-to-Microsoft Exchange migration.  Lisa shared some interesting insights.  Having recently migrated to Exchange 2007, one of the many questions we find is ‘what to use for backup?’.  Within Exchange you can set a “Local Continuous Replication”.   It takes an exact replica of the storage group.  Now the question is, since Local Continuous Replication is set do we need third party backup software?   In response to that question, we determined that yes we still need a backup solution.  By no means should LCR be considered as the only form of backup.  LCR also compliments any implemented archiving solutions by adding an extra utility for maintaining data integrity. Data integrity is crucial to just that one instance when archived data must be retrieved due to a legal inquiry. While it does give that option and helps in recovering quickly, it should not be the end of all.

Continue reading Microsoft Exchange LCR Compliments Archiving