You Had Me At EHLO...

Free swag to Exchange user groups

I have a bunch of swag and I'd like to find it a good home. Some of it is fun new stuff (Exchange Communities "Road Warrior" kits (including mini-USB mouse etc) and a nifty one-handed stapler/tape dispenser), the rest is mainly legacy gear [oops I mean vintage] from past releases - Exchange 2000 and 2003 t-shirts, jackets, other tchotchke's.

I thought I'd check if any Exchange user groups would like small care packages of this swag for a future meeting.

In order to be eligible for this, you must be a leader of a user group that meets in person and talks about Exchange at those meetings at least four times a year and has a fairly up to date web page.

If you meet those criteria, send an email to exblown AT Microsoft DOT com with your name, the name of your user group, the address to which we can send the goodies, and a link to your user group web page. We've got enough swag to do a decent-sized care package (3-5 things) for 10 groups; if we get fewer than 10 submissions, we'll do larger care packages. We'll accept submissions for two weeks.

Thanks!

- KC Lemson

First ever Austin Exchange User Group Meeting coming up

To try help local Exchange User Groups, we'll have a few posts related to the subject. We want to help build stronger Exchange community!

You are invited to attend the first ever Austin Exchange User Group Meeting!

Are you interested in learning more about Microsoft Exchange Server?  Would you like to meet some of the local Microsoft Exchange MVP's?

We will be holding the first ever Austin Exchange User Group meeting.  Join us for a lively discussion and an opportunity to network with peers.  During our first meeting, we will be asking for information on session topics you would like covered, and will give a sneak peek into some of the new features that will be introduced with Exchange 2007 (formerly Exchange "12").

Detailed information:

When: Tuesday, May 23rd, 7:00pm

Future meetings will be held on the fourth Tuesday of every month.

Where: Austin, Texas Microsoft Office/Microsoft Technology Center

Directions and address information can be found here:

http://www.microsoft.com/mscorp/info/usaoffices/gulfcoast/mtc_austin.mspx

There is no registration required, but please e-mail Ben Winzenz if you would like to confirm your attendance.  Refreshments will be provided!

Thanks and we hope to see you there!

- Nino Bilic

Setting Folder Permissions in Outlook - what really happens?

Someone asked the following, so I thought I would try and address the issue as I think it is one that is commonly misunderstood:

Could you enlighten us on what happens when an Outlook user uses the permissions tab on a folder to grant access to other users?  It apparently isn't the same as when they use the Delegates.  I found a script to dump the delegates, but I have users who are out of control assigning folder permissions!

Setting Permissions on Folders

So when an Outlook User uses the Permissions tab to give another user access to their folder, they are doing just that, giving another user the specified amount of access to the specified folder (One could compare this action with modifying the NTFS permissions on an OS folder).  They are not giving the other user the ability to log into their mailbox and then only access the specified folders.  They are allowing the other users to use the "Open > Other User's Folder..." functionality within Outlook and have some level of access to their folder(s).

Here is an example:

1.       I created a user named "User1", created a mailbox for that user on an Exchange 2003 SP2 server, and then logged into that mailbox using Outlook 2003.

2.       I created a second user named "User2" and also gave that user a mailbox on the Exchange 2003 SP2 server.

3.       From Outlook 2003 logged into User1's mailbox, I Right-Click on the Inbox folder and select Properties.  I then click on the Permissions tab.  The first thing that you should notice is that both "Default" and "Anonymous" have a Permission Level of None.

4.       I add User2 and give that user account the "Author" Permission Level.

5.       Now I log out of User1's mailbox and now log into User2's mailbox using Outlook 2003.  Again, I cannot log into User1's mailbox using User2's credentials.  User1 has not granted User2 any mailbox level permissions, just folder permissions.

6.       Once I am logged into User2's mailbox, I go to the menu bar and click FILE > OPEN > OTHER USER'S FOLDER.  The first thing you should notice is that Outlook does not arbitrarily let you just access any folder.  You can only access the Calendar, Contacts, Inbox, Journal, Notes, and Tasks folders.  So I select the Inbox folder and click OK.  I can now see the contents of User1's Inbox and perform the actions applicable to the permissions that User2 has been given.

Figure 1

Since Outlook only allows you to open the 6 enumerated folders, there is really no need for Users to be modifying the folder permissions to grant other users access to the "Sent Items", "Deleted Items", etc. folders because the other users probably don't have a client that will allow them to even access those other folders.  However, I can see how this might lead to Helpdesk calls because the users are expecting that since they can apply Folder Permissions, then there is a way that the other Users' can access their folders, and this just is not the case with Outlook.

Setting Delegate Access in Outlook

In Outlook under Tools > Options, there is a tab labeled "Delegates".  Here is the description that Outlook gives:

Delegates can send items on your behalf. To grant permission to others to access your folders without also giving them send-on-behalf-of privileges, go to the Properties dialog box for each folder and change the options on the Permissions tab.

If you read this carefully, you will see that the "Delegates" tab is really doing two things:

1.       Modifying the "Send-on-Behalf-of" privileges for the user account which is stored in the "publicDelegates" property on user object in the Active Directory.  This privilege can also be modified by an Administrator by going into "Active Directory Users and Computers" (ADUC), viewing the properties of the appropriate User Account, clicking on the "Exchange General" tab, and then clicking on the "Delivery Options" button.  A new dialog box titled "Delivery options" will appear and within this new dialog box is an area labeled "Send on Behalf".

2.       Modifying folder permissions so the delegated user account can have the appropriate access to the mailbox folders.  These folder permissions are stored on the folders within the Exchange Store.

So let's walk through an example:

1.       I created a user named "User1", created a mailbox for that user on an Exchange 2003 SP2 server, and then logged into that mailbox using Outlook 2003.

2.       I created a second user named "User2" and also gave that user a mailbox on the Exchange 2003 SP2 server.

3.       From Outlook 2003 logged into User1's mailbox, I clicked on "Tools" in the menu bar and then selected "Options".  From the "Options" dialog box, I then clicked on the Delegates Tab.   Of course this should be empty by default.

4.       Since I would like to add User2 as a delegate, I click the "Add..." button.  This pops up a new dialog box that wants me to select a user(s) to give Delegate Access to.  I select User2 and click OK.

5.       Now another new dialog box appears titled "Delegate Permissions: User2".  One thing you should notice is that nowhere on this dialog box does it say anything about Send-on-Behalf-of.  What it does allow you to do, however, is to decide what level of permission you want to give the delegate to the 6 defined folders: Calendar, Tasks, Inbox, Contacts, Notes, and Journal.  Notice that it does not allow you set give the Delegate permission to any folder you want, nor does it allow you to give any level of permission.  Instead, you get to choose from None, Reviewer, Author, and Editor.

Figure 2

6.       I see that the default set of permissions are sufficient for what I want User2 to have on User1's folders, so I click OK on this dialog box and then click OK on the "Options" dialog box.

7.       So what has happened is that User2 now has "Send-on-Behalf-of" privilege for User1 and User2 also has Editor permission on User1's Calendar folder and Editor permission on User1's Tasks folder.  You can verify the "Send-on-Behalf-of" privilege by opening up User1's AD Object via Active Directory Users and Computers, click on the "Exchange General" Tab, and then click on the "Delivery Options" button.  You will see that User2 is listed as having "Send on Behalf" permission for User1.  To verify the folder permission, I just opened the properties for the "Calendar" and "Tasks" folders and view the Permissions tab.

NOTE: Even though User2 has not been granted any permission to the other four folders, Outlook still adds User2 to the folder permissions with a Permission Level of "None".

8.       In reference to the "Delegate receives copies of meeting-related messages sent to me" check box, Outlook creates a server-side rule that forwards the appropriate messages to the delegate.

9.       In reference to the "Delegate can see my private items", this setting is stored locally in the Manager's mailbox.  Since the enforcement of "Private Items" is done on the client side, the Delegate's Outlook checks for this setting to see if the enforcement of "Private Items" is to be enabled or disabled.

Modifying Folder Permissions for Delegates

OK, so now what happens if the user modifies the permissions of the Calendar or Tasks folder for User2?  Will that mess up their Delegate settings?  The answer, of course, is Yes and No.  Directly modifying the folder permissions is not going to change the Send-on-Behalf-of permissions that were granted for User2.  However, it will change what User2 is allowed to do in the Calendar folder.  If I now view the folder permissions for User2 on the "Calendar" folder, I see that the "Permission Level" given by Delegation is "Editor".  However, I decide that I want User2 to be able to create subfolders under User1's Calendar folder.  So I check the box next to "Create subfolders" which changes User2's "Permission Level" to "Publishing Editor".  If I know go back to the "Delegates"  tab and view the Permissions for User2, I see that User2 now has "Custom" permission on the Calendar folder.  This is to be expected since the "Publishing Editor" Permission Level is not enumerated in the drop down menus.

Figure 3

So it is apparent that when Outlook opens the Permissions for an existing Delegate, it goes to each of the folders and sees what permissions that Delegate has been given.  Therefore, if I now modify the Inbox folder to give User2 "Contributor" permission, modify the Contacts folder to give User2 "Review" permission, and modify the Journal folder to give User2 "Nonediting Author" permission; I will see the following as the Permissions for the Delegate User2.  You can see that Outlook has enumerated the permissions on all the folders and displayed the appropriate Permission Level in the drop down box.

Figure 4

So can you guess what happens if you remove a Delegated User?  If you said, "Remove the 'Send-on-Behalf-of' privilege and remove the folder permissions for the removed Delegated User from the Calendar, Tasks, Inbox, Contacts, Notes, and Journal folders," then you are correct.   Removing a Delegated user will remove the Delegated User's permissions for the six predefined folders, no matter how the folder permissions were granted.

Here is another trivia question, can you guess what happens if you have already given User2 the necessary folder permissions on the Inbox folder and then decide later to specify User2 as a Delegated User?  If you said, "The previously defined permissions on the Inbox folder for User2 will probably be changed," then you are correct.  The unfortunate reality is that when you add a new Delegated User, Outlook does not iterate through the six folders to see if that account already has permissions.  Instead, it just assumes that it doesn't and gives you the default dialog box (see Figure #2 above).  By default, the added Delegated User has a Permission Level of "None" on the Inbox.  If this is not changed to be what User2 has currently on the Inbox folder, then the folder permissions will change.

In Closing

Using the Delegate functionality of Outlook is not something that all users will need to do.  However, if users are adding Delegates, then they are adding an entry to each of the six folders' permissions.  If users are out of control specifying Delegates, then they are probably out of control assigning folder permissions, and don't even know it.

- Chris Ahlers

New Exchange fixes may disrupt Blackberry, Goodlink and other services

CALL TO ACTION

A change in Exchange permissioning behavior may impact mobile communications and other add-on applications for Exchange. Shared and resource mailboxes may also be affected.  By evaluating in advance whether this change will impact your environment, you can take simple remediation steps to ensure that installation of a new Exchange update will not impact critical services. A script is available to help you identify accounts and applications in your environment that may be affected.

EXECUTIVE SUMMARY

A change has been made in how the "Send As" permission works in Microsoft Exchange. In the past, additional accounts could be granted the "Full Mailbox Access" permission to a mailbox and these accounts could then send mail as the mailbox owner. From now on, the "Send As" permission must be explicitly granted to additional accounts or they will not be able to send mail as the mailbox owner.

This change can affect add-on services that have relied on "Full Mailbox Access" alone for impersonating users to send messages on their behalf. For example, the user of a mobile email device may compose a message on the device. This message is transmitted to the mobile access service, which logs on to Exchange and sends the message as the user.

New rollups and service packs for both Exchange 2000 and Exchange 2003 will include this change, as will all updates and hotfixes for the Exchange Information Store service (store.exe).

The change was made several months ago and has been documented in Microsoft Knowledge Base Article 912918. However, many administrators have been caught by surprise after downloading an Exchange store update for a different issue. Therefore, the Knowledge Base article has been rewritten to more fully explain the change, and Microsoft will be publicizing the article widely, both internally and externally. A sample script has been added to the article that shows administrators how to quickly identify affected accounts and to correct their permissions, if necessary.

This change in permissions behavior will not keep Exchange mailbox owners from sending mail when logged on as themselves. But it may keep them from sending from a mobile device that impersonates them, or affect other applications or users who send mail as them. This change also does not affect "cross-forest," "resource forest" or mixed Exchange 5.5 and Exchange 2000/2003 installations.

Nonetheless, running the script right now is a good idea, both to get familiar with how it works, and to find out whether you have affected accounts you don't know about. You may have created resource or other shared mailboxes and forgotten to grant "Send As." Or you may be running scripts and applications that do not grant "Send As" when they should.

The script for finding affected accounts and granting them the right permissions  is available from this link:

http://support.microsoft.com/kb/912918

FREQUENTLY ASKED QUESTIONS

WHY DID YOU MAKE THIS CHANGE IF IT BREAKS SOME APPLICATIONS?

The change was implemented because of multiple requests from customers, and it provides additional security functionality in several scenarios. For example, consider a disaster recovery situation where an Exchange administrator needs full access to all mailboxes in a database in order to merge or salvage mailbox contents. Before, you could not grant such access without also giving the administrator the ability to send as any user in the database.

Correcting problems created by the change is straightforward--just go to the mailbox owner account and grant the "Send As" permission to the account that needs to send as that mailbox.

The old behavior was confusing too. An administrator might explicitly deny "Send As" rights and the Deny would have no effect when an account had "Full Mailbox Access". The way it works now is easier to understand and administer.

IS THERE A REGISTRY KEY OR SOME OTHER WAY TO OVERRIDE THE NEW BEHAVIOR UNTIL I'M READY FOR IT?

No, there is not. Providing a registry key or other override was considered and rejected because it would allow temporarily overriding the enhanced security whenever someone wanted to.

Something to remember is that this change applies only to additional accounts that are granted "Full Mailbox Access." If you are the mailbox owner, you don't need additional "Send As" permission. In cross-forest or Windows NT 4 mixed domain scenarios, the "Associated External Account" is treated like the mailbox owner, and so is a delegate who has been granted "Full Mailbox Access." Microsoft Knowledge Base article 912918 discusses each of these scenarios and exceptions in detail.

WHAT EXACTLY DOES THE SCRIPT DO?

The script is pretty simple. It works on one Active Directory domain at a time. In its Export mode it finds all accounts in the domain that have "Full Mailbox Access" to a particular mailbox, but don't also have "Send As." It ignores accounts that already have both permissions. So the output file only contains accounts that might have a problem.

The Export file is tab-delimited. You can sort it and edit it in Notepad or Excel, and then feed the file right back into the script to grant "Send As" in bulk for all accounts listed in the file.

Full documentation and tips on using the script are included in the Knowledge Base article.

ARE THERE OTHER WAYS OF CORRECTING THE PROBLEM WITHOUT USING THE SCRIPT?

You can use the Active Directory Users & Computers console to set permissions on individual accounts. You can also grant "Send As" for all objects in a domain or container, and thus have the permission take effect by inheritance.  

WHERE DO I GO FOR MORE INFORMATION?

Microsoft KnowledgeBase article 912918 is the place to start. It includes the script and the details about how all of this works - including information about Outlook delegation scenarios. To really dig in to how Exchange permissions work, settle in with these white papers:

Working with Active Directory Permissions in Exchange Server 2003

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3ad.mspx

Working with Store Permissions in Microsoft Exchange 2000 and 2003

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/storperm.mspx

- Mike Lee

Exchange "12" has a new name!

With Beta 2 approaching, Exchange "12" needed a name. I know the suspense has been killing everyone.

Well the wait is finally over:

Exchange Server 2007

If you keep hearing the team talk about "E12" , "12", or "Exchange 12" - please understand - it's all the same thing. It just takes a while for us to adjust.

Thanks!

- Terry Myerson

Exchange is 10 years old!

Seems like yesterday that Exchange 4.0 hit the market. In March of 1996 Exchange 4.0 was released. I thought I would give you a link for the geeks among you that have been along for the ride and for those that go even further back to ALL-IN-ONE, MailWorks, cc:Mail, IBM PROFS etc.

ITPRO has a great look back if you're interested in taking a look back at the evolution of hardware, Exchange Clients, Mobile devices, OWA, etc.  http://www.windowsitpro.com/Common/adforceimages/Decade_of_exchange.pdf

It's been a whirl wind ride and now we are nearing Beta 2 of Exchange "12"! What will Exchange look like 10 years from now? What features would you want to see (hey why wait - ask for them now!). If Exchange 2016 was ready for release, what features would you be most excited by?

So, take a look back, reflect on where we have been, then put on your thinking caps and tell us what you want to see in the next release and the one after that!

- David Espinoza

Are 'ghosts' modifying distribution groups in your mixed-mode environment?

We've seen a few issues recently where members of DGs (Distribution Groups) in mixed-mode Exchange 200x and 5.5 seem to randomly and mysteriously disappear. We thought we'd share one known root-cause and also show you how to prevent the problem while doing your migration, if for whatever reason you are still running Exchange 5.5 =). One easy way to prevent this problem (and a few others) is to ALWAYS use the Exchange 2003 post SP1 cross-site mailbox migration wizard if you ever have to move mailboxes in a mixed-mode environment.

With that said, typically the problem occurs when you use a directory export/import to move mailboxes between Exchange 5.5 sites. For example, if you have two Exchange 5.5 sites Site S (Source) and Site D (Destination) and you would like to move all the mailboxes in Site S to Site D you might perform the following steps. (When we refer to a DL we mean a Distribution List on the Exchange 5.5 side and when we refer to DG we mean a Distribution Group on the Active Directory side)

1. Extract all the DLs of the mailboxes you intend to migrate
2. Export the directory Information from the source Exchange 5.5 server in Site S
3. Delete the source mailboxes in Site S
4. Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also wait for the Active Directory Account to become mailbox-disabled.
5. Do a directory import of the mailbox information in Site D to recreate the mailboxes.
6. Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site

The problem occurs after step 4. The following key points should help you understand why.

• Replication between Exchange 5.5 sites is governed by USN-Changed values.  Any changes made to an object in a directory in one site only replicate to other sites if that object's USN-Changed value is higher than the corresponding value in some other site.
• For the special case of a mailbox deletion, you would expect the USN-Changed value for any DL that the mailbox is a member of to increment after the mailbox deletion.  This is, however, not necessary because when you delete a mailbox from its 'home' site, the member property of the DL changes and the read-only copy of the mailbox in all the other sites gets deleted.  When the read-only copy is deleted in all the other sites the DL membership is updated as well. The salient point is without incrementing a DL's USN-Changed, all the necessary changes for the sites to be in-sync are properly accounted for. This works well for a pure Exchange 5.5 environment but creates a problem for a mixed-mode one with an ADC (Active Directory Connector) in the mix.
• As we know, the ADC compares the msExchServer2HighestUSN value on the RCA (Recipient Connection Agreement) to the USN-Changed value of an object in the Exchange 5.5 directory to determine whether the Exchange 5.5 object should be replicated to the AD. If the USN-Changed on an object is greater than the msExchServer2HighestUSN on the RCA, the object has been changed in the Exchange 5.5 directory and needs to be updated in the AD. If msExchServer2HighestUSN is greater than or equal to USN-Changed, no changes have occurred on the 5.5 object that need to be updated (replicated to) on the AD side.  See the following knowledge base article for further details 253840. 

In this situation, since the DLs' USN-Changed isn't incremented in the 5.5 directory when you delete the mailboxes, the corresponding DG (Distribution Group) membership in the AD isn't updated.

If you later make changes that increment the USN-Changed on the DL, the entire object (including the earlier deletions) is replicated to the AD side and so some members seem to randomly disappear from the DG's members list. While replication in Exchange 5.5 is object-based and replication in the AD is attribute-based, Exchange 5.5 to AD replication is still object-based (think lowest common denominator). The solution to this problem is to force the USN-Changed on the DL to increment after performing the deletions in step 3. A DL's USN-changed increments under the following scenarios:

1. If you use the Exchange 5.5 Administrator program to open the DL's properties, modify any value and click Apply or OK (Or if you modify the DL's properties by doing an directory export/import with the standard header fields)
2. If you use the Exchange 5.5 Administrator program to open a mailbox's properties and remove a DL from the list of DLs that the mailbox is a member of
3. If the DL is updated by DRC or ADC replication changes from other 5.5 sites or from the AD respectively

Again, a DL's USN-Changed does not increment when you use the Exchange 5.5 administrator program to delete a mailbox from the DLs membership. To force the USN-Changed value on the DL to increment you need to make a 'dummy' change that falls under a, b or c after step 3. Our new steps to ensure we avoid the problem would therefore be:

1. Extract all the DLs of the mailboxes you intend to migrate
2. Export the directory Information from the source 5.5 server in Site S
3. Delete the source mailboxes in Site S
4. Use the Exchange 5.5 Administrator program to modify the "notes" field on all the DLs that contained the deleted mailboxes to force an increment of USN-Changed value. This step is critical
5. Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also trigger RCA replication and make sure that the 'member of' list for the AD user accounts that correspond to the deleted mailboxes is empty (except built-in groups such as Domain Users etc)
6. Do a directory import of the mailbox information in Site D to recreate the mailboxes
7. Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site.
8. Add the migrated mailboxes to the corresponding DLs manually using the Exchange 5.5 Administrator program. This step may not seem necessary but it is. Usually an administrator may notice that the member list is still present on the AD after performing the previous steps and therefore assume that nothing more needs to be done on the Exchange 5.5 side. Later when some other change increments the USN-Changed the deletions replicate to the AD and members seem to randomly disappear from DGs.

Everything should work fine and dandy at this point and you needn't worry about 'ghosts' modifying your DGs!

- Jasper Kuria and William Yang

Want to help us gear up for Exchange "12" Unified Messaging and Mobility release?

Here is a great opportunity for few "right" customers.  If you might be interested, please respond to "michael DOT liu AT microsoft DOT com" and I will set up a call with you to go through details.  The Exchange team is currently recruiting our best global brand name customers with an interest in Unified Messaging or Mobility to participate in Fall advertising (Note: Only 4 Customers will be selected). 

The Exchange team would provide:

- Resources to deploy Unified Messaging to 100 Exchange "12" mailboxes or 20 mobile phones to deploy on 100 Exchange "12" mailboxes
- A dedicated MCS or Partner resource to help you deploy Exchange "12"
- Two 64-bit servers to run Exchange "12"
- For UM, a dedicated Unified Messaging consultant to integrate Exchange "12" into your PBX system
- Access to the Exchange Unified Messaging or client access program managers

Your obligation would be to:

- Participate in global advertising campaign
- Provide project manager
- Deploy 100 mailboxes on Exchange "12" beta 2
- Work with Microsoft, Partner and Unified Messaging consultants to assist with technical implementation to be started June 15 through September
- PR/Marketing resource to coordinate advertising activity such as ad copy approval, photo shoots, case study and video interviews and approval

This is a great chance for the "right" customer (meaning, a customer we are looking for) to develop a deep relationship with the Exchange product team and showcase you and your company's technology leadership. Let us know if you are interested.  Send an email to "michael DOT liu AT microsoft DOT com" with the following information:

- Company name
- Contact email address
- How many employees
- Number of Exchange mailboxes
- Primary messaging system

Please note that this is a nomination process and not a guarantee of participation. Customers will be chosen based on a number of advertising criteria including benefits of E12 to the organization, name recognition, final target publications and geographies, etc.  We appreciate you being one of Exchange's very best customers!

- Michael Liu

Troubleshooting Version Store issues - JET_errVersionStoreOutOfMemory

Recently we have been seeing several issues in Support Services where Event ID 623 is being logged on the server. The symptoms include "Users unable to access their inbox", "Email backing up in the local delivery queue" and "Email awaiting directory lookup". Clients may also see emails stuck in the Outbox. Rebooting the server usually fixes the issue. In this blog, I have tried to explain what "Version Store" is and how to troubleshoot this issue.

A transaction is a series of operations that are treated as atomic (indivisible). So the operations in a transaction are either all done and permanently saved, or none of them are done. As an example we can consider the operations involved when we do something very simple like move a message from the inbox to the deleted items folder. The Version Store gives ESE the ability to track and manage current transactions; this allows ESE to implement Isolated and Consistent transactions.

What is Version Store?

The Version Store keeps an in-memory list of modifications made to the database. This list has several uses:

1. Rollback

If a transaction needs to rollback it looks in the Version Store to get the list of operations it performed. By performing the inverse of all the operations the transaction can be rolled-back

2. Write-conflict detection

If two different sessions try to modify the same record the Version Store will notice and reject the second modification

3. Repeatable reads

When a session begins a transaction it always sees the same view of the database, even if other sessions modify the records it is looking at. When a session reads a record the Version Store is consulted to determine what version of the record the session should see

4. Deferred before-image logging

A complicated optimization that lets us log less data than "other" database engines.

In simple terms, the Version Store is where transactions are held in memory until they can be written to disk.  If something is preventing us from completing transaction or writing to disk we will consume this cache and the store will stop responding to request until there is room in the cache again.

Event 623 is the result, typically, of a long running transaction. The result of this long running transaction is to exhaust resources in the version store. As a result, the Version Store no longer reaps deleted records causing unneeded data, which is marked as deleted, to accumulate in the database. The accumulation of unneeded data can exacerbate performance problems which can lead to event id 623. No more transaction can continue until this is clear. This error is NOT the result of the system running out of memory. If we failed to allocate more memory and NT refuses to give it to us we will fail with a different error. Increasing the RAM in the server will NOT fix this problem. Also, there's no relationship between write-back caching and the Version Store. Enabling or disabling write-back caching has no effect on the Version Store whatsoever.

The events 623, 1022, 1097 are a result of Version Store entries not getting cleaned up, either not at all or not in a timely enough fashion. This can happen for one of two reasons.

First, in order to properly reconcile write-conflicts and properly support repeatable reads, a given entry in the Version Store cannot be cleaned up until it is older than the oldest active transaction. This means that if the store opened a transaction and kept it open indefinitely (perhaps for some long-running operation such as grovelling the entire database for whatever unknown reason) or otherwise orphaned the transaction, Version Store cleanup would be precluded due to this active transaction and it would therefore continue to build in size until you reached the maximum.

The second reason Version Store entries might not be getting cleaned up is that version cleanup simply can't keep up with the load on the machine. The cleanup of Version Store entries is performed by an asynchronous background thread. As transactions commit or roll back, this asynchronous background thread will clean up the Version Store entries that are older than the oldest of the remaining active transactions. However, if there is so much write activity going on that it outpaces this cleanup thread, well, then you're going to get into a state where the Version Store continues to build up in size, but the version cleanup thread can't keep up with cleaning out old entries, so eventually you'll reach the maximum Version Store size. Of the two reasons why the Version Store can't be cleaned up, it's almost always caused by a long-transaction as opposed to the Version Store cleanup thread not being able to keep up with the load on the machine.

The size of the Version Store is determined by the msExchESEParamMaxVerPages on the "Storage Group" object in Active Directory. This setting is in units of 16K. If the attribute is not set, the default is 9280 in decimal.  The attribute can be increased to 10280 and then 11280 to avoid this situation.  This will result in less memory available for other function in the store and could result in other performance issues.

What happens when the Version Store reaches its maximum?

Well, for one thing, you'll see the 623 event indicating that the maximum Version Store size has been reached. Write operations to the database will start failing with -1069 (JET_errVersionStoreOutOfMemory) because there's no more Version Store space in which to record the operation. Additionally, you will start seeing the 602 events when the Version Store size starts approaching the maximum (you should actually see the 602 events even before the 623 event). What this event means is that any expensive cleanup operations will be skipped in an effort to get the asynchronous background Version Store cleanup thread to run as fast as possible. Every 100 operations that are skipped will cause us to generate the 602 event. If you're seeing tons of the 602 events right after a 623 event, then what is likely happening is that hitting the -1069 (version-store-out-of-memory) conditions has caused the long-running transaction to rollback. Since this transaction is no longer present to hold back version cleanup, version cleanup now proceeds to try to clean all the entries in the Version Store, which is now huge. Because it's so large, we will skip all expensive cleanup operations until the size is reduced. Because we skip so many operations, this leads you to see the spam of 602 events.

As for why the 602 event is generated even though online defrag has been scheduled for later on, that's because Jet has no knowledge of online defrag scheduling. The scheduling is done by the Store.

The key question to answer is whether 623 is the result of regular 602. Have you tried widening the on-line defragmentation window as the event indicates? Are the server's affected very heavily loaded, relative to their hardware when compared to servers that are unaffected? It is possible that regular 602 messages indicating that on-line compaction is not running to completion can results in indexes that are so inefficient, that transactions take longer and longer. The result would be the 623 seen here which makes the problem of inefficient queries even worse. Lastly, in such cases, off-line defragmentation will dramatically improve the database efficiency such that event 623 will not occur for some time, but then later occur after the database has become relatively defragmented because on-line defragmentation has not been able to complete. Try to take steps to ensure that on-line defragmentation is completing.

Increasing the Version Store size may not necessarily be the correct solution here. It's probably better to try to debug the problem and figure out why the Version Store got so big in the first place. The 623 event reports the Jet session holding the oldest transaction (and the thread it was on) at the time the version-store-out-of-memory condition was hit. Ideally, you'd want to set a breakpoint at the place in Jet that returns JET_errVersionStoreOutOfMemory and then use the information in the 623 event to identify the thread holding the long-running transaction and then debug what the Store is doing in that transaction that's taking so long.

Troubleshooting this event

There are lots of different reasons that can cause event id 623; database corruption, huge messages, at times third party software integration, to name a few.

I would start by doing the following:

1. Use Microsoft Operations Manager to monitor for 623 events.

Knowing your limits

Recently MSIT wanted to make some global changes to the retention time of public folders. In the past we had a global limit of 3 years retention on items in public folders. The plan was to change the default limit to 1 year, and then exempt folders as needed.

But there were a couple of complications...

After examining the public folder tree and gathering feedback from the user base, we found that about 30% of the public folder tree would need an exemption for one reason or another. About 100,000 folders give or take a sub tree. Worse, the folders to be exempted where "sprinkled" throughout the tree in no real pattern.

Secondly, in Exchange 2003, public folder age limits are enforced thru 3 mechanisms, per replica properties, database limits, and per folder properties. Database properties and folder properties could be accessed thru a variety of mechanisms (DAV, LDAP, and Exchange System Manager) but replica properties are accessible only thru ESM.

Due to the number of public folders that needed to be exempted, and problems around manually keeping each folder replica in sync, using Exchange System Manager to set per replica limits wasn't going to work. Since database policies had higher precedence then per folder limits, we decided that we would have to set all folders at the folder level and then turn off database and replica limits (fortunately, only a few folders had replica limits.)

In order to get the data we needed, we first used PFDAVAdmin to extract information about the tree. We needed the display name, folder path, folder size, item count, the PR_OVERALL_AGE property (this is the per folder age limit property), and the PERMANENTURL (mapi prop:0x670e001f)

Exchange 2003 SP2 introduced a number of cool new features, one of which is a wizard for doing large scale modifications of public folders. Since the folders where scattered all around, we couldn't use this tool to set the age limits on the folders. PFDavAdmin doesn't support importing modifications of these types of properties so it was out too. Time to write some code! Fortunately, there are lots of examples of how to do this; MSDN has a good one here.

Basically we need to do a DAV propatch something like this on each folder:

            queryBuilder = new StringBuilder();

            queryBuilder.Append(@"<?xml version=""1.0""?>");

            queryBuilder.Append(@"<b:propertyupdate xmlns:a=""http://schemas.microsoft.com/mapi/proptag/"" xmlns:b=""DAV:"" xmlns:z=""urn:schemas-microsoft-com:datatypes"">");

            queryBuilder.Append(@"<b:set>");

            queryBuilder.Append(@"<b:prop>");

            queryBuilder.Append(@"<a:0x66990003 z:dt='int'>" + Int32.Parse(ageLimit) + @"</a:0x66990003>");

            queryBuilder.Append(@"</b:prop>");

            queryBuilder.Append(@"</b:set>");

            queryBuilder.Append(@"</b:propertyupdate>");

We still needed to have a way to identify each folder. Since users can modify display names, move folders, and include symbols which maybe hard to code into a URL, we need a better URL naming mechanism. Fortunately, this already exsisted, the permenateurl property we had gathered ealier. Basically, each public folder in Exchange can be identified by a URL that looks something like the following:

http://myPublicFolderServer/ExAdmin/Admin/<FQDN>/public%20folders/-FlatUrlSpace-/f85c74f57f7280469fa523b239cea3e3-1e834051

We now have all the information we need to set the folder age limits, the desired age limit, the url of the folder, and a tool to stamp each one. Any public folder server will work, since the age limit is a property on a folder, and all public folder servers have a copy of the folder hiearchy. We're ready to go.

The final step was to batch the folders into smaller groups. Making large scale changes to public folder properties can result in mail replication storms as each PF server sends out and recieves change notifications. We needed to ensure that our changes where small enough that we didn't cause any problems. After a little testing in our lab, and carefully monitoring the impact on our infrastrucutre, we found the magic number (which will vary from deployment to deployment, you'll have to do this on your own) and a week or two later had removed all the stale unwanted data from our environment.

- Ted Kolvoord

How do you know which mailboxes are registered with the Auto Accept Agent?

This is my 4^th blog post on the subject of Exchange 2003 Auto Accept Agent. If you want to see previous posts, you can see them here: one, two and three.

The listings of Mailboxes that are registered on any given server are currently homed in the SystemMailbox. These registrations are populated by running the RegisterMailbox.vbs script and are listed as GUID items under the StoreEvents/Internal folder of the SystemMailbox as mentioned earlier. The inbox of the resource mailbox permanently contains an item "OnSaveForAutoAcceptAgent" (Subject, no sender) that is hidden. It is very important that one should not alter this in any way. If it is altered, the Sink will fail. If this message isn't hidden on the mailbox but is listed under the Root in Outlook the Sink will fail. This is probably due to a permissions issue.

There are 2 utilities that will allow you to open a resource mailbox and view properties of items in the mailbox including the GUID.

1. MFCMAPI
2. Exchange Explorer

Exchange Explorer can be obtained from the Exchange SDK that will allow you to open a mailbox and view properties of items in the mailbox including GUIDs. More information regarding this application can be found at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/wsst_web_storage_system_schema_designer.asp

The Exchange SDK can be downloaded from

http://www.microsoft.com/downloads/details.aspx?FamilyId=4AFE3504-C209-4A73-AC5D-FF2A4A3B48B7&displaylang=en

MFCMAPI can be obtained from http://support.microsoft.com/?kbid=291794

Here are the steps to use MFCMAPI to check the store event on the inbox folder of the resource mailbox.

Ensure that the user performing this process has "Receive As" rights on the Mailbox Store where the SystemMailbox resides. Follow article 821897 for more information on how to do this.

1. Copy MFCMapi to the client machine that has Outlook running.
2. Create an Outlook profile for the registered resource mailbox.  Make sure that you have "Prompt for a profile to be used" option check.
3. Start the MFCMapi and click OK on the About MFCMapi window.
4. On the MFCMapi window, click on Session menu and select Logon and Display Store Table.
5. Select the Outlook profile that you just created.  This will open the mailbox table and the public folder.
6. Highlight mailbox and click MDB > Open Store.  This will open the mailbox store.
7. Expand Root Container > Top of Information Store.
8. Highlight the Inbox folder and click Actions | Open Associated Contents Table.
9. From the top pane, look under the Subject column.  You should have "OnSaveForAutoAcceptAgent".  If you don't see this hidden message, that means the mailbox did not get register with the Auto Accept Agent.
10. Highlight the OnSaveForAutoAcceptAgent and click Actions > Save Message(s) To File. This will save all the properties of the message into text format.
11. Select OK and choose the location to save the text file.  

Below is a screenshot of the "OnSaveForAutoAcceptAgent" hidden message as seen with MFCMAPI.

In order to view the GUIDs within the SystemMailbox, follow steps 1-7 and navigate to StoreEvents > internal folder. Double click the internal folder to view the GUIDs of the registered mailboxes. To log into the SystemMailbox mailbox, have a look at article 253784 for the steps. As another method MFCMAPI can be used to logon to the SystemMailbox without creating an explicit profile. Log into the SystemMailbox only as a measure of troubleshooting.

Hope this was helpful!

- Nagesh Mahadev

Demystifying Exchange Server 2003 SP2 IMF Updates

Hi All,

I thought I would introduce myself to the BLOG-O-Sphere, my name is Scott Roberts and I'm a Software Developer in Test for the Exchange Sustained Engineering team. One of my responsibilities on the Exchange team includes being part of a team that pushes out the update for Intelligent Message Filtering (IMF) via Microsoft Update (MU). This BLOG will cover a few of the areas that we seem to find customers having problems with when trying to get the latest IMF update via MU.

By now, I hope all of you know that new Intelligent Message Filter (IMF) is out in the wild with the release Exchange Server 2003 Service Pack 2 and have moved off of the older version. What you might not be aware of is that Exchange pushes an update twice a month to the Microsoft Update infrastructure to deliver the latest IMF files to your server and this is explained in

http://support.microsoft.com/?kbid=907747. The below will give additional information and troubleshooting steps to make using the IMF update functionality easier and troubleshooting issues less costly. Additionally, you should check our previous post on this subject too.

Microsoft Update/Windows Update

An IMF Update is the same as any other Exchange Update and therefore will use the 'Microsoft Update' pipe instead of the 'Windows Update' pipe to deliver the update to the customer. Every computer by default uses 'Windows Update' when first installed and can be reached by START > PROGRAM FILES and selecting the 'Windows Update' shortcut.

For additional information, I would recommend reading the FAQ on Microsoft Update.

In order to use Microsoft Update (MU), the computer must 'opt-in' via a website and from that point on the machine will use MU for detecting if it needs updates instead of Windows Update (WU). KB901037 explains 'How to enable and to disable Microsoft Update'. It isn't that difficult to do and only takes a minute.

Detection Logic

First off, I think it will be important to explain how detection does happen. There are several checks that happen before the update will be downloaded to the machine and installed. The Automatic Update (AU) Service (Description of the Automatic Updates feature in Windows) is responsible for the scan on the local machine and based on its configuration (How to schedule automatic updates in...) will decide how to handle the update. Remember that there is an ActiveX control that needs to be installed and that there is also a possibility that the machine needs an update for 'Windows Update'.

The detection that happens during the AU scan that does happen is as follows:

1. Is one of the Exchange Product installed on the machine?
2. Is Exchange Server 2003 installed on the machine?
3. Is Exchange Server 2003 Service Pack 2 installed on the machine?
4. Is the IMF 'ContentFilterState' registry a DWORD and a value of 1?
5. Is this particular IMF Update already installed onto the machine?

At this point, the 'AU' then does what is configured to do on the local machine:

1. The update is automatically installed (AU Scheduled)  and uses the 'localsystem' account for the installation of the update
2. The update is downloaded and the local user is prompted to install. The update is installed using the credentials of the local user.
3. The update is not download but the local user is prompted to download and install. The update is installed using the credentials of the local user.
4. If the scan is initiated by going to http://update.microsoft.com/microsoftupdate/v6/ then it is up for the user to decide. The update is installed using the credentials of the local user.

Enabling IMF Filter Updates

To enable Intelligent Message Filter updates, you must create the ContentFilterState registry entry. http://support.microsoft.com/?kbid=907747 explains this some detail. To do this, follow these steps:

Customer Headaches

A few requests from customers have been in the area of creating a tool that does the scan at a schedule time and not install every other update that is also being offered. If the local machine is configured to auto-install updates at a specific time then all updates being offered that are of 'high-priority' will also be installed based on the 'AU settings' regardless if the IMF is offered or not. I created a small vbscript tool to show how someone can use the 'WU API' to write a custom tool so that the customer has some flexibility on how to install the IMF Update. The script will detect or download just the IMF Update based on the parameter passed in at run time. If there is no IMF update detected as needing to be installed then the script exits until the next time it is run.

The script follows; please save it into a file called blogIMFV1.vbs, for example. Also please note that seeing that the blog post contains some Unicode characters, in order to view them properly, please set your browser Encoding to "Unicode (UTF-8)" (in IE, go to View > Encoding and then refresh the page after chaning the encoding to Unicode):

Option Explicit
'//---------------------------------------------------------------------
'//This is a sample script, not officially supported by Microsoft.
'//---------------------------------------------------------------------

Exchange 12 preview Webcast series continues...

If you are following Eileen's blog - you already know about this, but for you that don't... A few more Exchange 12 WebCasts are coming up. Mark your calendars! Here are the subjects:

TechNet Webcast: Improvements to Calendaring in Exchange "12" (Level 300)
Tuesday, April 18, 2006
11:30 A.M.-12:30 P.M. Pacific Time

TechNet Webcast: Exchange "12" Management Shell and Scripting (Level 300)
Thursday, April 20, 2006
11:30 A.M.-12:30 P.M. Pacific Time

TechNet Webcast: The Improved Exchange System Manager for Exchange "12" (Level 300)
Tuesday, April 25, 2006
11:30 A.M.-12:30 P.M. Pacific Time

TechNet Webcast: Recipient Management and Permissions in Exchange "12" (Level 300)
Tuesday, May 2, 2006
11:30 A.M.-12:30 P.M. Pacific Time

To keep up with what might come up on the subject, please go to this page. The same page has links to past (recorded) Exchange 12 WebCasts which you can view on demand.

- Nino Bilic

Exchange 12 Server Roles and Disk IO

Introduction

This is the first of a four part Web log where I will focus on the different server roles in Exchange 12 and their disk I/O characteristics. Over the next few months I'll be addressing other Exchange 12 storage concerns in three upcoming Web logs:

• Exchange 12 High Availability Storage Considerations
  • This focuses on Exchange 12 features that increase availability, and hardware strategies you can use to increase fault tolerance.
• Exchange 12 Data Protection
  • This focuses on the features and strategies you can use to backup and restore your Exchange 12 data.
• Exchange 12 Storage Planning, Configuration, and Validation
  • This will build upon the three prior Web logs and tie everything together to outline our recommendations on how the storage solution should be configured, validated, and monitored.  

As with all server applications, Exchange 12 servers need to be properly deployed with sufficient, storage capacity and performance. The server roles in Exchange 12; Hub Transport Servers and Edge Transport Servers (collectively referred to in this blog entry as Transport servers), Client Access Servers, Unified Messaging Servers, and Mailbox Servers have different storage requirements and different backup and restore requirements, in part because they carry out different functions:

• Hub and Edge Transport is the server role that delivers mail in and out of the organization, mail in and out of Mailbox Servers, and voice mail messages submitted by Unified Messaging servers.
• Client Access Server is the client protocol server for Exchange, providing Outlook Web Access, Exchange ActiveSync, Outlook Anywhere (formerly known as RPC over HTTP), and other Internet protocols.
• Unified Messaging Servers provide Outlook Voice Access, as well as incoming FAX support.
• Mailbox servers, the heart of Exchange Server, are where user mailboxes and public folders are stored.
• Mailbox clustering or Single Copy Cluster (SCC) uses the Windows Cluster service in a shared disk active/passive configuration.
• Continuous Replication replicates log files to an alternate location which can be on a standalone server using Local Continuous Replication (LCR), or in a cluster that does not use shared storage using Clustered Continuous Replication (CCR).

Mailbox Server

The Exchange 12 Mailbox Server role is the core server role upon which all other server roles build. Once you determine your mailbox profile, which includes user I/O per second and capacity, you can begin to plan your deployment. How many users you place on an Exchange Server is usually a mixture of preventing a hardware bottleneck and the ability to backup and restore that data within your Service Level Agreement (SLA).

There are three storage requirements that must be balanced to achieve a successful Exchange 12 deployment. The first is the transactional I/O, or the performance measured in latency for each I/O to be satisfied by the storage. The second is the backup and restore throughput, or how quickly your data can be moved to and from your backup medium. The third is capacity, or ensuring you have enough space in the chosen RAID configuration for your production LUNs, and on the target backup medium.

In Optimizing Storage for Exchange Server 2003, we outline how to size your disk I/O requirements using mailbox profiling. For example, say you want to place 3000 users on a server with a .4 IOPS profile with 2GB mailboxes. Your performance requirement would be 1200 I/Os per second (IOPS). You would have to ensure that you could backup and restore 6 terabytes of information. If your backup SLA is 4 hours, you would have to backup 1.5TB of data in an hour or 417MB a second. If your backup solution could only backup 300MB a second, you'd have to reduce the mailbox size or the number of users by 28%.

In Exchange 2000 Server, the best practice, which was influenced by virtual memory limitations, was to fill out a storage group with 5 databases before creating another storage group. In Exchange Server 2003, those limitations were considerably reduced, and the best practice is to add an additional storage group for each new database until the maximum number of storage groups has been created. With Exchange 12, the I/O footprint is reduced due to enhancements to JET, the underlying database engine used by Exchange.

Core JET Enhancements

Exchange 12 reduces the overall I/O footprint for Exchange because of several key design changes in JET:

-      A 64-bit operating system and a 64-bit Exchange Server enable a much larger database cache, increasing from 900 MB to potentially dozens of gigabytes, depending on the total system memory.

-      Database read operations also benefit from many new cache optimizations. I/O coalescing increase from 64 KB to 1 MB further reduces disk I/O by increasing the opportunity to read and write larger I/O.

-      There is no streaming databases (STM) file and the ExIFS has been removed.

-      In Enterprise edition up to 50 databases in up to 50 storage groups can be utilized on a single server.

As a 64-bit application, Exchange 12 does not have the virtual memory limitations of its 32-bit predecessors. Exchange 12 supports up to 50 databases and up to 50 storage groups, but you cannot place more than 5 databases in a storage group. Each storage group creates its own separate transaction log and is the basic unit for backup and restore. The maximum amount of data that JET can write to the transaction log before it writes it to the database is a cache called the checkpoint depth. Using 1 database in a storage group allocates the entire checkpoint depth to that database, increasing the likelihood that multiple updates to a database page will be done in cache, and only the last update will be written to the database, thereby reducing I/O.

Exchange Mailbox Data Components

Backup

Backing up mailboxes requires careful planning and below I outline some considerations for Volume Shadow Copy Service (VSS) and streaming online backups. There are trade-offs in every solution that impact variables such as cost, time, and reliability. Most administrators define a window for online database maintenance and defragmentation, and scheduled operating system maintenance. This competes with the backup window and special care is needed to balance backup, maintenance, and production load. Larger mailboxes may make a daily full backup strategy impossible to complete within your SLA. A common strategy to lessen the pain of a full nightly backup is to perform weekly full and daily differentials. With this strategy, you need to recover the full backup, and then recover the last differential backup.

Volume Shadow Copy Service (VSS)

The article entitled Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 details VSS fundamentals and Exchange 2003 best practices, and I recommend that you read it (and not just because I wrote it). In addition to everything covered in that article, there are two major VSS-related considerations in Exchange 12 that I want to focus on; larger mailboxes, and the ability to backup a CCR & LCR replica. While VSS backups can be made on either the production or replica data, we recommended that you backup the replica and avoid an impact to the production physical disks. 

With LCR, Exchange 12 is replicating Exchange data to a separate disk on the same server. When using VSS clones on the replica, the replica storage should be configured on different physical disks so that the clone operation and checksum integrity do not impact the production physical disks. With VSS snapshots on the replica, the replica storage should be configured on different physical disks so that the checksum integrity and subsequent streaming to tape won't impact your production physical disks.

With CCR, Exchange 12 is replicating Exchange data to a separate server. This server is a node in the cluster, but the target replica is not shared storage. When using VSS clones, you are able to run the checksum integrity on the replicated copy on the passive node using different physical disks thereby isolating the backup process. With VSS snapshots, the checksum integrity and subsequent streaming to tape won't impact your production server or physical disks.

Streaming Online Backup

Unlike VSS, where the data is typically moved within the storage appliance, when using streaming backups, the server is responsible for moving your data. You don't have to worry about the performance impact of the checksum integrity process because every page is checked during the backup. Whereas VSS can only backup one storage group at a time, a streaming backup can backup multiple storage groups concurrently. These multiple streams can stress the limits of your backup media, whether it is gigabit Ethernet or fiber channel attached tape. For many customers, the backup SLA window, divided by the throughput-per-minute of their streaming backup medium, limit the permissible size of the storage group. For example; if you had a 1-hour SLA on your storage group, and can backup 100MB/sec, your maximum storage group size would be 360GB.

Client Access Server (CAS)

The Client Access Server offloads many stateless tasks from the Mailbox server (assuming the roles are installed on different physical servers), and provides a unified namespace where your users need only point to a single name regardless of which Mailbox server they are on. Internet protocols such as IMAP4, POP3, and HTTP (OWA) are serviced by the Client Access Server. Outlook Anywhere (formerly known as RPC over HTTP), ActiveSync, Autodiscovery and Web Services are other examples of features serviced by the Client Access Server.

The Client Access Server can be bottlenecked by CPU, memory, and network, yet it has a very small disk I/O footprint. SMTP traffic, a potential disk I/O consideration in an Exchange 200x front-end server, is now owned exclusively by the Hub Transport and Edge Transport servers.

Transport Servers

The Hub Transport and Edge Transport servers are the bridgehead and gateway for Exchange 12. Their primary mission is to send and receive mail. Many businesses will deploy a transport server into two groups; message hygiene (Edge Transport Server) and routing (Hub Transport Server).  The Edge Transport Server's primary responsibility is to protect the Exchange infrastructure from incoming mail containing spam or viruses. The Hub Transport server will then categorize the clean mail, and deliver it to the proper Mailbox server. The storage impact to these servers will fluctuate depending on the number of messages handled per second, and the average size of those messages. 

Summary

I hope this helped you identify how disk I/O impacts Exchange 12 based on the server roles. I am looking forward to adding more content with my next blog, where I will focus on Exchange 12 high availability storage considerations.

More Information

VSS Supportability KB: 822896

- Robert Quimbey

Are you ready for Exchange 12?

Be the first to know about upcoming Microsoft Betas!  Register to receive updates on the Exchange "12" public beta via a customized Microsoft TechNet Flash Newsletter!  Find out more here: http://www.microsoft.com/technet/prodtechnol/beta/preregister.mspx.

- The Exchange Team