Using the Microsoft Exchange Replication service can sometimes mean that administrators must determine which occasional errors to fix later and which errors need correction as soon as possible.

Administrators will usually have the Microsoft Exchange Server 2007 Management Pack for Operations Manager (MOM) running which can relieve them of constantly having to monitor the Windows Application log on systems that run Exchange Server 2007.

If the following event or events are logged in the Details table then the Management Operations Manager will generate an alert such as: ‘A directory required by the Microsoft Exchange Replication Service does not exist.”

The event which causes this alert is as follows:

Product Name:    Exchange
Product Version:    8.0 (Exchange Server 2007)
Event ID:        2074
Event Source:        MSExchangeRepl
Alert Type:        Error
MOM Rule Path:    Microsoft Exchange Server/Exchange 2007/Mailbox/Continuous Replication
MOM Rule Name:    A directory required by the Microsoft Exchange Replication Service does not exist.

When this event occurs it means that the Microsoft Exchange Replication (MSExchangeRepl) service could not access the required directory for the source logs, the target logs, or the checkpoint file or could not access the “targetsystemdirectory”. The event can occur if there is a permission issue on the directory, a hardware failure, or a configuration failure. If an administrator has misconfigured the system to use a particular volume and then removed the volume that the configuration points to then the event ID 2074 may be generated. Replication will fail for the respective storage group. Once the misconfiguration has been corrected then an administrator can successfully resume the replication.

Continue reading Troubleshooting Exchange Error 2074

Microsoft introduced its first analyzer tool for Exchange in 2004. Called by the catchy title Microsoft Exchange Server Best Practices Analyzer, the software proved to be so successful that similar software was rolled out for troubleshooting other aspects of Exchange.

Best Practices Analyzer emerged after Microsoft observed certain patterns when addressing critical situations with its support services. Critical situations require urgent assistance to solve a problem that’s disrupting service to an organization’s members and its important business operations. What Microsoft found was that not only were the number of critical situations growing, but that 60 percent of them were caused by configuration errors, not bugs in Exchange. Moreover, new critical situations arising in some shops were the same ones that had emerged in other organizations just a few months earlier.

Microsoft began by creating a utility to gather key information throughout an Exchange environment. When a customer faced a critical situation, they were told to run the utility and Microsoft would sift through the data to ferret out the root cause of a problem.

Collecting data was only the first step. Next, an engine was developed that could analyze the data and expose it to a set of rules. The rules established thresholds. If a key data item was outside the acceptable range in a threshold, the rule would “fire” and a red flag would be raised for support folks.

Continue reading Use Microsoft’s analyzing tools to keep Exchange humming

Outlook 2010 includes some great, though rather less than obvious, troubleshooting capabilities. You can enable diagnostic logging from within advanced options of Outlook, and hidden within the application’s system tray icon is the option to test email auto-configuration as well as to determine what messages are displayed to the user.

Enabling this logging, and testing connections, are both great ways to diagnose connection issues and to determine whether any connection problems are on the client side, or the server side. If you’d like to learn more, please read on.

Enabling diagnostic logging cranks up the data generated by Outlook to 11, so it is not the sort of thing we want to just do and leave turned on. If you have a client with connection issues, it is the best way to generate detailed logs of what is going on between the client and the server. When this logging is enabled, Outlook will display a message in the title bar, and lots of disk activity will occur. Continue reading Troubleshooting Outlook 2010 connections

Some of the new features of Exchange Server 2010 are that of the inclusion of two Volume Shadow Copy Service (VSS) Writers: the Replication Writer and the Store Writer. These writers make it easier for backup applications to create Windows Server 2008 VSS snapshots. For databases, Exchange Server includes the Replication Writer for replicating databases using the Database Mobility Features. And for those databases that are not replicated using a Database Availability Group (DAG) there is the Store Writer.

The Replication Writer is built into the Replication Service and is available on the passive node of the DAG server. The Replication Writer is used to support backing up particular databases that have had a shadow copy taken of the replicated instance of the transaction log files and of the replicated instance. By using the Store Writer, backups taken by Replication Writer can be restored to the active database location.

The Store Writer is built into the Exchange store and is available on any mailbox server. Store Writer is used for backing up and restoring active databases.

Continue reading Troubleshooting Exchange Replication Service Errors

One of the frequent challenges I have faced as an email administrator is trying to troubleshoot a system from the outside. That is to say, while I am viewing the system from the inside, and have administrative rights to it, the problem I am working on may be related to something outside my control, and I have limited visibility into what is happening from the perspective of other systems. It can be just as important to know how other mail systems interact with your systems and to see this from the outside perspective as it is to review your own logs. Unless I had access to another email system, my Gmail account was my best, albeit limited, resource to use for testing.

Fortunately, I have found several online resources through the years to help with setting up, testing, and troubleshooting email systems. The following fourteen are those that I have found to be the most useful. Some are single purpose, others have lots of great tools. Together, they let me validate/test just about any aspect of my email system, both from a server perspective, and from a client’s. This post will divide them up into categories for their best use, provide links, and share a little about what you can use these for and what to expect.

Continue reading 14 online resources for email admins

A major factor in moving from Outlook 2000 to Outlook 2003 was the advantage of utilizing RPC calls to make connections from Outlook clients to an Exchange server. The specific technology for making these internet connections was RPC over HTTP.  RPC means remote procedure calls and allow your Outlook MAPI clients to connect to Exchange servers using HTTP or the secure HTTPS protocol.

Remote Procedure Call (RPC) is a protocol that one application can use to request a service from another application running in another system in a network without having to understand network details. Remote Procedure Calls uses the client/server model. The requesting application is a client and the application which supplies the service is the server component. Remote Procedure Calls are synchronous operations that require the requesting application to wait until the results of the remote procedure are returned from the server. The uses of lightweight processes or threads that share the same address space allow multiple Remote Procedure Calls to be performed concurrently.

One of the advantages of using RPC over HTTP is that this methodology can support secure connections to the Exchange server and thus add an additional layer of security between the client and the server.

The other benefit is that these RPC commands could be encapsulated in HTTP. What this means from an administrator perspective is that only one of two ports would need to be opened at the firewall – port 443 or port 80 – as opposed to earlier versions which would have required two additional ports: port 135 and port 53. These ports were well known to hackers and used by them to create havoc within many organizations on a routine basis.

Continue reading Troubleshooting Connections to Exchange Server using HTTP

Understanding the underlying mechanics of how Exchange Server works and how it stores messages can be very helpful to administrators especially when problems occur and resolution is needed immediately.

One of the most important components of the Exchange Server is that of the database which contains all the messages and directory information before those messages are applied to the database. Exchange Server 5.5 Standard Edition uses fault-tolerant, transaction-based databases that can grow to a maximum of 16 GB.  The size of the database for Enterprise Edition is limited only by the hardware used for storage. As with all databases Exchange Server uses transaction log files to be able to reconstruct the data should a failure occur. This data has already been accepted by the server but has not yet been committed.

The important database components of Exchange Server 5.5 include the Information Store and the JET Database Engine. The Information Store is actually comprised of two separate databases: the private information store database, Priv.edb, which manages data in user mailboxes and the public information store, Pub.edb, which manages data in public folders. Both databases are based on the JET format used to track and maintain information by utilizing the log files.

Administrators can encounter problems with the Exchange Server if any of these log files or the database become corrupted for some reason. Typical areas where database files can become corrupted include:

• Page (file system) level
• Database (JET database engine) level
• Application (Exchange information store) level

And the three most common errors that are associated with file-level problems in an Exchange database are:

• -1018 JET_errReadVerifyFailure
• -1019 JET_errPageNotInitialized
• -1022 JET_errDiskIO

Most of the -1019 and -1022 errors are caused by problems in the underlying system but the -1019 and -1022 errors can also be the result of errors in the Exchange Server code itself.

Continue reading Troubleshooting “–1018” Exchange Server Database Errors

When using Outlook 2007 in Cached Exchange Mode users can access their email and can read emails while in an offline mode. But when they try to access additional mailboxes and shared mail folders they note that they are only allowed to do so when the mailboxes and shared mail folder are available only in an online mode. There are some workarounds which will allow them to access additional mailboxes and shared mail folders in the offline mode.
Even though shared mail folders cannot be cached users can cache any other shared folder though such as Contacts, Calendar and Public Folders.

Additionally, if an administrator has granted full mailbox access to those additional mailboxes, then they could be set up as IMAP accounts. An email administrator can help with the IMAP settings.

Support for caching shared folders with Cached Exchange Mode depends on the version of Outlook that is running. There are workarounds for Outlook 2003 and Outlook 2007 but if administrators don’t want to spend time on implementing workarounds then they can upgrade to Outlook 2010 which has full caching support for additional mailboxes.

Continue reading Troubleshooting Caching Shared Mail Folders in Outlook 2007

Administrators have many responsibilities when it comes to ensuring the reliability and performance of their servers. But sometimes their responsibilities get overshadowed by just trying to maintain a set level of performance. If their server performance slows down or begins to degrade they must be able to know where to go looking to correct the behavior before it begins to adversely impact their end user community.

One of those areas that can present performance problems is in the area of memory. And as one of the main components of server performance – CPU, I/O and memory – lack of memory resources can be fairly easily solved by purchasing and installing more memory. But when more memory is not the answer then the troubleshooting process can be more time consuming as there are more aspects of memory usage which must be examined.

Many times the memory performance problems don’t show up until the software applications – such as Outlook – have been upgraded. Some administrators have reported performance problems with paged and non-paged pool memory as the number of Outlook 2007 client have been added within the organization.

To solve this problem it is necessary that the paged pool memory used by client connections to the Exchange server be reduced. This can be accomplished by reducing the size and number of access tokens. Additionally, the client connections can also be distributed and managed so as to optimize performance.

Continue reading Troubleshooting Pool Memory in Exchange Server 2003

Troubleshooting mail flow problems in Exchange Server can be a complicated process. There are many factors that can contribute to a slow down in processing and may include messages that are backing up in remote delivery queues due to bad DNS configuration or unintentional third party software settings. As previously discussed in another blog post some messages might be getting backed up in the Messages awaiting directory lookup queue in which case those backed up messages might be due to heavy distribution group expansions or permissions inheritance blocks. It is also possible that messages cannot be received due to a metadata corruption issue.

Some of the ways that the slow down of mail processing is exhibited include:

• Client response is very slow when email status is changed such as when end users change an email’s status from read to unread, or if email items are opened of deleted.
• Messaging Application Programming Interface (MAPI) error messages are generated that include the phrase “Client Operation Failed.”
• Log files in the Mdbdata folder show continuous growth even though very little has actually changed in the public folder resources or the mailbox resources.
• Attempts to improve the speed of processing are unsuccessful such as creating a new folder and moving the contents of the folder, with the slow responsiveness, to the new folder. The move is only temporarily successful as the speed of processing will continue to steadily decrease until the processing matches the previous unacceptable condition.
• Administrators may notice that some folders are more easily accessible than others within the same database and show no slowdown or problems in responsiveness. This uneven distribution of problems and responsiveness can include special folders such as gateway folders like the Mts-in and Mts-out folders.

If users are receiving unexpected non-delivery reports when sending messages then an administrator should review those NDRs to obtain the DSN code that is contained in the non-delivery report. Lookup the DSN code definition and then determine what actions will be needed to correct this error.

Continue reading Troubleshooting Mail Flow Problems in Exchange Server