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.

An administrator can correct the misconfiguration using the steps outlined below:

• Confirm that the directory permissions have been set correctly.
• Verify that the specified directory exists and can be accessed without errors.
• Ensure that the storage is configured correctly for the storage group.
• Ensure that the storage hardware is operating correctly.

There is another situation that administrators have encountered when error 2074 can be generated and that is if they have recently enabled Standby Continuous Replication (SCR) in their environment.

In RTM version of Exchange Server 2007 Microsoft introduced Local Continuous Replication and Cluster Continuous Replication which are variations of SQL Server’s Log shipping feature.

The RTM version of Exchange 2007 is configured with rules, that in a continuous replication environment, prevent a log file from being deleted only if it has been backed up first and then replayed into the copy of the database. However, when using SCR, this rule is modified.

Standby Continuous Replication allows truncation of the log files at the SCR source as soon as they have been inspected by all SCR target machines. Unfortunately the log file truncation at the SCR source server does not wait until all log files have been replayed into all SCR targets. The reasoning for not waiting is because of the large log replay latency times associated with some of the SCR target copies.

As mentioned earlier, enabling SCR in an environment can produce the  EventID 2074 from the MSExchangeRepl source. A more detailed error message would look similar to the following:

“The directory \BYPASSsomefilename required be the Microsoft Exchange Replication Service for BYPASSStorage does not exist. Check the system and its permissions”

Some administrators have unsuccessfully tried to fix the problem by reseeding the database and then resuming the storage group copy. The database can be reseeded but when the primary site tries to access the log file, it will still show this error in the application log. Reinstalling both nodes will also not fix the error.

The problem is that Standalone Continuous Replication enables share on the Storage Group log folder and if this share is not created then log shipping cannot start.  To correct this problem an administrator can create the share with the name of the source server such as, in this case, “somefilename”.

And another workaround is to set the permissions to Full Control since the setup process may not set the share permissions as needed.

Administrators have also reported that by stopping the sharing of the shares that have already been created then that will allow the replay service to recreate them with the proper permissions. I have not tried this particular workaround but thought I should include it as a possible solution.