((MXECHO))

It is rather common for people to experience problems after their mailbox has been moved between Exchange Servers. This is usually due to something else playing a part in the move, for example maybe Anti_Virus on the server has not been configured properly (http://support.microsoft.com/kb/823166 and http://www.msexchange.org/articles/Properly-Configure-file-system-antivirus-Exchange.html) or maybe something else is hooked into the mailbox when trying to move, 3rd party archiver or indexer…whatever. What can you do to help verify that your mailbox moves will go as planned? Well of course you can test on a small subset prior to your whole org, but you can also turn up diagnostic logging on the Exchange Server to get more information about the mailbox moves during the move, so should something go wrong you can go back and review.

In Exchange 2003 – Navigate in Exchange System Manager to the Exchange Server, right-click and choose Properties, open the Diagnostic Logging tab and choose MSExchangeIS\System\Move Mailbox – turn this up to Maximum. This will generate a lot of events in the application log on your server (so be mindful of space) but will also give you much more information about how the procedure went and if there were any errors in the process.

In Exchange 2007 you will use the Management Shell

set-eventloglevel –id “MSExchangeIS\9002 System\Move Mailbox” –level expert

and to turn it back down

set-eventloglevel –id “MSExchangeIS\9002 System\Move Mailbox” –level lowest

Hope this helps in troubleshooting Move Mailbox operations.

I ran across a situation the other day that I thought could use some additional explanation. In this case when users would open a Public Folder for the first time through Outlook the Outlook client would lock up or become unresponsive. If the user closed (end task) Outlook and went back into the same Public Folder then it opened quickly. If they waited (not ending task) then the Outlook client would “hang” for 40 seconds to 2 or 3 minutes – depending on how many items were in the Public Folder, but the folder would eventually open. The more items, the longer the wait time. As testing the Admin, created new profiles, and even restarted the computer several times to test. The issue ONLY occurs the first time they open the folder, after the first long pause, the folder opens fast each and every time. These clients were online clients. To clarify, this was for each folder in the Public Folder hierarchy. 

When we open a Public Folder in Outlook online mode the server creates the view for your client based on the view requested by the client. On most clients the view is standard, meaning they have not added any additional columns or modifications. In this standard scenario, the server has the general view already created as a table and can provide this view to the client quickly. However if your client is requesting a different view, then the server must create this view as a table in the store in order to present the view to the client. Once the view is created it is kept for a given amount of time (varies depending on Exchange version, but at least days) and is reused the next time it is requested. This is why the users would see the data quickly after the initial delay.

Do you have any control over these views or workarounds for the initial delay? There are two attributes on the public folder store that can control how many cached views are held and how long they are held for, msexchmaxcachedviews and msexchagingkeeptime. The biggest impact you can have on this initial delay is lowering the item count for the folders you are trying to access. The more items in the folder, the longer it will take to present the new view to your client. The other option you have is to reset your clients views back to default. You may  not even realize that you are using a view that is not common. The Outlook switch /cleanviews will reset your clients views back to default. This will NOT clear any views from the server, just the settings on the client.

This same type of behavior can be seen in mail folders as well, not just Public Folders. In fact many people may see this after a mailbox move as the views associated with the mailbox will needs to be recreated. Once the view is created, as long as it is accessed frequently enough the view will not be deleted from the server and the clients performance will remain quick. If the user goes on vacation….and doesn’t access their custom view for a given amount of time, then when they return they will also more than likely see some initial delays while those views are being created.

For additional information on this behavior see this TechNet article http://technet.microsoft.com/en-us/library/cc535025.aspx

Exchange 2007 mailbox databases have content indexing enabled by default. This is new to Exchange 2007. The search process and indexing process is much faster and much improved over previous versions. Several posts could be made regarding Exchange Search, however this post will just discuss how attachments can affect your indexing and search results.

Filters are used to extract the text from specific types of documents, html, doc, xml, xls, pdf, and so on. In the registry under HKLM\Software\Microsoft\Exchange\MSSearch\Filters there will be a list of filters that the server is able to use; see picture below.

Registry view of IFilters

Now here is what you need to understand, if a filter exists for a file type Exchange Search will attempt to index the attachment. If the server does not have a filter installed for a file type, Exchange Search will skip the attachment. Yeah OK, so that makes sense, but why is that important? Well if the Exchange Server has a filter installed for a file type that Exchange can not access, then the entire message will fail to get indexed. For example, lets say you have an xls file with DRM or is password protected, Exchange Search will not be able to read that attachment, and will not index the message either. Now let’s say that same example, but this time you DO NOT have an xls filter, then Exchange Search will NOT try to read the attachment and WILL index the message.

So, Message will fail to be indexed if Exchange fails to index an attachment that Exchange HAS a filter installed for.

Message will succeed indexing process if Exchange does NOT have a filter installed.

All of this only matters in situations where Exchange can not read the attachment. If a normal xls attachment is sent and can be opened and read normally then both the attachment and the email message will be indexed (as long as there is an xls IFilter). This all works great, the problem is where there are issues with the attachments.

There is one other interesting piece to this, in situations where the file type is not a true file type. For example, let’s say some random NON-Microsoft application spits out automated spreadsheet’s or documents and gives them an xls or .doc  file extension. This file was not created in Microsoft Excel so the attachment will not be read correctly, meaning again both the attachment and message will fail indexing. In the same sense that you can not rename a .pdf to .doc and expect Word to open it correctly, you can not expect an IFilter to be able to read a file type that was not truly created by that file types application.

When troubleshooting Exchange Search cases where you are seeing missing items in your search results, check the attachments can you find anything that sets them apart. If they were created by another application or process what are your options?

1. Open each attachment and resave with the appropriate application. Example: 3rd party app creates .xls files, they open with Excel fine but were not created with Excel – Indexing will fail to index this file. Open each attachment in Excel and re-save, they attachment and message should now be added to the content index catalog.

2. Remove the associated Filter. Example: delete the xls IFilter from the registry, Exchange will now skip attempting to read xls attachments and the actual message will now succeed, of course this means none of your xls attachments will be indexed.

3. Disable Content Indexing for the mailbox database in question. By disabling Content Indexing for this database you will force Exchange to use Store Search when clients query for items. Store Search does not index attachments and would not be affected by the behavior explained above. Store Search is much slower and has some limitations but it would work around your issue.

Side Note:Exchange 2007 does not have IFilters for Office 2007 by default you need to install these - http://support.microsoft.com/kb/944516

Recently I ran across a scenario where a company had migrated from Exchange 2003 to Exchange 2007 and noticed that their Search functionality was behaving differently. They, like most, used their email as a major component of their business. Work orders would come into their mailboxes and they would use Search to find and manage the flood of inbound emails. Each email would have a subject pattern that was somewhat predictable based on their work ordering numbering scheme. When they would search they would search for their portion of the code. This portion was not always the first portion of the string of characters. When using Exchange 2003 this worked great. Once they moved to Exchange 2007, they got inconsistent results. Why? Answer

Search in Exchange 2007 (Exchange Search) is completely different from earlier versions of Exchange. Improvements were made to performance, Content Indexing, and Search. New items are indexed almost immediately after their arrival into a mailbox giving end users a fast, reliable, and more stable search function. In Exchange 2000 and Exchange 2003, indexing was not enabled by default.

(note: there are other possible fixes to this error

I have a few posts coming on Exchange 2007 Search, but in the mean time I am posting a gathering of links from around the Microsoft Net. These links are a good beginning to understanding Exchange 2007 Search. If you are interested in Exchange 2007 Search and Content Indexing, this list should help you get familiarized.

How to Diagnose Exchange Search Issues - http://technet.microsoft.com/en-us/library/bb123701(EXCHG.80).aspx?track=cc_exchange_sync

How to Disable or Enable Exchange Search - http://technet.microsoft.com/en-us/library/aa996416.aspx

How to Rebuild the Full-Text Index Catalog - http://technet.microsoft.com/en-us/library/aa995966(EXCHG.80).aspx

Indexing Exchange Server 2007 Public Folders - http://blogs.msdn.com/enterprisesearch/archive/2008/06/06/indexing-exchange-server-2007-public-folders.aspx

Managing Exchange Search - http://technet.microsoft.com/en-us/library/aa998289.aspx

Understanding Client Throttling - http://technet.microsoft.com/en-us/library/cc540454.aspx

Understanding Exchange Search - http://technet.microsoft.com/en-us/library/bb232132(EXCHG.80).aspx

Exchange Search FAQ - http://www.exchangeninjas.com/ExchangeSearchFAQ

Exchange Server 2007 Cross Mailbox Search using Export-mailbox - http://msexchangeteam.com/archive/2006/12/18/431934.aspx

The new Search in Exchange Server 2007 - http://msexchangeteam.com/archive/2006/10/11/429163.aspx

944516 How to register Filter Pack IFilters with Exchange Server 2007 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;944516

945077 The Outlook Web Access search function does not work for some users in Exchange 2007 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;945077

When you look up another users Free Busy you may see ////// hash marks. Many Administrators know these hash marks, they can sometimes be frustrating. But, before immediately thinking you have a problem with Free Busy, it is important to know some, valid reasons for seeing these hash marks //////

For example, lets say there is a free busy message in the public folder but no meetings are scheduled in the calendar. You may see hash marks, not just a blank schedule when looking up the user. Below are the different mailbox/client scenarios and what they produce in this type of situation.

Free Busy message exists in Public Folder, but no meetings are scheduled during the clients publishing period (generally 2 months)

MB = Mailbox, CL = Client

MB Exchange 2003 with CL Outlook 2003 or 2007 = ////////////

MB Exchange 2007 with CL Outlook 2007 = <nothing>

MB Exchane 2007 with Outlook 2003 = /////////////

So you can see the only time we will actually see a blank calendar when there are no appointments or meetings scheduled in the users calendar is when we are using Outlook 2007 and Exchange 2007. Otherwise if the users calendar is blank for the entire publishing period we would see hash marks.

So, easy test. Next time you are fighting a ////// Free Busy battle, see if posting a meeting to the users calendar has any affect. Remember to give the entry time to publish and replicate if using multiple Public Folder Shed + Free Busy replicas.