When looking at solutions on securing email, many people don’t take into consideration the type of business environment they work in. All too often, after spending a great amount of time and money, small to medium-sized enterprises find out that what works for a company the size of Bank of America doesn’t quite work for them.

To better help SMBs find solutions scaled to their needs when it comes to email security, I have compiled a list of 5 tips that address the risks and restraints that they face.

1. Get the right solution

Email security can come in any number of packages. Security solutions can be software based, deployed through an appliance or even in a hosted environment. Each type has a variety of advantages, but there may be some disadvantages based on your company size or industry so it is important that you weigh your options carefully.

It is also important to look to solutions that can provide the protection your company needs at a cost that works. Too many times people are under the impression that security appliances are seriously out of reach for most small to medium sized businesses. This isn’t the case. There are many solutions that organizations find affordable and feature rich.

Make content filtering a standard practice

Content filtering needs to be a two way street. Of course, you want to filter out inappropriate content from being received by employees and certain types of attachments need to be blocked to prevent the spread of malware and expose vulnerabilities. However how often do you consider filtering what leaves your business via email?

Many industries nowadays are highly regulated and sending sensitive, or even financial, information out through email can not only bring compliance issues to your business, but it may also give competitors an edge. Filtering what users send out can be just as important as filtering what they receive when it comes to securing your company’s email.

Practice recovery as well as backup and archiving

Do you brush just half of your teeth? Then why would you only test half of your backup and recovery solution? Many companies find out, only when it is too late, that their backup and recovery solution was not configured properly or that there is some sort of problem.

This can be alleviated by regularly testing the recovery portion of your backup. By simply setting up a server (or virtual server) on which you can replicate your email system you can frequently test the validity of your backups in a way that will not disrupt your current email process.

Create fair policies that management will enforce

One of the biggest mistakes that SMBs make when it comes to email security is to take an overly aggressive approach. Without the manpower and resources to fine tune security policies, it becomes easier to just restrict anything that could be a perceived threat. This becomes especially true in small IT departments because they are tasked with so many other responsibilities.

When creating policies, it is important to bring other departments to the table so that these policies do not restrict anyone from getting their work done efficiently and effectively. Involving others at the management level also helps them better understand the reasons behind email policies and the ramifications for not following them. Gaining this support will help when it comes time to enforce these policies and discipline those who violate them.

Educate your staff

When it comes to security, it is a common misconception that bigger, state of the art, expensive solutions provide the best protection. Even though this isn’t true, SMBs often feel that they are at a disadvantage when it comes to email security because they cannot afford to deploy such solutions.

What many SMBs don’t see is that they have a distinct advantage over their larger counterparts when it comes to educating end users. When you have a smaller number of employees to train you have the advantage of being able to spend more time with them to make sure they understand the material you are delivering. You also have the opportunity to be readily available to answer questions or address any concerns or issues that your users may have.

Developing a solid training series for email security can also help free up time for IT departments that find themselves tasked with too many responsibilities because users who are informed and educated require less oversight and less attention.

5 Essential Tips for SMB Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In just one week Google, the International Monetary Fund and Citigroup have all made headlines as a result of email associated with them being under attack. The reason we continue to see companies make the news as a result of email attacks is that email security is sometimes ignored when it comes to training users properly and making good decisions. In some cases, having the latest and greatest when it comes to security tools even creates a false sense of security that causes us, and our users, to overlook the little things. A multi-layered defense that has been properly configured with all the best technology can be rendered useless if the little things are forgotten.

This list displays some of the most common mistakes that are made when it comes to email security and a brief description of what you can do to prevent them.

Leaky emails

There are many times when sensitive information is passed along via email. If everything is encrypted properly you, and your users, often assume that it will only be seen by the appropriate people. Unfortunately this isn’t always the case. Too many times a recipient may answer an email with sensitive information and hit the reply all button without checking to see who will be receiving the email.

The fix: Put a policy in place that addresses sensitive emails and reply to emails. However a policy alone isn’t enough. Make users aware of the policy through training and keep a record that all users were trained/informed of the policy and repercussions of not adhering to it.

Trusting others

When we receive emails from family, friends and business colleagues we often blindly open them without much concern. Especially if they are contacts we communicate with on a regular basis. However malware can easily be spread through emails by attachment or embedded code and links.

The fix: HTML in emails should be blocked if this is a concern, as should the ability for your users to receive attachments that are scripts or executable files.

Passwords that are easy to guess

Remember when Sarah Palin’s personal email account was breached? It was because her password was easy to guess using information the attacker found on her Wikipedia page. Companies often list information on corporate sites that provide attackers enough information to guess passwords as well.

The fix: Enforce strong passwords or password phrases for all users. Also, make sure that people don’t give up information that may be used to guess their passwords when providing bios.

Ignoring malware protection on the desktop

While scanning all emails for malware needs to be done, the desktop should not be ignored. And all too often it is. Malware definitions are outdated, software is not configured to run properly or protection is completely left to the user.

Even if you have a policy that enforces strong passwords, a keystroke logger can easily give up even the most complex password combination.

The fix: Email administrators should work closely with IT security to make sure that the desktop and network security isn’t lax so passwords are tougher to expose.

Failing to check on backups

Some companies and industries are required, by law, to back up and archive emails for a set period of time. Others are not required to do so. Regardless of the laws, every person and company should be in the practice of backing up emails. Emails often provide important records and information that could be lost.

But what happens if you need to restore your emails and find that something went wrong? Maybe the backup was incorrectly configured or the backup location was insecure. In any event, the inability to restore emails from a backup can render the entire solution useless.

The fix: Frequently test the ability of your backup solution, and staff, to restore emails.

These five tips may seem basic and simple. But that is the point. Working in IT we often gravitate towards the more complex issues and ignore simple techniques and solutions until it is too late. By taking the time to do the little things when it comes to security, we build an even stronger foundation for all the bells, whistles and technologies that really impress us and our bosses.

5 Simple Mistakes When it Comes to Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

Third Party Warranty – In very resilient environments, such as those with clustered servers, this is less of an issue.  But for an environment with SLAs for single points of failure, the right warranty response times need to be in place for SLAs to be met.  A 4 hour return to service target will not always work if it is paired with a 4 hour vendor response time, because the vendor meets their target simply by showing up on site within 4 hours.  After they then spend time fixing or replacing failed components, the IT team then has to potentially deal with other software and data recovery processes.

Backups – The backup system will be heavily influenced by the SLAs that are in place.  If the backup system cannot restore all of the required data within the SLA timeframe then of course the SLA cannot be guaranteed.

Staffing – The SLA will define the service levels for different times of day, and this will impact staffing levels.  If 8×5 support is all that is required, then that is a different staff level and rostering schedule than 24×7 support would be.

It all starts with the SLA.  Sometimes an organization has trouble defining their requirements before an actual outage occurs.  For those without any SLA at the moment my suggestions would be:

1. Analyze your current infrastructure and make an estimate as to how long a recovery would take under a variety of failure scenarios (e.g. single mailbox, single database, single server)
2. Identify the business processes that email supports and is involved in
3. Survey a sample of staff from various departments and teams, ensuring that each tier of employee is well represented in the survey

From that exercise you will gain an understanding of your business needs, technical capabilities, and the gaps that exist between them, and you can then begin work to formalise them as SLAs and implement changes in the environment to close those gaps.

Exchange Server SLAs, and Why You Need One

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

The benefit of archiving in reducing backup load is that once the data is stored in the archive it can be subject to different backup schedules than primary email storage.  While daily full backups of the primary storage might be a requirement, the archive stores may only require weekly or even monthly backups depending on the archive policies in place.

Meanwhile, good email archive systems still provide fast access to archived email items when required by end users.

Synthetic Backups

A synthetic backup combines the efficiency of an incremental backup (in which only data that has changed since the last backup is backed up) with the restorability of a full backup, by combining data from the incremental backup with existing data in the backup system from earlier backups to form a new, full backup.

In other words, if a file is already stored in the backup system and hasn’t changed, the backup system doesn’t need to copy it from the server again, it simply uses its existing local copy to “stitch together” a complete backup of the server.  Because not all data on a server is likely to change every day, the backup takes far less time than a full backup would, but achieves the same end result.

These synthetic backups can then be duplicated on to removable storage such as tape media to send offsite for longer term storage.

De-Duplication

Data de-duplication for backups means that multiple copies of the same data are not required to be backed up individually.  This is particularly effective in email systems, for example when 100 people all received the same email attachment only one copy of that email attachment needs to be backed up.

This reduces the amount of backup storage needed, but also the amount of backup traffic generated.  When the de-duplication occurs at the backup client itself there is less data required to be transmitted to the backup server, reducing overall backup times, yet still achieving a full backup.

Thanks to these three technologies of archiving, synthetic backups, and de-duplication the growing email storage needs of enterprises can be delivered while still achieving a reliable and effective backup regime.

3 Technologies for Improving Backup Efficiency for Growing Exchange Environments

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.This sort of problem easily arises in environments with poor change control.  When a new server is introduced, or a significant change is made to a server, it is easy to forget to reconfigure the backups to include the new data locations that have been created.

Have a change control process in place that includes a mandatory step to notify the backup administrators of any environment changes so that they can adjust the relevant backup jobs accordingly.

Can You Restore the Data When You Need To?

One of the toughest situations you can face is an environment where all of the backups have been running successfully and backing up the right data, but you can’t actually restore it.

I’ve spent a lot of hours testing tape after tape in multiple different tape drives for a client to try and find one that can be used for a recovery.  This can happen to any organization due to faulty backup media, poor storage methods, or even lack of speedy access to offsite archives.

Test your recovery plans at regular intervals to verify that you can meet the required timeframes for restoration, and that your backups are still usable.  It pays to take an extra step of testing important, long term archives such as yearly backups before sending them offsite, to be absolutely sure that you aren’t sending a useless backup off to storage.

Give Backups the Priority They Deserve

Ask yourself those four questions above and if you find you cannot answer yes to all of them then it is time to give your backups the attention and priority that they deserve and address the problems now before they become a real disaster.

Are You Sure Your Backups Are Working?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

Make sure your fellow IT staff know how to troubleshoot email problems and have the minimum level of access they will need to deal with routine support issues.

You can also avoid simple support requests such as spam quarantine releases by putting in systems that support end user self-service for those functions.

Passwords

Most networks have a password policy that forces a new password to be chosen every 30 or so days.  Depending on the remote access infrastructure in place it is not always possible to update an expired password via remote access.

I’ve been caught out by this before and had to drive into work on holidays to fix an issue that would have taken me 5 minutes over remote access, all because my password had expired.

Take a moment before you go away on holidays to update the passwords on any accounts that you need so that they won’t expire again for another 30 days.

Lock the Door Behind You

Ever created an account with a weak password just for a “quick test” and then forgotten to delete the account afterwards?  Spend some time checking your email servers and accounts for any test accounts or other administration oversights that might lead to a security breach while you are away.

Remember that hacking activity increases over holiday periods both because the hackers are bored and because they know a lot of networks are unmanned during these times.

Double check your firewalls and other access points to make sure they are still locked down the way you intended.

This can all mean the difference between returning from holidays to a healthy network or starting off the new year with a disaster on your hands.

Christmas Checklist for Email Admins

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

What will all the results of this separation of duties be? Will things work better or more poorly? Are you already in this sort of situation and frustrated that nothing seems to get done and that things take many times longer than they used to or seem that they should?

If you are a growing organization and thinking of separating duties and responsibilities because of workload, security, expertise, or all three, consider carefully what the impact will be. When one group does not know what another is doing, when, or why, it can make otherwise simple changes into boondoggles. Scheduling with clear communication between groups of planned outage times, priorities, and potential risks of course are important. Clear communication sounds easy, but when everyone is busy with their own work sometimes we forget that not everyone knows what we are doing and that everyone else may not have read every single email before they left work for the weekend, especially if the email was about another group’s project. When things do go wrong and problems erupt, affecting systems unexpectedly, is there a well-understood escalation process and means of contacting the staff needed to troubleshoot and resolve things? Monitoring systems and automatic email or text alerts are great as long as those systems can function properly and they have a connection outbound to the Internet and from there to you when the crisis happens.

Recently we discovered at one location that backups for some systems had not been running for a long time. No alerts or warning about that, because the backups weren’t configured in the first place. A few days later we discovered that some of the systems were not being monitored for performance at all, although there was monitoring software available and a plan was in place, it just wasn’t happening. These things went unnoticed by the staff directly administering and supporting those systems, because they did not have administrative or even read-only access to the backup technology or the monitoring solution. The staff did not have the means to even look and see if these important functions were active and operating as assumed. The problems have been corrected, and going forward, the staff has been granted access to check that the backups and monitoring are operating. This is an example of where separation of duties was problematic. The lessons learned were that we can’t assume that others know what we want, and that we should verify things. Just trusting someone in another area’s word that something is true isn’t enough–”show me” works better.

Organizations can be and will be so large that any one IT staffer simply can’t know everything about everything. The field is becoming complex enough that this is no longer possible. For large organizations, it’s not possible to have the same group manage every IT service. Since this is the reality, we are left with the task of ensuring that the different IT roles can and do work best together. As an email admin you may discover that you know more and more about less and less of the whole IT infrastructure. Just don’t take it to the point where you know everything about nothing!

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

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

Backing up the Client Access Server

The data that needs protecting by backup for the Client Access server is located in several places:

• Exchange server configuration stored in Active Directory
• Configuration files stored in the file system (C:\Program Files\Microsoft\Exchange\ClientAccess)
• IIS customizations stored in the IIS metabase

Similar to the Hub Transport server the Exchange server configuration can be recovered from Active Directory using the setup /m:RecoverServer command.  Assuming the Active Directory is already backed up by your Domain Controller backup strategy the Client Access server backups only need to take into account the configuration files in the file system and the IIS metabase.

However there is a downside to this.  When setup /m:RecoverServer is used to restore a Client Access server, and then the IIS metabase is restored afterwards, the Client Access server will experience errors.  Because of this, Microsoft recommends keeping a manual change log of all customizations made to the Client Access server, such as changes to the default virtual directories, or any new virtual directories created.

A workaround for this is to perform a full backup of the file system and System State for Client Access servers.  This allows you to restore the entire server without causing problems after the IIS metabase is recovered.

Recovering the Client Access Server

Since there are two approaches to backing up the Client Access server role there are also two approaches to recovery.

The first is to use setup /m:RecoverServer to reinstall Exchange on the replacement server.  Then, restore the C:\Program Files\Microsoft\Exchange\ClientAccess files from the most recent backup.  Finally, manually apply all customizations that have been recorded in a change log.

The above method will work provided your change log is up to date and accurate.  Any discrepancies will potentially lead the recovery effort astray.  This method is also quite tedious and error prone in complex environments.

The second approach is to use a complete server backup for the restore.  In this scenario the new server is installed with the operating system only.  There is no need to join it to the domain or even to give it a static IP address provided a DHCP server is available.  Next, restore the last full server backup onto the server.  It is likely that the server will then require a restart.

This second approach is less effort and will tend to be more accurate but requires that more data be backed up each night than for the first method.

Recovering Individual Email Items

In Part 2 of this series I demonstrated the recovery of an entire mailbox database.  In some situations it may be necessary to recover just a single email item from a backed up mailbox.  In the next part of this series I will demonstrate how to restore single mailbox items.

Exchange Server 2007 Backup and Recovery Part 4 – Client Access Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

For example, if a Hub Transport server crashes and is unrecoverable the Exchange administrators can build a new server of the same name, and then install Exchange Server 2007 on it with the /m:recoverserver setup parameter.  This tells the installation to use the configuration stored in Active Directory for the server being rebuilt.

Despite this feature there are still several items to be aware of for Exchange Server 2007 backups.

Mailbox Servers

The most obvious role that an organisation will backup is the Mailbox server role.  As the name suggests this role hosts all of the mailbox databases and public folder databases.  Because of the database format in use, backups must be performed using an Exchange-aware backup product.  These products can use one of two different methods to backup the database.

Streaming Backup – this backup “streams” data directly from the live database page by page.  The built-in Backup utility for Windows Server 2003 performs this type of backup of Exchange.  Remote streaming backups are disabled by default in Exchange Server 2007 Service Pack 1 but can be re-enabled with a registry change.

Shadow Backup – a VSS shadow copy (or snapshot) of the database is made so that a “point in time” backup can be performed.  Most third party backup products perform this type of Exchange backup.

For Mailbox servers with database replication enabled (either Local Continuous Replication, or Cluster Continuous Replication) an Exchange-aware backup product can usually perform its backups using the “passive” copy of each database.  This is an advantage in many environments because the entire backup I/O load is kept off the active database, preventing any performance impact on end users.  This makes it possible to perform backups during business hours, which is important to some organisations.

Hub Transport Servers

Although most of the Hub Transport configuration is stored in Active Directory the local file system still contains important data such as the message queues, log files, and some configuration files that are often modified by administrators for performance tuning.

By including the C:\Program Files\Microsoft\Exchange Server\TransportRoles folder (and all sub-folders) in the backups you provide some protection from failure, however the queues and logs change on a minute by minute basis so unless you run multiple backups through the day the recovery benefits are minor.  Additionally, these files are often locked and in use at all times so the backup must be performed by a product that can handle locked files correctly.

Client Access Servers

Most of the important configuration information for Client Access servers is not stored in Active Directory, but rather is located on the local file system of the server and also the IIS metabase.  The IIS metabase in particular contains vital information such as customised settings on the Exchange virtual directories.

To backup these important items you should include the C:\Program Files\Microsoft\Exchange\ClientAccess folder and the System State of the server in your backups.

Edge Transport Servers

Edge Transport servers are not members of any Active Directory domain, so cannot be restored using /m:recoverserver.  Instead their configuration must be exported using the ExportEdgeConfig.ps1 PowerShell script, and the export file then backed up elsewhere.

In addition, the message queues and log files should be backed up in the same manner as with Hub Transport servers.

Unified Messaging Servers

Most of the configuration for Unified Messaging servers is stored in Active Directory, but as with other server roles some customisations are only stored on the local file system of the server.  The C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging folder should be included in backups.

Active Directory

Exchange Server 2007 relies on Active Directory and uses it to store most of its server configuration information.  The Active Directory database is backed up by including the System State of one or more Domain Controllers in backups.

Client Data

Although organisations are moving away from the use of PST files for email storage some still persist in using them.  PST files can be difficult to back up because the Outlook client will lock them “in use” and prevent some backup software from successfully backing them up.  Furthermore, if the PST file is stored on an end user machine it probably will not be included in server backups.

I have seen this dealt with in several ways, such as storing PST files on a file server share and using backup software that can handle locked files.  In many organisations though they simply consider PST files as being excluded from backups and accept any data loss that may occur from them.

POP3 clients are fairly rare in Exchange Server 2007 environments but the simplest approach with these is to configure the POP3 client to leave copies of mail items on the server so that the Mailbox Server backups can protect them.

Other Messaging Systems

To ensure that the entire messaging environment is backed up you should also consider any other non-Exchange servers that are involved, such as an anti-spam server.  In most cases this will mean backing up the file system of the anti-spam server, as well as any SQL databases it uses for storing quarantined items and reporting data.

How to Backup and Restore a Mailbox Server

In the next part of this series I will walk through the process of backing up a Mailbox server, simulating a failure, and then performing a recovery of the server and its databases.

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

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

How compliant is in-the-cloud storage?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

Now the “LCR” is more of another option if a disaster occurs.  As a small business this gives us a quick reliable way of recovery.   Should a database get corrupted it automatically gives you an option to switch to the LCR copy.  To be exact in terms, it switches to a Passive copy of the database.  This minimizes the downtime.  Now how does this happen?  It all takes place by creating a log file.  This log file is called a Transactional Log.  Each time a change is made on the database it writes to the log instead of directly to the database.  This is how it determines how to quickly recover the database.  As part of enabling the Local Continuous Replication from the Exchange Management Console under the Server Configuration Node under Mailbox.  That is part of another documentation.  To recover from a corrupted database you have the option to run Restore-StorageGroupCopy CMDlet.  This will replace the LCR copy (passive copy) to become the active copy.    The exact command is Restore-StorageGroupCopy -Identity “First Storage Group” -ReplaceLocations:$true

Once the passive copy becomes the active one, LCR is disabled.  You have to enable Local Continuous Replication for that storage group.  By using this method the path of the group also changes.   Microsoft does not recommend this method but instead recommends the Restore-StorageGroupCopy CMDlet without the ReplaceLocations parameter.  This is similar to the other method but it does not change the path of the storage group.  It gives you more control to replace the database to its current path or set another path.  For either method used you will probably need to restart the server.

You can suspend and resume the Local Continuous Replication at any time.  To do so you can do it via the Exchange Management Console.  Reasoning for suspending the LCR could be for any specific reason.  But one in particular is to do an integrity check.  This you should do once in a while.  Once you are ready to enable the Local Continuous replication you can do so using the same Exchange Management Console.  Just click on Resume Local Continuous Replication.  Check the status field until it says Healthy.

Every once in a while you should check the integrity of the passive storage group copy to make sure that the database and the log file are not corrupted.  This can be accomplished by running Exchange Server Database Utilities (Eseutil.exe).

Microsoft Exchange LCR Compliments Archiving

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators