Error message when you try to activate a passive copy of an Exchange Server 2010 SP3 database: "File check failed"

Applies to: Exchange Server 2010 Service Pack 3

Symptoms

Consider the following scenario:
  • You activate a passive copy of a Microsoft Exchange Server 2010 Service Pack 3 (SP3) database by using Windows PowerShell or the Exchange Management Console.
  • The mounted database dismounts without issue, and the passive copy mounts.
  • The database copy status changes to a failed state during the initializing stage on the copy that is now passive. In addition, the status message for the database copy shows failed.

When this issue occurs, you receive an error message that resembles the following when you run the Get-MailboxDatabaseCopyStatus | fl identity,errormessage cmdlet in the Exchange Management Shell (EMC);

The Microsoft Exchange Replication service encountered an error while inspecting the logs and database for DB\Server on startup. Error: File check failed : Logfile 'path\Exx.log’ is generation number1; however the expected generation is number2.

For example, you may receive the following error message:

The Microsoft Exchange Replication service encountered an error while inspecting the logs and database for DB\Server on startup. Error: File check failed : Logfile ‘f:\logs\DB\Enn.log’ is generation 2024; however the expected generation is 2004.


Cause

If 8DOT3 name creation is enabled on volumes that contain transaction logs in Exchange Server 2010 SP3, this can cause invalid transaction logs to be returned as part of a findfile query during the databases' activation process. This causes the databases to be sent to a failed state because of an invalid sequence in the transaction log generation numbers.

No data loss occurs because of this failure.

Resolution

To resolve this issue, install the following update rollup:
2866475 Description of Update Rollup 2 for Exchange Server 2010 Service Pack 3

Workaround

Step 1: Determine the configuration of 8DOT3 name creation

To determine whether 8DOT3 name creation is enabled, run the following command from an elevated command prompt. (Here, we assume that the transaction log files are on drive C.)
fsutil 8dot3name query c:
If the expected output returns something that resemblbes the following, 8DOT3 name creation is enabled:

The volume state is: 0 (8dot3 name creation is enabled).

The registry state is: 2(Per volume setting-the default).

Based on the above two settings, 8dot3 name creation is enabled on C:
Or, the expected output may return something similar to the following:
The volume state is: 0 (8dot3 name creation is enabled).

The registry state is: 0 (Per volume setting - the default).

Based on the above two settings, 8dot3 name creation is enabled on C:
This indicates that drive C has 8DOT3 name creation enabled.

Make sure that you run this command on the volume that contains the transaction logs. You can also use the following if you use mount points: 
fsutil 8dot3name query Volume{928842df-5a01-11de-a85c-806e6f6e6963}
You will have to substitute the volume GUID to match your volume's GUID. To determine volume and GUID for a specific drive, run the following command:
mountvol [Drive:]Path /L
Depending on your requirements, you can set 8DOT3 name creation to be disabled either for all volumes or on a volume-by-volume basis, as is outlined in step 3. It is most important that you make sure that the volume that contains the transaction logs is disabled for 8DOT3 name creation.

Step 2: Check Group Policy for disable 8DOT3 name creation

Before you try to disable 8DOT3 name creation, you should be aware that this setting can be controlled through Group Policy. Please check to determine whether Group Policy is configured to change the following registry key on the Exchange servers:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation"=dword:00000002

If this setting is controlled through Group Policy, remove this setting from the Group Policy settings for the Exchange servers, and set the NtfsDisable8dot3NameCreation DWORD to a value of 2. This allows for individual volume changes.

Note If a value of 0 is used, you can't change volume configuration.

For more information about the Fsutil 8dot3name command, go to the following Microsoft TechNet website:
Fsutil 8dot3name

Step 3: Change 8DOT3 name creation

To disable 8DOT3 name creation for all volumes, run the following command: 
fsutil 8DOT3name set
If you prefer to disable only on individual volumes that contain the transaction logs, run the following command: 
fsutil 8DOT3name set c: 1
Note In this command, c is the letter of the drive that contains the transaction logs.

Or, you can run on a specific volume. To do this, run the following command: 
fsutil 8dot3name query Volume{928842df-5a01-11de-a85c-806e6f6e6963}
After you change the volume's configuration to disable the 8DOT3 name creation, you can verify that the setting is disabled. To do this, run the following command again: 
fsutil 8DOT3name query c:
This causes all new files that are created or copied on this volume not to generate a 8DOT3 name for the file name. However, all existing files still contain the 8DOT3 name. Therefore, you have to resolve this.

Step 4: Remove 8DOT3 names for existing transaction logs

Option 1

The preferred option is to run a full backup on the Exchange databases. This causes the transaction logs to be truncated and removes the existing logs that have 8DOT3 names. After all transactions logs that contain 8DOT3 names are truncated, database moves will not fail.

Option 2

If the backup option is not available, you have to manipulate the copy of all transaction logs to make sure that the 8DOT3 names are removed from the files. To do this, follow these steps:
  1. On a server that contains the passive copies of the database, stop the Microsoft Exchange Replication service.
  2. In Windows PowerShell, run the following command: 
    stop-service msexchangerepl
  3. In Windows Explorer, locate the folder in which you are storing transaction logs.
  4. Select all the transaction logs of type Enn*.log, and move them to a temporary folder. Make sure that you move only the transaction logs of type Enn*.log. You should move no other file types.
  5. move all transaction logs back to their original location. In this move process, the 8DOT3 names are removed.
  6. Repeat this process for all transaction logs for all passive databases.
  7. Restart the Microsoft Exchange Replication service: 
    start-service msexchangerepl
    Note This step should be completed first for all passive copies of databases.
  8. Move the mounted (active) copy of the database to a copy on which the transaction logs are manipulated: 
    Move-ActiveMailboxDatabase DB2 -ActivateOnServer MBX1 -MountDialOverride:None 
  9. Stop the Microsoft Exchange Replication service, and then again move transaction logs to a temporary location and then back to their original location.
  10. Start the Microsoft Exchange Replication service. Now, database failure during a move-activemailboxdatabase action should not occur.

More Information

Other common symptoms that occur are in the Application log and in the ExchangeHighAvailability-Operational log. There, events appear that resemble the following:

To determine whether you have still have 8DOT3 names on transaction logs, you can run the following command at a command prompt in the transaction log location: 
dir /x
If transaction logs still contain 8DOT3 names, you see something that resembles the following: 


04/10/2013   04:16 PM         1,048,576 E0C749~1.LOG E0000000118.log 04/10/2013   04:16 PM         1,048,576 E01D7D~1.LOG E0000000119.log 04/10/2013   04:16 PM         1,048,576 E00834~1.LOG E000000011A.log 04/10/2013   04:16 PM         1,048,576 E05DFF~1.LOG E000000011B.log 04/10/2013   04:16 PM         1,048,576 E06DCB~1.LOG E000000011C.log 04/10/2013   04:16 PM         1,048,576 E0F768~1.LOG E000000011D.log
Note If you see the E0F768~1.log name present in the next-to-last column, you still have transaction logs that have 8DOT3 names. Therefore, you will still have issues when you try to move active databases.