다음을 통해 공유

8dot3 and the Exchange 2010 SP3 LAG Copy

  • 아티클

Recently I deployed Exchange 2010 SP3 and experienced a few headaches when it came to the LAG copy.  It turns out that this was probably related to the known issue with Exchange 2010 SP3 and 8dot3Name, even though we never activated these copies and with no transaction logs on the active copy containing any 8.3 names (weird!). 

My configuration:

  • Exchange 2010 SP2 RU4 on Windows 2008 R2
  • Circular Logging enabled (backup-less environment)
  • LAG copy containing more than 2 weeks of transaction logs

First, what is 8.3 name and why was it enabled?   This is a legacy naming convention, from the old MS-DOS days.  By default, our Windows 2008 R2 build does not have 8.3 enabled.  However, we discovered that a GPO had been set which overrode that value as a requirement for a government compliance program.  It turns out that lots of older government compliance programs required this to be enabled. 

An example of files with and without 8.3 naming convention:  (dir /x)

clip_image001

How did we discover was enabled?   In our testing, we had a number of LAG database copies go to a FailedandSuspended state.  Our troubleshooting led us to the known issue listed above and we confirmed using the FSUTILcommand andDIR /X. 

What problems did we experience? If we upgraded a server from SP2 to SP3 that contained either the LAG copy or was the owner of the Active copy and if the LAG copy contained at least 1 log that had an 8.3 naming convention, then intermittently the LAG copy would go to a failedandsuspended state.  Not all copies failed all of the time.  Nor did we have to activate the DB for it to fail – it just did it whenever the server was rebooted.

What did we do to fix it? We knew that if the LAG copy contained any transaction logs with 8.3 naming convention, the DB would fail.  So we made a change to the server using FSUTIL (FSUTIL 8dot3Name Set 1).  It took us a day later to discover that the setting reverted, thus leading us to an old GPO entry.  After changing the GPO and forcing the update to occur, we could see that newly created transaction logs were not getting 8.3 names. 

Next, we wait for all database copies to get cycle thru the old logs (those containing the 8.3 names) before making any server reboots or significant changes.  We could fail a database over to another copy, this did not do anything. 

We verified that all database copies contained no transaction logs containing these 8.3 files names by running a PowerShell command per server:

$GetDatabase = Get-MailboxDatabase -Server $Env:Computername foreach ($DB in $GetDatabase){$LogPath = "$($DB.logfolderpath)"+"\*~1.log" ; If((cmd /c dir $LogPath) -ge 1){write-host $DB.Name " - 8dot3 Log Files Found" -ForegroundColor Yellow} Else{Write-Host $DB.Name}}

 

Basically, before you upgrade to SP3, check that your server does not have 8.3 naming convention enabled (FSUTIL 8dot3Name Query).  If so, set that to disabled and cycle through all your transaction logs before deployment. 

As you can see, you don’t have to actually activate the DB for this to cause issues. 

Good Luck!

D