Humans are always screwing up. How else do you explain all the user errors we tally up in the workplace? Thanks to the human in us, user errors are a common occurrence for just about every organization. In some cases, these blunders are minor disruptions that can be easily corrected. In others, they’re monumental mistakes with the potential to cause serious damage. Here are seven examples of how user error can hinder an organization’s Exchange Server deployment.
1. Limited Resources
Exchange Server is a robust application that commands quite a few resources in the way of processing power, RAM, and disk space. When planning a deployment, administers have to consider any applications and services that may be running alongside a copy of Exchange. In fact, if you’re installing it on a virtual machine, it should be the only application running next to Windows. Virtual servers are naturally thin on hardware resources, so forcing Exchange to compete for them is almost certain to result in company-wide hiccups.
2. Data Deletion
Accidental deletions are usually the result of brain freezes that can’t be explained by logic. Perhaps it’s a user who mistakenly deletes an email with the attachment needed to start on a client’s new project. Or maybe it’s an administrator who goofs and deletes an entire Exchange server from the local drive via their management console. Emails and other mailbox items aren’t necessarily permanently erased when zapped with the delete button. However, if those items somehow end up deleted for good or can’t be easily recovered, there’s going to be a little egg on someone’s face and a lot of inconvenience.
3. Dirty Shutdown
In the Exchange environment, a dirty shutdown refers to an instance where a new database is abnormally terminated and not saved correctly. It can happen after a power outage, server crash, or a user mistakenly hits the reset button without properly shutting down the system. While a Dirty Shutdown does not always lead to a corrupted database, it does require the affected database to be recovered. If it can’t be recovered with the “Eseutil /k” utility from the command line interface, your best bet is a third-party Exchange recovery tool that can repair and restore the database.
4. Improper Load Balancing
In general, load balancing ensures that the workload of a server or application is evenly distributed across all available endpoints. In the Exchange environment, it’s vital to making sure users enjoy ideal performance and around the clock availability – even if one endpoint should fail. Companies can compromise the reliability of their Exchange deployment by failing to implement a load balancing solution to optimize its operation. Microsoft actually recommends using a third-party hardware load balancer opposed to the software-based counterparts for the best results.
5. Database Overload
Over time, an Exchange database can grow fairly large as emails, contacts, tasks, and other items are continually added. Allowing them to gorge without consideration for capacity is an error that can make performance a major issue when disaster recovery efforts come into play. According to Microsoft, Exchange 2013 can support databases of approximately 16 TB a piece in capacity. 200 GB is what it recommends as best practice. Go beyond that recommendation or even in the vicinity, and those databases could move dreadfully slow during backup and recovery procedures.
6. Ignoring Performance Indicators
Users are increasingly interfacing with Exchange from smartphones, tablets, and other connected gadgets. These devices, though very capable, still aren’t reputed for their blazing speed so it’s not uncommon to experience some slowness when connecting to your mailbox. Writing such issues off as common is often a mistake by the users who fail to report them, or the administrators who fail to address them. Administrators should specifically keep an eye on the Common, Client, Mailbox, and other relevant performance counters Exchange makes available. This data, combined with general user awareness, will help organizations identify and address performance issues in a timely manner.
7. Incomplete Upgrade
A lot of companies are currently in the process of upgrading from Exchange 2010 to 2013. It’s a very extensive process that combines aspects such as licensing, installation, and data migration with a host of structural and procedural changes. Some companies may be tempted to make the move in phases and relax once all their mailboxes and contacts are switched over. Kind of like moving into a new house and living out of boxes once you’ve got your bed and TV setup (who does that?). In order to avoid what could be a myriad of problems, administrators should proceed with transferring polices, addressing legacy issues, and other steps needed to complete the migration.
An Exchange Server deployment is a menace with enough complexity behind it to challenge novice and seasoned users alike. As we’ve mentioned here, administrators tend to be some of the biggest offenders in the screw-up department. User error may rear its clumsy head every now and then, but considering what’s at stake, devoting the extra focus to keep it in the bag is certainly worth the effort.
To learn about one of the best Microsoft Exchange backup, management, migration, and recovery tools available, read about the award winning StorageCraft Granular Recovery for Exchange.
Photo Credit: Dennis Skley via Flickr