You Had Me At EHLO...

Free swag to Exchange user groups

2006-05-08T20:13:00Z

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

2006-05-05T23:25:00Z

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?

2006-05-01T19:58:00Z

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

2006-04-28T19:19:00Z

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!

2006-04-25T21:08:00Z

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!

2006-04-24T21:17:00Z

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?

2006-04-21T22:23:00Z

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)

Extract all the DLs of the mailboxes you intend to migrate
Export the directory Information from the source Exchange 5.5 server in Site S
Delete the source mailboxes in Site S
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.
Do a directory import of the mailbox information in Site D to recreate the mailboxes.
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:

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)
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
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:

Extract all the DLs of the mailboxes you intend to migrate
Export the directory Information from the source 5.5 server in Site S
Delete the source mailboxes in Site S
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
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)
Do a directory import of the mailbox information in Site D to recreate the mailboxes
Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site.
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?

2006-04-21T18:18:00Z

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

2006-04-19T22:15:00Z

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.

2. Rule out Antivirus by possibly applying the registry modifications/tunes noted in the EXBPA report for the Antivirus. Use the Microsoft Exchange Server Best Practices Analyzer Tool to resolve any outstanding critical issues.

3. Confirm Integrity of JET and Information Store level.

a) Run ISINTEG -S Servername -FIX -TEST ALLTESTS as a priority

b) Confirm Jet integrity. This is accomplished through eseutil /g.

4. Try to track down a large message going through the store. A few articles that can help:

830762 Messages that are larger than global size limits can affect server performance

http://support.microsoft.com/default.aspx?scid=kb;EN-US;830762

Large Messages Affect Server Performance blog at http://blogs.msdn.com/jeremyk/archive/2004/02/29/81773.aspx

911836 E-mail client users experience a decrease in performance, and event 623 is logged when you receive a large message in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;911836

893599 You may experience slow client performance if the version store runs out of memory in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;893599

317722 Client latencies occur when Exchange 2000 Converts Mail from MAPI to MIME format

http://support.microsoft.com/default.aspx?scid=kb;EN-US;317722

5. Verify online maintenance is completing and its schedule is not conflicting with online backup times. Widen the online maintenance window during off-peak hours if the online maintenance is not completing.

6. Disk I\O performance issues can also be attributed to this issue. Disk I\O latency can account for a slow read transaction and may lead to event id 623 occurring. Use the Microsoft Exchange Server Performance Troubleshooting Analyzer Tool to analyze and fix any Exchange Server performance issues.

The best way to find the root cause of a 623 event id is to enable the " Show Advanced Counters" (aka "Squeaky Lobster" - though Squeaky Lobster is still supported for backward compatibility) & monitor Database > Version Buckets Allocated counter and take a dump once this counter hits 70%, the next time this event id occurs. Jet's "Version buckets allocated" counter will show up when you enable the "Show Advanced Counters" in the registry.

We can determine the cause of 623's if we have a userdump of the store process as the long running transaction is occurring. Unfortunately, this doesn't always catch the culprit because by the time the dump is grabbed, whichever session/thread owning the transaction that was causing the Version Store to build up may have error'd out and gone away. Normally these can be difficult to catch manually.

1. We need to set the "Show Advanced counters" registry key so we can view Jet's "Version buckets allocated" counter. This can be accomplished by setting the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESE\Performance
On the Edit menu, click Add Value, and then add the following registry value:
Value Name: Squeaky Lobster
Data Type: REG_DWORD
Value: 0x1

You will need to restart the perfmon service after setting the key to see the additional counters.

2. We are setting this key so we can set an alert for "Version Buckets Allocated", we have the following 623 event in the case:

Event Type: Error
Event Source: ESE
Event Category: Transaction Manager
Event ID: 623
Description: The version store for this instance (0) has reached its maximum size of y MB(For purpose of this blog I will use 155Mb). 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.

A version bucket is 64K in size in perfmon or the perfmon counter is in units of 64k in Exchange 2000/Exchange 2003. It is in 32k units on 64-bit Exchange 12 and 16k units on 32-bit Exchange12.

The calculation is as follows: x/1024 *64 = y, where x is the number of version buckets allocated and y is the total Version Store memory. Now, we know that the maximum Version Store memory (i.e. y) is 155Mb and we can therefore work out the maximum number of version buckets allocated. x= (155*1024)/64 so we can see that this is 2480.

When we see the version buckets allocated reaching 70% of this maximum then we can say in all probability that we are experiencing a long running transaction and can therefore start to take dumps accordingly. 70% * 2480 = 1736 buckets

3. Create a batch file (call it user.bat and place it in the root of C: drive), with the following information:

adplus -quiet -hang -pn store.exe x:\store.dmp (where x is the drive. Note: make the path where you have enough free space)
del c:\user.bat

I have it delete the user.bat so we don't continually dump the store.

For more information on ADPlus, please review the below article:

How to use ADPlus to troubleshoot "hangs" and "crashes"

http://support.microsoft.com/default.aspx?scid=kb;en-us;286350

4. We need a perfmon alert that will trigger our batch file to dump the store:

a. Open Perfmon
b. Under "Performance Logs and Alerts", right click Alerts and select "New Alert Settings".
c. Give it any name, like Version Buckets or 623. Click OK.
d. Click Add; Select the "Database" as the Performance object, then under Counters select "Version Buckets Allocated". Make sure that only Information Store is selected under instances. Select Add and then close.
e. Then set Alert when the value is "Over" the "Limit" to the value calculated above 1736.
f. Set the interval to 120 Seconds.
g. Go to the Action tab, check "Log an Entry in the application Event log", also check "Run this program" and browse to the batch file which will dump the information store.
h. You may want to configure an alert that will notify you when the Alert is triggered.

Send in the dump file, application log and performance monitor log that were running when the dump was collected to PSS for further analysis.

FYI, in Exchange 12, a new "health check" task has been added in the Store that runs once a minute by default and evaluates usage levels of various Jet resources, including Version Store buckets (the other resources are sessions, cursors, b-trees, and checkpoint depth). For any resources whose usage exceeds a certain threshold (65% by default), a new warning event is emitted. A lot of thought process is going into this to maybe provide an option to crash or otherwise generate a dump somehow if the threshold is exceeded.

Hope this information is useful.

- Nagesh Mahadev

Knowing your limits

2006-04-17T21:09:00Z

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.

Age Limit Enforcement	Precedent
Per Replica	1^st
Per Database	2^nd
Per Folder	3^rd

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?

2006-04-14T20:53:00Z

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.

MFCMAPI
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.

Copy MFCMapi to the client machine that has Outlook running.
Create an Outlook profile for the registered resource mailbox. Make sure that you have "Prompt for a profile to be used" option check.
Start the MFCMapi and click OK on the About MFCMapi window.
On the MFCMapi window, click on Session menu and select Logon and Display Store Table.
Select the Outlook profile that you just created. This will open the mailbox table and the public folder.
Highlight mailbox and click MDB > Open Store. This will open the mailbox store.
Expand Root Container > Top of Information Store.
Highlight the Inbox folder and click Actions | Open Associated Contents Table.
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.
Highlight the OnSaveForAutoAcceptAgent and click Actions > Save Message(s) To File. This will save all the properties of the message into text format.
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

2006-04-12T19:35:00Z

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.

What Is Microsoft Update?
It's the new website from Microsoft that helps you update Microsoft Windows and many other Microsoft programs that you've installed, such as Microsoft Office, Microsoft Exchange Server and Microsoft SQL Server, all in one convenient place.

Does it work with Automatic Updates?
Yes. If you turn on Automatic Updates using your settings in Control Panel, Windows will automatically find and install high-priority updates for any Microsoft products that you have installed and that are supported by the website.

If I use Microsoft Update, do I still need to visit the Windows Update website?
No. Microsoft Update provides the same updates you find on the Windows Update website and more. Microsoft Update is designed to make it easier for you to update Windows and your Microsoft products in one place.

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:

Is one of the Exchange Product installed on the machine?
Is Exchange Server 2003 installed on the machine?
Is Exchange Server 2003 Service Pack 2 installed on the machine?
Is the IMF 'ContentFilterState' registry a DWORD and a value of 1?
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:

The update is automatically installed (AU Scheduled) and uses the 'localsystem' account for the installation of the update
The update is downloaded and the local user is prompted to install. The update is installed using the credentials of the local user.
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.
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:

1.	Ensure that Exchange Server 2003 Service Pack 2 is installed on the machine
2.	Click Start, click Run, type regedit, and then click OK.
3.	Expand the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange
4.	In the left pane, click Exchange. Then, right-click in the right pane, point to New, and then click DWORD Value.
5.	Type ContentFilterState, and then press ENTER to name the new registry entry.
6.	Right-click ContentFilterState, and then click Modify.
7.	In the Data value box, type 1, and then click OK.
8.	Quit Registry Editor.
9.	In the Services snap-in, restart the Simple Mail Transfer Protocol (SMTP) service.

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.
'//---------------------------------------------------------------------

'Simple VBScript to show usage
'Forgetting to use cscript.exe could lead to annoying pop-ups when wscript.echo is called.
'Will run on any machine but only will do *stuff* on an Exchange server configured according to http://support.microsoft.com/?kbid=907747

On Error Resume Next

Dim error, i
Dim objUpdateSession, objUpdateSearcher, objSearchResult
Dim objupdateInfo, BundleUpdate
Dim objUpdatesToDownload, objUpdatesToInstall
Dim UpdateAction, bInstall, bDetect
Dim IUpdate
Dim downloader, installer
Dim installationResult

bInstall = false

if WScript.Arguments.Count = 1 Then

  UpdateAction = lcase(WScript.Arguments.Item(0))

  Select Case (UpdateAction)

     Case ("install")
       bInstall = vbTrue
   Case ("detect")
       bInstall = vbFalse
   Case Else
       Usage

  End Select

else
  Usage
end if

Set objUpdateSession = CreateObject("Microsoft.Update.Session")

if (err.number <> 0) then
msgEcho ("Microsoft.Update.Session is not present - have you connected to MicrosoftUpdates before?")
msgEcho ("Microsoft.Update.Session is not present - have you connected to http://update.microsoft.com/MicrosoftUpdate before?")
end if

Set objUpdatesToDownload = CreateObject("Microsoft.Update.UpdateColl")
Set objUpdatesToInstall = CreateObject("Microsoft.Update.UpdateColl")

msgEcho ( "Setting UpdateSession to Microsoft Update")
Set objUpdateSearcher = objUpdateSession.CreateupdateSearcher()

objUpdateSession.CreateupdateSearcher()

'By default, the scan will use what AU is configured to use. It could be WSUS or MU/WU.
'If you want to force the scan to use Microsoft Update and not what AU is configured to use simply uncomment the below lines

'objUpdateSearcher.ServiceID ="7971f918-a847-4430-9279-4a52d1efe18d"
'objUpdateSearcher.ServerSelection = 3
'objUpdateSearcher.Online = true

msgEcho ("Setting SearchResult and performing search")
Set objSearchResult = objUpdateSearcher.Search("CategoryIDs contains '3cf32f7c-d8ee-43f8-a0da-8b88a6f8af1a'") 'Exchange 2003 GUID

if (err.number <> 0) then
msgEcho ("Have you set the ContentFilterState DWORD registry value?")
msgEcho ("you connected to http://update.microsoft.com/MicrosoftUpdate?")
end if

msgEcho ("Search completed")
msgEcho ("Total Updates Returned:" & objSearchResult.Updates.Count)

'//
'// List current updates and status
'//

msgEcho ( "All Exchange Updates Status:")
msgEcho ("")

msgEcho ( VBTAB & "Is Installed: ")
For i = 0 to objSearchResult.Updates.Count-1

  if (objSearchResult.Updates.Item(i).isInstalled = true) then
   msgEcho ( VBTAB & VBTAB & objSearchResult.Updates.Item(i).title)
  end if

msgEcho ( VBTAB & "Not Installed: ")
For i = 0 to objSearchResult.Updates.Count-1

  if (objSearchResult.Updates.Item(i).isInstalled = false) then
   msgEcho ( VBTAB & VBTAB & objSearchResult.Updates.Item(i).title)
  end if

Next

'//
'// List only the IMF updates
'//

msgEcho ("")
msgEcho ("IMF Update Status:")
msgEcho ("")
msgEcho ( VBTAB & "Is Installed: ")
For i = 0 to objSearchResult.Updates.Count-1

if ( IsTitleOfUpdateIMFUpdate(objSearchResult.Updates.Item(i).title) ) then

   if (objSearchResult.Updates.Item(i).isInstalled = true) then
    msgEcho ( VBTAB & VBTAB & objSearchResult.Updates.Item(i).title)
   end if
  end if
Next

msgEcho ( VBTAB & "Not Installed: ")
For i = 0 to objSearchResult.Updates.Count-1

'This will only work for English
if ( IsTitleOfUpdateIMFUpdate(objSearchResult.Updates.Item(i).title) ) then

   if (objSearchResult.Updates.Item(i).isInstalled = false) then
    msgEcho ( VBTAB & VBTAB & objSearchResult.Updates.Item(i).title)

    if (bInstall) then
     msgEcho ( VBTAB & VBTAB & VBTAB & "Adding to the Download Queue")
     objUpdatesToDownload.Add(objSearchResult.Updates.Item(i))
    end if

   end if
  end if
Next

if Not (bInstall) then
msgEcho ("Exiting - detection only")
wscript.quit (0)
end if

if (objUpdatesToDownload.Count = 0) then
  msgEcho ("No 'Updates for Intelligent Message Filter' to download")
  wscript.quit (0)
end if

msgEcho ("Downloading updates...")
Set downloader = objUpdateSession.CreateUpdateDownloader()
downloader.Updates = objUpdatesToDownload
downloader.Download()

msgEcho ("Adding downloaded updates to the install list")
For i = 0 to objUpdatesToDownload.Count-1

  if (objUpdatesToDownload.Item(i).IsDownloaded = true) then
   objUpdatesToInstall.Add(objUpdatesToDownload.Item(i))
     end if

Next

if objUpdatesToInstall.Count = 0 then
  msgEcho ("No 'Updates for Intelligent Message Filter' to install - an error at this point")
  wscript.quit (-1)
end if


Set installer = objUpdateSession.CreateUpdateInstaller()

msgEcho ("Installing Updates...")

installer.Updates = objUpdatesToInstall

Set installationResult = installer.Install()

if (installationResult.ResultCode <> 2) then
msgEcho ("Installation Result: Bad Error (" & installationResult.ResultCode & ")")
else
msgEcho ("Installation Result: Succeeded")
end if

msgEcho ("Reboot Required: " & installationResult.RebootRequired)

msgEcho ("Exiting with Error 0x" & Hex(Err.Number) & " (" & Err.Description & ")")
WScript.Quit(Err.Number)

Function IsTitleOfUpdateIMFUpdate(StrTitle)

IsTitleOfUpdateIMFUpdate = vbFalse

if ( StrComp (objSearchResult.Updates.Item(i).title, "Update for Intelligent Message Filter for Exchange Server 2003:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Exchange Server 2003 Intelligent Message Filter 용 핫픽스:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Mise à jour pour Intelligent Message Filter pour Exchange Server 2003:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Update für Intelligent Message Filter für Exchange Server 2003:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Exchange Server 2003 Intelligent Message Filter 用更新プログラム(KB907747):") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Actualización para Intelligent Message Filter para Exchange Server 2003:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Aggiornamento per Intelligent Message Filter per Exchange Server 2003:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "更新 for Exchange Server 2003 Intelligent Message Filter:") > 0 ) OR _
   ( StrComp (objSearchResult.Updates.Item(i).title, "Exchange Server 2003 Intelligent Message Filter 的更新:") > 0 ) then IsTitleOfUpdateIMFUpdate = vbTrue

End Function

Sub msgEcho (strEcho)

WScript.Echo(NOW() & vbTab & strEcho)

End Sub

Sub Usage()
Wscript.Echo "Invalid Arguements"
Wscript.Echo vbTab & "Usage: imfUpdateScript.vbs ActionType"
Wscript.Echo vbTab & "ActionType - 'Detect' or 'Install'"
Wscript.Quit(-1)
End Sub

- Scott Roberts

Exchange 12 preview Webcast series continues...

2006-04-11T19:55:00Z

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

2006-04-07T19:09:00Z

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

Mailbox activities that impact disk I/O
Activity	How it impacts disk I/O
JET database (.edb file)	The Exchange 12 Mailbox Server stores all mail in a JET database. The JET database is randomly accessed and uses an 8 KB page size, though I/O coalescing can result in larger I/Os. For reliability, and in some cases performance reasons, the database should be on disks that do not contain transaction logs.
Transaction log files (.log files)	All changes made to the database are first committed to the transaction log, which is a sequential write to the disk. The writes vary in size from 512 bytes to the log buffer size.
Content indexing	There has been much development work to improve the search feature in Exchange 12. Content indexing is a random workload that should be placed on the same LUN as your database and will typically be about 5% of the database size. Since content indexing runs in the background indexing messages as they arrive, the disk I/O impact is minimal.
Paging	If a process requests a page in memory and the system cannot find the page at the requested location, a page fault occurs. If the page is elsewhere in memory, the fault is a soft page fault. If the page must be retrieved from disk, the fault is a hard page fault. Most processors can handle large numbers of soft page faults without consequence. However, hard page faults can cause significant delays. Continuous high rates of disk paging indicate a memory shortage.
Content Conversion	Most content conversion is done on the CAS and Hub Transport servers. Legacy WebDAV content conversion, for legacy Outlook Web Access clients, occurs on the Exchange 2003 Mailbox Server. When a client requests data that must be converted on a CAS server, the data is accessed from the Exchange 2003 Mailbox server, converted in the Mailbox server's TMP folder, and sent to the CAS server. To improve performance the TMP folder should not be on the same LUN as the page file and operating system.
Database Maintenance	The Exchange 12 information store requires periodic online maintenance to be run against each database. The two tasks that impact disk I/O are the hard deletion of messages and mailboxes that are older than the configured retention policy, and online defragmentation of the database. Since backup will halt online defragmentation, care must be taken to give both backup and database maintenance exclusive windows of time to complete their tasks.
Backup & Restore	The process of backing up data requires that data be read from your database and transaction log file volumes. This additional I/O can impact user response times and should be avoided during business hours. The process of soft recovery requires that JET play back all of the transaction log files. This causes the I/O profile to be a sequential read stream. As a result, the recovery performance improves if the transaction log files are on a disk with fast sequential disk access. Detailed Backup & Restore strategies will be outlined in the forthcoming blog, Exchange 12 Backup and Restore.

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.

CAS Server activities that impact disk I/O
Activity	Why it impacts disk I/O
Protocol Logging	Protocol logging is a sequential write that, if enabled, will be a performance hit and consume disk space to store the logs. When you keep a history of the protocol you choose to log, you can verify whether the protocol is performing its work as expected or is experiencing communications problems, and identify attacks from the Internet.
Content Conversion	Content conversion for all Exchange 12 protocols occurs on the Client Access server. When a client requests data that must be converted on a Client Access server, the data is accessed from the Mailbox server, converted in the Client Access server's TMP folder, and sent to the client. Legacy Outlook Web Access WebDAV clients have their content converted on the Exchange 2003 Mailbox server. To improve performance the TMP folder should not be on the same LUN as the paging file and operating system.
Paging	See Paging under Exchange Mailbox Data Components

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.

Edge & Hub Transport Server activities that impact disk I/O
Activity	Why it impacts disk I/O
JET database (mail.que file)	Both the Exchange 12 Edge Transport and & Hub Transport Server store all mail in a JET database. The JET database is randomly accessed and uses an 8 KB page size. For reliability, and in some cases performance reasons, the database should be on separate disks from the transaction logs.
Transaction log files (.log files)	All changes made to the database are first committed to the transaction log, which is a sequential write to the disk. The writes vary in size from 512 bytes to the log buffer size.
Protocol Logging & Message Tracking Logs	Message tracking and the protocol logging is a sequential write that if enabled, will be a disk performance hit and consume disk space to store the logs. When you keep a history of the protocol you choose to log, you can verify whether the protocol is performing its work as expected or is experiencing communications problems, and identify attacks from the Internet.
Content Conversion	On the Hub Transport server, incoming mail from the Internet is converted to MAPI prior to being delivered. This content conversion process occurs in the TMP folder. To improve performance, the TMP folder should not be on the same LUN as the paging file and the operating system.
Paging	If a process requests a page in memory and the system cannot find the page at the requested location, a page fault occurs. If the page is elsewhere in memory, the fault is a soft page fault. If the page must be retrieved from disk, the fault is a hard page fault. Most processors can handle large numbers of soft page faults without consequence. However, hard page faults can cause significant delays. Continuous high rates of disk paging indicate a memory shortage.
Agents	Customization of the Transport Server is done via code, known as agents, running in the CLR environment and triggered by an event. Some agents log data which will be a disk performance hit and consume disk space to store the logs.

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?

2006-04-07T19:06:00Z

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