Fix for 8DOT3 Names Causing Exchange Server Error

8DOT3 errorUpdating your database is an important task to maintain. Sometimes lack of doing routine maintenance can result in your database failing. For example, suppose you have a passive Microsoft Exchange Server 2010 SP3 database that you’re attempting to mount. The database that is currently in place dismounts without any problems, and your copy mounts. After yours has mounted, the copy status turns into a failed state, which results in an overall failed copy.
To check specifically what went wrong you’re going to need to run an Exchange Management Shell (EMC) command. The command is: Get-MailboxDatabaseCopyStatus | fl identity,errormessage. What it returns will tell you where the database has failed. In this instance it will specify that a file check has failed and points to log files.

The reason it’s returning a failed message is because of 8dot3, which is a name creation for log files. A difference between the two databases was the fault in this case because the 8DOT3 instance creates a different name per log file. So when the findfile query is executed during the activation of the database, it returns failed because the sequence of log files is invalid.

A typical log file will look something like this:

06/08/2013 3:00pm 1,046,432 E01dg4~1.LOG E000000022A.log

In the above example we can see that this particular files 8DOT3 name is E01dg4~1.LOG, and this will cause the error message when moving a database.

In order to determine the 8DOT3 name creation settings we’re going to run this command:

fsutil 8dot3name query d:

This command will return information on the volume state as well as letting us know if 8DOT3 is enabled on the volume. For this particular command we’re assuming that the log files are located in the d: drive.

You can also use mount points in the above command instead of specifying the particular drive. For example instead of saying d: you could put, “Volume{428842df-5s01-11ae-a35c-806e6c6c6963}” this will return the same information as mentioned above, but will only be for the specified mount point.

You will later on change the 8DOT3 in order to disable it, but for now we’re going to try to control this setting through group policy. With the following command we’re going to change the registry key for the exchange servers. The key setting we’ll use is:


This key setting will change the group policy settings to a value of “2”. If instead of “2” you use “0” you won’t be able to change the configuration of the volume.

Finally we begin changing the 8DOT3 settings. In order to disable this setting you can run the following command:

fsutil 8DOT3name set

This command will disable the 8DOT3 name creation for all volumes. You can also run commands to specify certain volumes. For example:

fsutil 8DOT3name set d: 1

This will disable an individual volume on the d: drive. You can also indicate entire drives by omitting the “1” value and just ending the command at d:

The fsutil command can be used multiple ways; here are two examples of how the format works for the command:

fsutil 8dot3name [set] { <DefaultValue> | <VolumePath> {1|0}}

fsutil 8dot3name [query] [<VolumePath>] Now all these commands will only cause new files to be 8DOT3 free. In order to change existing files we’re going to need to do some more work. The first thing you need to do is back up all your Exchange databases; this includes both the passive and the active databases. Since we changed all these attributes in the previous commands, backing up will exclude the 8DOT3 names which will result in no errors when moving the database.

If you cannot perform a full backup for any reason, you can still attempt to manipulate the log files to ensure that the 8DOT3 names are omitted from the logs. You should keep in mind that the previous example is better suited for safety as manipulation of the log files is more prone to error. That being said the first step is to stop the exchange service by running the following command:

stop-service msexchangerepl

After performing this command, go to your log folder and begin moving all transaction logs that contain “Enn*.log” to a temporary folder.

Next move all logs to their original location.

Keep performing this process until you are finished with the logs. Afterward restart the exchange server.

After the restart you should no longer see a failed message.

Written by Jacob Rede

Leave A Reply