Exchange 2007. eseutil /cc. JET_errLogSectorSizeMismatch

Consider this scenario.

You’ve had to recover email from an older version of Exchange. You’ve created a new domain, installed Exchange with the same organisation name and added a new Exchange server where the Storage Group and Database retains the same name and structure.

You’ve successfully restore from tape. However the Database isn’t mounted and fails to mount.

You’ve try to replay the logs from the restore.env file and you get this error

eseutil /cc

Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume’s sector size) after 0.78 seconds.

You get the same error when you try to reply the logs manually using eseutil /r

The cause? The sector size.

As discussed in this blog post, the sector size and physical disk types for databases in an Exchange 2010 Dag need to remain the same across all volumes. I highly recommend taking the time to read the article in it’s entirety. https://blogs.technet.microsoft.com/exchange/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes/

First. I had a look at my disks by running this command

fsutil fsino ntfsin DriveLetter:

Take note of my example below and the ‘Bytes Per Physical Sector’

>fsutil fsinfo ntfsinfo c:

NTFS Volume Serial Number :       0x1e6848246847f953
Version :                         3.1
Number Sectors :                  0x00000000077ccfff
Total Clusters :                  0x0000000000ef99ff
Free Clusters  :                  0x00000000004ba961
Total Reserved :                  0x0000000000000040
Bytes Per Sector  :               512
Bytes Per Physical Sector :       4096
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0

>fsutil fsinfo ntfsinfo D:

NTFS Volume Serial Number :
Version :                         3.1
Number Sectors :                  0x00000000077fefff
Total Clusters :                  0x0000000000effdff
Free Clusters  :                  0x0000000000c99b89
Total Reserved :                  0x0000000000000000
Bytes Per Sector  :               512
Bytes Per Physical Sector :       512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0

>fsutil fsinfo ntfsinfo e:

NTFS Volume Serial Number :
Version :                         3.1
Number Sectors :                  0x000000007cffefff
Total Clusters :                  0x000000000f9ffdff
Free Clusters  :                  0x0000000002edb5ec
Total Reserved :                  0x0000000000000000
Bytes Per Sector  :               512
Bytes Per Physical Sector :       512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0

The backup product had restored the logs required for the database onto the C:\. As this failed the database was in a ‘dirty shutdown state’ and eseutil /cc or eseutil /r failed

The ‘Bytes Per Physical Sector’ for the C:\ differed from the disks that held the database and logs

The fix was relatively simple. I moved the logs required for restore to the D: and reran eseutil /cc

 

Advertisements

Exchange 2013. Management Tools. RDS. Part 2

You may have read this post
https://mxrnz.wordpress.com/2014/07/30/exchange-2013-management-tools-rds/

Or this Microsoft Article
https://support.microsoft.com/en-gb/kb/2921141

I had given up on this and after some time, I thought I’d reattempt this with the Exchange 2013 CU 12 release and to my surprise the Management Tools have installed!

I’m not so sure when the fix was made and I may have missed it in the updates notes, however it does appear to have been fixed!

Party Time!

 

 

Public Folder Mailbox. Storage Limit. False Alerts.

In a follow up to this post

https://mxrnz.wordpress.com/2015/12/07/exchange-2013-split-publicfoldermailbox-ps1-fails/

I had received quota alerts and moved the folders, a default quota of 2 GB, a PublicFolderStatistics only shows 4 MB of data, a Search-Mailbox with -SearchDumpsterOnly returns nothing and yet the alert was still generating.

A quick google brought up the blog post below suggesting this is a bug and I am inclined to agree. http://no-one-uses-email-anymore.com/bogus-public-folder-mailbox-quota-alerts-in-exchange-2013/

My advise in the mean time is to ignore the alert entirely until there is a fix.

A better option would be to remove the reliance on Public Folders altogether. Like all good things, this will take time.

Alert: 
PublicFolders health set unhealthy (PublicFolderMailboxQuotaMonitor/PublicFolders) – Public folder mailbox %Mailbox%is approaching storage limit – The public folder mailbox PFMailbox11 is approaching its storage limit. Consider splitting the mailbox using Split-PublicFolderMailbox.ps1. This warning will not be sent again for at least twenty four hours. Error context: {<Properties> <TenantHint>00000000000000000000000000000000</TenantHint> <MailboxDisplayName>%Mailbox%</MailboxDisplayName> <MailboxGuid>%guid%</MailboxGuid></Properties>} Knowledge: http://technet.microsoft.com/en-us/library/ms.exch.scom.PublicFolders(EXCHG.150).aspx?v=15.0.1130.7

Powershell Script. Remove old IIS Logs.

I don’t like to keep IIS logs for too long. Just over a week is plenty in my environment. To keep these under control , I run a powershell script with an automated task once a week.

There are likely better ways to manage this or better ways to write the script but in saying that, it works for me.

$Servers = “server1” , “server2”
$dir = “\driveLetter$\inetpub”
$daysOldLimit = 8
Set-Location MyScriptFolderLocation

$servers | foreach {
$server = $_

Get-ChildItem -Path (“\\” + $_ + $dir) -filter *.log -Recurse | foreach {

$timestamp = [datetime]$_.lastwritetime
$daysOld = (NEW-TIMESPAN –Start ([datetime]$_.lastwritetime) –End (get-date) | select TotalDays).TotalDays

If ($daysold -gt $daysOldLimit)
{
$FullName = $_.FullName
Remove-Item -Path $FullName
}

}

}

Exchange 2013 – Split-PublicFolderMailbox.ps1 Fails

You may or may not have SCOM in your environment and you get this alert.

PublicFolders health set unhealthy (PublicFolderMailboxQuotaMonitor/PublicFolders) – Public folder mailbox <mailbox> is approaching storage limit – The public folder mailbox <mailbox> is approaching its storage limit. Consider splitting the mailbox using Split-PublicFolderMailbox.ps1. This warning will not be sent again for at least twenty four hours.

You try Split-PublicFolderMailbox.ps1 only for it to fail.

Do this instead

Get the Public Folders in said mailbox, sort by itemcount or size.

Get-PublicFolder -Recurse | ?{$_.contentmailboxname -like “*mymailbox*”} | Get-PublicFolderStatistics | sort itemcount | select name, folderpath, itemcount, totalitemsize

Identify your folders and run

New-PublicFolderMoveRequest -Folders “\MyPath\ToFolder”, “MyPath\ToAnotherFolder” -TargetMailbox myPFMailbox

 

Exchange 2007. Recovery Storage Group. Dirty Shutdown.

It’s been a while since I’ve had to recover an Exchange 2007 Database for a Client. I created the Recovery Storage Group and ran the Restore job with success, except I missed the option to replay the log files and mount.

This meant that the database wouldn’t mount.

Error:
Mount-Database : Exchange is unable to mount the database that you specified. S
pecified database: MyServer\Recovery Storage Group\MyDatabase; Erro
r code: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-
544)

How to Resolve

You will need to work in the Command Line.

First. In your database folder, confirm this is indeed in Dirty Shutdown state.

Navigate to your Database Directory
eseutil /mh “MyDB.edb”

Look For
State: Dirty Shutdown

Second, Make a copy of the Restore.env and Log files from your Restore. Put into another folder.

Third. If you have the luxury of extra disk space, make a copy of the EDB and put into another folder. In my case, I didn’t have that luxury and needed to work from the original.

Fourth. Navigate to your new log directory.

Run
Eseutil /r <YourLogPrefix> /d <Path to DB Folder (not the EDB itself)>

In my case this was
Eseutil /r E01 /d J:\RSG\DB

Note: The prefix for your Logs will depend on the restored logs, in my case is was E01. It can be E00, E02, E03 etc.

In my case, I got a complaint that a log file was missing.

Recovery has indicated that there might be a lossy recovery option. Run
recovery with the /a argument.

Operation terminated with error -528 (JET_errMissingLogFile, Current log file missing) after 0.0 seconds.

Sometimes you may be missing one log, possibly from a read / write error when backing up. I used the /a switch for lossy option.
Eseutil /r E01 /d J:\RSG\DB /a

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.03
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode…
Logfile base name: E01
Log files: <current directory>
System files: <current directory>
Database Directory: J:\RSG\DB

Performing soft recovery…
Restore Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|
……………………………………………

Operation completed successfully in 3.438 seconds.

Success, I can now mount my database.

Exchange 2013. Exchange 2007 Public Folders. There is no existing PublicFolder that matches the following Identity: ‘\’.

Scenario: You have an Exchange 2013 and Exchange 2007 Co-existence environment. Both versions are at support levels.

You are having problems managing public folders from your Exchange 2007 console or the Public Folder Management Console.

Error: Get-PublicFolder : There is no existing PublicFolder that matches the following Identity: ‘\’.

Fix: In ADSI Edit, check the HomeMDB for The System Attendant under your Exchange 2007 Server. Confirm or correct it. This needs to point to the DN of your Mailbox Database.

Repeat for your Exchange 2013 Servers. In my case, the HomeMDB was empty. I populated with the DN of a 2013 Mailbox Database for each.