Exchange Storage Groups # 2 - Transaction Logs

Following on from yesterday’s article about storage groups, here is another tip.

 

Transaction logs.

 

Transaction logs are created on a “per storage group” basis. i.e. if you have 2 stores in one storage group, you will generate a very mixed bag of transaction logs that are an amalgam of both stores within the group. Therefore your TL volume is filling up at twice the rate and in the event of a database failure of one store, the play forward after a restore will not be as efficient.

 

This reinforces the reasoning for using one storage group per store. Keep it simple.

Exchange Storage Groups

This one cropped up a while ago actually but might benefit others moving to Exchange 2007 from earlier knowledge of Exchange.

 

In the olden days when the world was black and white and we weren’t in a recession, you put all of your Exchange database stores in one storage group. This was due to a memory leak when you used more than one storage group but it was addressed.

 

People who went on the training courses or read the books had it drummed into them that you filled the storage group with stores before creating the second storage group.

 

That was old school.

 

Now you fill the server with storage groups putting one store into each until you run out of storage groups before putting a second store in the first group.

 

This applies to Exchange 2003 and 2007.

 

Mail flow from Exchange 2003 to Exchange 2007

Scenario:
You have added your first Exchange 2007 server into your Exchange 2003 network. You followed all of the steps but still mail will not flow.

Reason:
The original connectors don't always work but I haven't installed at enough locations yet to work out a pattern.

Solution:
Firstly check for link state suppression on the Exchange 2003 server:
Regedit (usual caveats about using regedit)
Drill down to: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc\Parameters.
Right-click Parameters and select New | DWORD value.
Name the new DWORD value SuppressStateChanges.
Double-click SuppressStateChanges.
In the Value data field, enter 1.

Restart the SMTP and Exchange Routing Engine services on the Exchange 2003 server.

Then:
In EMC on Exchange 2007, delete the receive connectors on the HT (there will probably be 2 of them), one called Client (port 587) and one called Default (port 25).

In ESM on Exchange 2003, delete the one routing group connector from the E2003 routing group that specifies the E2007 name.

In ESM on Exchange 2003, delete the one routing group connector from the E2007 routing group that specifies the E2003 name.

Then in EMS on Exchange 2007, type the following:
New-RoutingGroupConnector -Name "2003 to 2007 conduit" -SourceTransportServers "E2007 server name" -TargetTransportServers "E2003 server name" -Cost 1 -Bidirectional $true -PublicFolderReferralsEnabled $true

There are no services that require stopping / restarting.

Mail will start to flow.

Exchange 2003 running slowly

End user problem: Exchange 2003 is running slowly.
Symptoms: Ave disk queue length is huge, disk response time poor.

Red herring: It isn't the array, the controller, the OS, defragmentation, the stores, the Exchange installation. But by all means check them - I did.

The problem: If you are using Entourage (IMAP4 client for Apple Macs), that client requires MIME encoded mail. If you do a move mailbox from one store to another, you get all email converted BACK to MAPI. In other words, once you have moved users, their IMAP client has to convert it all from MIME to MAPI again which results in the disk thrashing and subsequent slowness of Exchange.

The more times you move mailboxes to counter this problem, the worse the problem becomes as Entourage/Exchange has to start again. By default, IIS converts these but IIS can run out of memory for large attachments and I've got lots of those.

Reg hack (terms and conditions apply, back up everything and only touch if you know what you are doing, do this at your peril etc, etc):

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeWEB
Create a new key called DAV
Add a new value in that new key:
Value name: MaximumResponseSizeInBytes
Data type: REG_DWORD
Radix: Decimal
Value data: value

Where value is the maximum msg size in BYTES. It has been suggested to set this to 1GB (1,073,741,824 decimal)

Then restart the Exchange Application Pool within IIS Manager.

Bearing in mind that some of the messages internally here are over 100MB, the IIS default was not entirely enough. Hopefully that has put that issue to bed.

Exchange 2003 (for a change)

I spent part of the weekend moving the Stores off the fibre RAID and onto a SCSI RAID. Then the PST files for extinguished users were moved similarly.

Disabled the fibre array, disabled the fibre channel HBA. Restarted.

This morning I had a request for the "Exchange 2003 Outlook Web Access Reply Red Cross in Internet Explorer" problem. It is a hotfix available on KB911829. Unfortunately that one likes a restart so I chose NOT to restart the server. The problem is that the IIS stack isn't then happy so the Entourage users cannot connect.

Email to staff - Exchange to be restarted, alert the troops.

All seems well now apart from the quizzical EMAIL that arrived an hour later that says (and I quote) "I take it email still down?"

Erm, you EMAILED me to ask if email is down? Roll on my next Exchange user group meeting at 6pm.

Exchange 2007 migration

It has been on the back burner to respond and now I can't recall who asked!!

Someone said "Can I just copy my Exchange Server 2003 database files onto the Exchange Server 2007 box and just mount them and Exchange will do the rest?"

No.

a) The STM file has gone away / been pushed back into the EDB whilst Ex2007 retains the benefits inside the EDB file. So Jet would not understand the file.
b) The EDB database / Jet engine is new and improved and it does not make sense for it to be backwardly compatible with the older EDB files as that would compromise the speed.