Friday, December 05, 2008
#
W00t! A new version of the Exchange Server 2007 Mailbox Server Storage Cost Calculator (sheesh, that's a lot of words) has been released, and the Exchange team has updated their original blog post on the subject to reflect the changes in the tool. (The calculator can be downloaded here.)
Why am I so excited? Well, I've been doing a lot of work around clustering and storage as of late (and having a lot of fun with it), and the work Microsoft has done for the calculator helps back up some of the work that I've done. Also, there seems to be a feeling among much of the Exchange community that SANs are best for Exchange, and I disagree with that viewpoint - I think a solution that the Exchange administrator can remain in control of is the best solution. Storage administrators don't really get Exchange, and have a tendency to say stuff like, "disk is disk", which drives me right up a tree. So my preference has always been to let the storage folks play with their bits, and have other folks let THEIR stuff reside on the SAN, and to keep Exchange away from their unappreciative hands. The storage cost calculator shows that there really are HUGE savings to be gained by following my preferred model, so I dig that too.
Anyway, the storage cost calculator is pretty cool stuff, and it definitely worth an afternoon's time to play with!
There are two types of message journaling for Exchange; message envelope journaling is the preferred method if you need to capture messages for compliance purposes, because it captures not only the message (the P2 information, i.e. the message contents), but also the message "envelope" (the P1 information, which contains specifics about who a message was sent to, including recipients who were blind copied, and expanded distribution list membership). Think about a letter you'd get in the mail - the envelope would be addressed to you, at your address, but the letter inside could say "Dear John, ...". Without envelope journaling, all you've got for reference is the "Dear John" portion of the message, but knowing who the message (i.e. letter) was actually addressed to (i.e. who received it) is also important contextual information.
If you're implementing a third-party archiving product, it will (or should - don't pick one that doesn't understand message envelope journaling) know how to handle messages that are journaled with the envelope data.
If you're not implementing a separate archiving product, and plan to use the journal mailbox as an archive, there will be some hoops to jump through to read the actual messages. However, if you're saving these messages for
compliance-related purposes, you want the envelope data, and I would strongly advise you that the journal mailbox is an inadequate long-term archive, especially for compliance-related purposes.
Database corruption is the bane of Exchange Administrators – and recovering from any type of corruption is complex and time-intensive. When either logical or physical corruption is present, administrators must determine the best path to database recovery. Recovery options include:
· Repairing the database by running the Exchange Server Database Utilities (ESEUTIL). This process entails taking the database itself offline (and thus, not providing messaging services to the users) and using ESEUTIL in repair mode (ESEUTIL /p). ESEUTIL can be destructive in certain circumstances, as database pages that cannot be repaired are discarded. After ESEUTIL has completed in repair mode, it should then be run again in defragment mode (ESEUTIL /d). ESEUTIL. It should be noted that ESEUTIL can process about 9GB of data per hour, so two different ESEUTIL operations on a 50GB database would take approximately 11 hours to complete. After both ESEUTIL operations have completed, database integrity should then be performed by using the Information Store Integrity Checker (ISINTEG) with the “–fix” and “–test alltests” switches. If ISINTEG is able to fix all database errors on the first pass, a report will be presented that shows the error count as zero – if all errors were not able to be corrected with the first ISINTEG operation, ISINTEG will need to be run again until the error count is zero. ISINTEG performance is roughly equivalent to that of ESEUTIL, depending upon the number of errors that must be corrected.
· Restoring an older database copy and letting the transaction logs generated since the backup was taken replay in order to bring the database back to the state when the failure occurred. These operations take less time than running database utilities; however there have been numerous instances where organizations that thought their backups were valid found that the backups could not be restored to operation when necessary. The speed of database recovery varies depending upon the type of backup performed – Volume Shadow Copy Service (VSS) allows third-party vendors to provide quick database backups, and these backups are also quick to restore – but they may only be restored to their original location. The Recovery Storage Group (RSG) introduced in Exchange Server 2003 reduced the complexity of previous recovery methods, however the RSG only works with streaming backups which take much longer to restore than VSS-based backups. Depending upon the number of transaction log files that must be replayed, there may be a significant amount of time that passes before a restored backup will be available to provide messaging services. (No lie - I once experienced a 10+ hour wait while transaction logs replayed. Not fun.)
· In cases where the database is still operational, the best option is often to move the mailboxes themselves to a different information store. This process involves less down time for users (while a mailbox is in the process of being moved, it will be unavailable to the individual with whom it is associated; mailboxes that are not in the process of being moved will remain available for access) and is the preferred path when available. If a database has dismounted due to physical corruption and cannot be remounted, this option will not be available.