MS Exchange Server Administration and its Challenges- A Walk Through

“With career start-off as a system architect, my work-experience as an admin for network, Windows Server, Active Directory, and third party security protocols have been contribution in understanding Microsoft Exchange Server Space. With Certification as Microsoft Exchange Server Master, I am currently serving my services as an Exchange administrator in a medium sized enterprise.

For sharing knowledge and experience with people from IT administration community, Experts-Exchange has been an interactive platform. Finding solutions and providing answers to various technical aspects is a reason to be a part and contributor to this association of experts.”

Exchange Server is a calendaring and email solution that works on Windows Server platform. It has been an ultimate choice of organizations to build an in-house Server platform and by far what has been realized is its management is not that easy.

The initial days of database administration includes day-to-day management of Server which was mailbox creation, troubleshooting Outlook and mailbox related issues. With growing skills and experience, Exchange Server installation, security design management, configuring Active Directory, integrating crucial elements to the messaging environment, disaster recovery planning and many other tasks made me a Professional administrator of the organization. But overall, the job remained the same, “Ensuring Security and High-Availability of the Messaging System”. 
 

Learning and Practicing Phase

To start off by managing Exchange 2007 was challenging and the updation in Exchange 2010 took a little more time than expected to understand the installation and data migration procedure. Installing a new Server platform, you actually spend days to understand the requisites, prepare for it, and most importantly find all the resources for a successful deployment. The entire go through however, have been an accomplishment and certainly with some lessons for the future. 
 

“Restoring Database: Always a Better Option”

If something wrong happens to the database, it is better to go for recovery than repair process (you will surely avoid complications by choosing this!). Before you actually start restoring, you must be very clear about WHY you are restoring it. Plus, there are multiple approaches that can be made for database restoration. I consider backup as one of the strongest aspects of a disaster recovery (DR) plan because it actually helped to cope up with situations like:

#1: Hardware Failure where Exchange Server was supposed to be rebuilt. Once the Server was rebuilt, backup can be easily restored to it.

#2: Minor system failures (power, hardware, or software) resulting in a corrupt database. Instead of repairing it, the better option is to restore it from backup.

Maintaining online backup regularly and testing it as a part of DR strategy is quite helpful in dealing with server failure scenarios. But restoring an entire database backup is not the solution in every case.
 

“Backup: Not Always a Solution!”
 

Backups are created after understanding business requirements. If multiple databases from data centers are to be restored, definitely this approach can be adopted, but it does not help if single mailbox from an EDB file has to be recovered or just specific items like contacts have to be extracted from the mailbox.

#1: Once, SAN failure took place in business hours and it caused damage to one of three databases on Exchange 2007. My dependency on backup created more trouble because as a part of the solution, only a full tape backup was available. A Recovery Storage Group (RSG) was created for so that employees were able to send and receive emails. After the backup of all three databases were restored to RSG and log files were replayed, both the DBs (dial-tone and that on RSG) have to be swapped and merged. Lots of Effort and Time Demanding Technique!!!

#2:  For moving mailbox database from one Server to another, Database Portability is definitely a good option. But redirecting all users to new user databases takes time. Even migrating mailboxes is not simple with backups.

In different situations, different approaches have to be made. Understanding the problem, a relevant disaster recovery plan has to be prepared and executed to minimize any negative impact on business-continuity. 
 

“Backup up Database with Server Roles is Important”
 

Exchange 2007 and 2010 are managed via different Server roles. An important fact learnt from past experience is backing up Server roles is equally important as database. For example:

#: Configuration settings of Edge Transport Server get saved in Active Directory Lightweight Domain Services which is a static copy of Active Directives and do not get replicated on the Server. You have to run ExportEdgeConfig.ps1 script that will export the user-settings into an XML file and helps creating cloned configuration of the edge transport server.  

#: Exchange 2007 has five Server roles; they are the same in Exchange 2010. All local configuration details of Server roles get saved into local files and the Registry.

#: The voice messages (or the audio) files on Unified Server role can be accessed using a UNC path. So, you just do need to store these files on Exchange Server.

#: Websites and other web services used by the Client Access Server (CAS) have all records in IIS Metabase. If any changes are made to IIS metabase, they will not be reflected in Active Directory. Rather, the changes done will get saved into CAS locally which has to be saved using system-state backup.

There are numerous levels of protection for complete recovery and restoration of database and the one amongst them is securing Server role settings.
 

“Message Tracking: It Really Helps!”

Even if everything is working fine, users might complain about problems in the message flow. The problem could be anything ranging from trouble with network or DNS. However, the first resolution is checking the message queue. There is free message-tracking tool by Microsoft that helps to test status of message-queue. So, it is better to enable message tracking system for Transport Server to remove hindrances in messaging system.

Preventing interference in mail-flow is equally important as the maintenance of Server. The message - tracking tool is an effective option available for administrators that should be actively used to ensure smooth messaging within enterprise. The Queue Viewer is a part of Exchange Management Console ‘Toolbox’ under the ‘Mail Flow Tools’ section. 
 

“Recovery is Directly Proportional to Log Files”
 

There is a unique definition of the word “Recovery” in context to Exchange Server. It is replaying log files against the database. No matter if it is soft recovery or hard recovery of the database, it completely depends upon availability of log files. Complete series of log files and that too in healthy state should be on place to get back inaccessible or lost database.
In very rare options, where the requirement is Exchange database recovery without log files and there is no better solution than using ESEutil /p switch that repairs EDB file. Basically, a last resort but very helpful in scenarios when log files are missing.

Transaction logs monitor minor to major change in database and relaying it when Server starts or DB is restored from backup is an integral part of what we called Exchange database recovery.  
 

“Managing Space on Server: Day-to-Day Requirement”

Many of the users working with Outlook have a misconception that size of their OST on the local machine is the size of mailbox on the server. The actual space occupied by mailbox on disk is the combination of mailbox limit, white space, and the dumpster size.

Database dismounting is the worst impact that can be faced as a result of non-management of disk space. Fortunately, this is something that a dedicated administrator generally doesn’t come across but yes regardless to disk management causes innumerable issues to Exchange Server.
Using PowerShell commands or utilities like JetStress tool can be a great help in management of disk space and taking the required steps to prevent adverse consequences.
 

The Phase of Challenges

How you do it matters more than what you do! Problems while managing a Server environment are obvious but tackling them with intelligence can be a solution to various tragic situations. There are number of solutions from Microsoft’ end that definitely helps an administrator to work around a problem but the actual problem is, these tools and services are time consuming and demands foolproof expertise from our end. The major challenges while managing Exchange Server are:

#: Maintaining the Right Plan for Disaster Recovery: You never know in what form the problem will strike the Server or its mailboxes. For different issues, distinct recovery approach has to be made in order to ensure that business continuity is maintained.

#: Co-existence for Migration and Requisites: Moving mailboxes to different Exchange Server calls for a co-existence environment. Handling two different Servers and extremely unique database structure is quite risky.

#: Management of Public Folders and Migration: Unlike mailboxes, recovery and migration of public mailboxes is not easy. Different set ups and solutions have to be used while dealing with public folders and honestly, they are not easy!
ESEutil, Isinteg, Exchange Management Console, PowerShell commands are some of the help services by Microsoft’ end. They prove quite helpful in database management and works perfectly as DR plan. But, they have limitations and failure.  However, with right usage of backup and these native solutions, it is possible to cope up with minor and major issues successfully.
 

More on Backup Monitoring and Validation for Disaster Recovery in the Upcomming Article -

Monitoring and Validating Backups: A Part of Disaster Recovery Plan!