Microsoft Exchange and Search Folders
The Exchange search folders tend to be a very complicated subject for a lot of administrators. There are two different ways of filtering messages in MAPI - (Search folders and restrictions).
- A search folder is like a regular MAPI folder, except that instead of containing real messages, it contains only links to messages in other folders which meet some specified restriction. A search folder is created by calling IMAPIFolder::CreateFolder with a folder type of FOLDER_SEARCH, followed by a call to IMAPIContainer::SetSearchCriteria to specify the search restriction and search domain. The search domain may be an arbitrary set of folders in the same store, and may be recursive, so that messages in any sub-folder of the specified domain folders are also searched.
- A “restriction” is formed by calling IMAPITable::Restrict on a MAPI Table. The resulting table shows only the items which match the restriction specified in the Restrict call. A restricted contents table can show only messages from a single folder. This usage sometimes causes confusion with the MAPI-defined structure which describes the filter criteria for a search folder, which we also call a restriction.
Now when a client (any application with search capabilities) sets up a restriction on a contents table object (which is known as a VMSG – View Message Object), we will create a hidden search folder which searches the original folder, and will point the VMSG at the search folder. Clients have no knowledge that this has occurred, and will only that some of the messages have disappeared from the table. This is not a fast process because even a restriction on a small table requires that we create a new folder row and a new message folder table in Jet. Creating tables via Jet will cause us to log transactions because we are creating objects. Excessive logging can lead to complications and 623’s (Version Store Out Of Memory). For more information on Version Store please see this blog: "Troubleshooting Version Store issues - JET_errVersionStoreOutOfMemory". In addition to that blog I also reviewed an article that we wrote and we blogged about it on the Exchange Blog site: "Version Store issues revisited - Event ID 623 at Information Store service startup".
Now there are two types of search folders (Temporary and Permanent) that can get created. When you create a hidden search folder this is actually a “permanent” part of the database, it can be reused later when someone performs the same restriction. Search folders are very much like regular folders. Each search folder has a single row in the folders table. Instead of a message folder table, there is a search table with a name like “S-1-4309”. The S denotes that this is a search folder and the following [1-4309] is the FID of the search folder.
Search tables will contain a subset of message folder tables that have columns. Ideally you want to have only a few columns and each row should be just a pointer to the “real” message in another folder.
Search folders can be created by a number of applications like Outlook, or any 3rd party application that issues searches for messages in an information store. The problem starts to manifest itself when a lot of search folders are created and never deleted by the application that creates them.
What is a Search Queue and how is it used in Exchange?
When Exchange has a larger search operation it will use the search queue. When a search event is issued against a search folder, we create a task and we enter that task into the databases search queue. The search queue is a Jet table and is a permanent part of the database. Each row in the search queue will represent a particular search event that was previously entered. For example “search folder ‘Inbox’ with respect to a search folder called ‘Dave’s Search Folder’, and create links for any messages which match”.
When a search folder is created, or other operations occur which cause a search to be modified, the appropriate search events are added to the search. Once the transaction has been committed, Exchange will then call a function to start the search task operation. This will process the search events listed in the databases search queue. This is done so if the information store is shut down or crashes before the search is complete, the search event will still be in the search queue. When Exchange starts up, it will also call a function to start searching for any search tasks events in the search queue.
When a restriction is started, the same search events are entered in the search queue as for a regular search folder. Rather than starting a separate background task to actually perform the search, restrictions process the search events immediately on the RPC thread before returning.
Having a ton of search folders will impact an exchange servers performance. When messages are created, modified, or deleted, all of the search folders linked will be updated immediately, within the same transaction as the original message operation. Since all search folders are updated in one big transaction, all search folders need to be locked before the transaction begins. When the exchange server starts to process batches of transactions it will begin to use up the stores Version Store cache to process these transactions.
There is a way that this can be controlled to a small extent and you can age out the views. For more information please see this article: How to Temporarily Delete Existing Search Folders.
I have also written a tool that will allow you to take an isinteg.pri file and search through it to look for users that have a very high amount of search folders.
Download Link: https://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=FindSearchFolders&ReleaseId=1456
Here is what the output looks like if you are search for a mailbox that has a high item count and high search folders. The action plan for finding the mailbox with the high search folder count is listed at the end of this output.
**********************************************************
Find Search Folders
Dave Goldman - Exchange Escalations Services
Purpose: Find the highest search folder offenders
Time: 05/14/08 18:04:58
**********************************************************
Isinteg is from server name: server.company.com
Folder FID=0001-000000DF1A28
Parent FID=0001-0000004F959B
Search Fids found: 1
Folder FID=0001-000000DF77E0
Parent FID=0001-000000DF88C8
Search Fids found: 12
Folder FID=0001-000000DF77E1
Parent FID=0001-000000DF88C8
Search Fids found: 222 <- Denotes that there are a lot of search folders :)
Highest number of search folders found: 222
Highest offender is: Folder FID=0001-000000DF77E1
Parent Folder: Parent FID=0001-000000DF88C8
Total folders that do not contain search folders: 3822
Who has the highest search folder count in an isinteg dump
**********************************************************
1. Take the highest offenders Parent FID and search the isinteg.pri file for this..
2. Look in the ESM and match these items counts and you should have your offending mailbox.
c:\isinteg.pri closed.
3. Searching for the following fid's takes me to objects that look like this with a massive amount of items in the inbox.
4. From here I can look in the ESM (Exchange System Manager) to match up the number of items and I have the user who keeps taking down the exchange server!
[2544] Folder FID=0001-000000DF77E1
Parent FID=0001-000000DF88C8
Root FID=0001-000000DF88C7
Folder Type=1
Msg Count=118,257
Msgs Unread=101,783
Msgs Submitted=0
Rcv Count=0
Subfolders=0
Name=Contacts
Comment=
Restriction=
Search FIDs=0001-000000E0EDB5,0001-000000E0EDB8,0001-000000E35105,0001-000000E35106,0001-000000E35109,0001-000000E3C29C,0001-000000E3C29D,0001-000000E3C29E,0001-000000E3C2A1,0001-000000E3C2A4,0001-000000E3C2CC,0001-000000E3C2CD,0001-000000E3E61A,0001-000000E3E61B,0001-000000E3E61C,0001-000000E3E62E,0001-000000E3E65D,0001-000000E3E693,0001-000000E40831,0001-000000E40832,0001-000000E40869
... Removed to save space ...
Scope FIDs(search folder only)=
Recursive FIDs=
Search Backlinks=0001-000000E0EDB5,0001-000000E0EDB8,0001-000000E35105,0001-000000E35106,0001-000000E35109,0001-000000E3C29C,0001-000000E3C29D,0001-000000E3C29E,0001-000000E3C2A1,0001-000000E3C2A4,0001-000000E3C2CC,0001-000000E3C2CD,0001-000000E3E61A,0001-000000E3E61B,0001-000000E3E61C,0001-000000E3E62E,0001-000000E3E65D,0001-000000E3E693,0001-000000E40831,0001-000000E40832,0001-000000E40869,0001-000000E40894,0001-000000E40895,0001-000000E40896,0001-000000E40897,0001-000000E41E88,0001-000000E41E89
... Removed to save space ...
If you are looking for a mailbox that has a massive amount of search folders like the one above you can do the following:
1. Put the isinteg.pri in the root of your c:\.
2. Run the tool. and this will create a text file in the root of your c:\.
4. Look at the bottom of the log file and find the fid that has the most search folders.
5. Then open the isinteg.pri file and search down for that fid until you cant go anymore, this will be your offender,
6. Get the root fid from that and search up from the bottom and that is your mailbox
Dave
