You may across  Event ID 1022, Error 1245 in the application log of an Exchange 2007 mailbox server. The event can appear frequently and references a mailbox within the description, see the example below:

Solution:

The 1245 error indicates that the mailbox referenced has exceeded the storage limit/quota configured on the mailbox database. To stop the errors occurring, clear down items in the referenced mailbox or re-configure your storage limits on the database:

The error below is received when searching for mail within OWA:

“Search results may take a long time to appear because Microsoft Exchange Search is unavailable. Results will not include matches in the e-mail body.”

This is due to the full-text index being corrupt. To confirm that the index is corrupt, run Test-ExchangeSearch from the Exchange Management Shell on your mailbox server and the following output will be received:

ResultFound : False

SearchTime : –1

Solution:

Run ResetSearchIndex.ps1 –force MailboxDatabaseName from the Exchange Management Shell

The ResetSearchIndex.ps1 script is located in the <drive>:\Program Files\Microsoft\Exchange Server\Scripts folder.

Recently we had an issue on Exchange 2007 that required us to change the mailbox database that the System Attendant Mailbox was located in.

We did this by doing the following

1. Open Adsiedit.msc
2. Connect to the CN=configuration
3. Navigate to CN=Services , CN=Microsoft Exchange, CN=Organisation Name, CN=Administrative Groups ,CN=Administrative Group, CN=Servers, CN=Server Name,  CN=Microsoft System Attendant
4. Right click Microsoft System Attendant and choose properties
5. Select “HomeMDB” in the list and click edit
6. Change the value to the Distinguished Name of the mailbox you would like to move the System Attendant to
7. Click ok and exit
8. Restart the System Attendant service on the mailbox server

Now your System Attendant Mailbox should be moved

We had an issue recently backing up DPM when a Log File got deleted form the log files directory and we were then unable to backup the mailbox databases in the storage group with the following error “DPM has detected a discontinuity in the log chain for Storage group StorageGroup on ServerName since the last synchronization. (ID 30216 Details: Unspecified error (0×80004005))”

The way we fixed this was by doing the following.

• Dismount Mailbox Databases in the Storage Group
• Make a copy of all .log files from the storage group log files directory and then delete them.
• Mount the databases again and you should now be able to perform a backup

Recently we came an issue where we couldn’t back up Exchange via DPM and the following error was given “DPM has detected a discontinuity in the log chain for Storage group First Storage Group on servername since the last synchronization. (ID 30216 Details: Unspecified error (0×80004005))”

After researching the event id most articles pointed to circular logging be enabled as the culprit but this was not the case as it was turned off.

Resolution

1. Take a backup of the Exchange databases, the Storage Groups logs and chk file,  by first dismounting the stores and taking a copy to a different location.
2. Delete the Storage Groups logs and chk file
3. Mount the Exchange Databases
4. Run DPM Backup and this should complete

We recently had a problem with one of our customers where a user was trying to set up a smartphone to sync emails but was getting a 0x86000C0A error when attempting to do so.

After some researching on the error we found that the user was a member of the Domain Admins group and any user that is a member of a protected security group will have problems when setting up syncs with smartphones. If the user is a member of any of the following groups then active sync may not work:

Account Operators
Administrators
Backup Operators
Domain Admins
Domain Controllers
Enterprise Admins
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators

When we removed the user from the domain admins group we still could not set up the phone. The problem seemed to be related to the AdminSDHolder, more information about it can be found here:

http://blogs.technet.com/b/askds/archive/2009/05/07/five-common-questions-about-adminsdholder-and-sdprop.aspx

Resolution

What we did to resolve this issue was to go to AD Users and Computers, click the view menu and select Show Advanced Features. Open up the affected users properties and click on the Security tab. Click on the advanced button and make sure that ‘Include Inheritable Permissions From This Object’s Parent’ is ticked. Click OK twice to close the user account.

After AD replication has occurred then the user should be able to set up their phones for sync.

Note

If your user needs to have domain admin credentials or any of the roles that are in the list above then the best practise is to create another account for the user with the administration role that they require.

I came across an issue on Exchange 2007 a while back now. Basically we received a few alerts on SCOM regarding the Hub Transport Service being stopped on an Exchange Server.

So i jumped onto the server in question and came across the following events in the event log.

“Event Type: Error
Event Source: ESE
Event Category: Transaction Manager
Event ID: 623
Date: 
Time:
User:  N/A
Computer:
Description:
edgetransport (5612) Transport Mail Database: The version store for this
instance (0) has reached its maximum size of 249Mb. It is likely that a
long-running transaction is preventing cleanup of the version store and
causing it to build up in size. Updates will be rejected until the
long-running transaction has been completely committed or rolled back.
Possible long-running transaction:
SessionId: 0×0000000005217400
Session-context: 0×00000000
Session-context ThreadId: 0x00000000000014F8
Cleanup: 1

Event Type: Error
Event Source: MSExchangeTransport
Event Category: Storage
Event ID: 17017
Date:  
Time: 
User:  N/A
Computer:
Description:
Transport Mail Database: Quota exceeded while performing a database
operation. The Microsoft Exchange Transport service is shutting down.
Exception details:
Microsoft.Exchange.Isam.IsamVersionStoreOutOfMemoryException: Version store
out of memory (cleanup already attempted) (-1069)
at Microsoft.Exchange.Isam.?A0x051b51e0.HandleError(Int32 err)
at Microsoft.Exchange.Isam.Interop.MJetSetColumn(MJET_TABLEID tableid,
MJET_COLUMNID columnid, Byte[] data, MJET_GRBIT grbit, MJET_SETINFO setinfo)
at
Microsoft.Exchange.Transport.Storage.DataStreamImmediateWriter.Write(Int64
position, Byte[] data) ”

So i started the Hub transport service again and then had a quick look at the mail queue via queue viewer. In The queue viewer i spotted a 250mb e-mail and consequently was just too big for the hub transport to handle and causing the service to stop.

To get his issue fixed i had to get rid of this mail out of the queue, first i tried removing the mail with no NDR, this got rid of the mail, however 20 seconds later it reappeared again.

So what i had to do was recreate the queue, so it basically got rid of all mail that was currently in the queue. The downside to this is that other mail still queuing up on the Hub Transport server will be lost to.

Resolution

1, Make sure the MS Exchange Transport service is stopped.

2, Rename the following directory “<drive>\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue” to “<drive>\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue_old”

3, Start the MS Exchange Transport service

4, This Should Recreate the Queue folder and the “MS Exchange Transport” will no longer stop.

This Should Resolve Your Issue.

Daniel Davies