Управление Search Folders в Exchange

Не все администраторы Exchange систем знают или часто используют Search Folders – Папки поиска в Outlook.

А уж управлять ими из Exchange – и подавно. Давайте разберемся что к чему.

Существует два общеизвестных способа фильтрации сообщений в MAPI – Search folders и собственно Фильтры – Restrictions.

Search folder похожа на обычную MAPI папку в ящике пользователя, за исключением того, что в ней не хранятся реальные сообщения, а только результаты отбора по параметрам писем из прочих папок ящика. Создается Папка поиска механизмом IMAPIFolder::CreateFolder по типу папки “FOLDER_SEARCH”, и с параметрами IMAPIContainer::SetSearchCriteria для указания условий (search criteria) и области поиска (search domain). Область поиска может лежать в произвольно выбранных папках и подпапках, благодаря поддержке рекурсивной работы.

Фильтры (restrictions) формируются вызовом IMAPITable::Restrict в системной Таблице MAPI. Таблица выборки показывает только отфильтрованные объекты, обозначенные в условиях отбора. Фильтры работают только в пределах выбранной папки ящика. Использование тех и других иногда может даже приводить к путанице, вызванной возможностью использовать правила отбора и в фильтрах и в папках поиска одновременно.

Далее, когда почтовом клиенте, (с возможностями поиска) устанавливается фильтр объектов MAPI таблицы (это называется VMSG – View Message Object), мы можем создать скрытую Папку поиска, которая отобрав нужный контент из оригинальной папки, перенаправит результаты в пользовательскую Папку поиска. Пользователи этого не знают, и увидят только результат – отобранные сообщения, и отсутствие прочих.

Процесс этот не быстрый, поскольку любой фильтр, даже в небольшой MAPI таблице (читай ящике пользователя) требует создания нового ряда папок и новую таблицу папок сообщений в Jet. А создание таблиц в Jet также выполнит транзакцию, и журнальную запись, поскольку это создание нового объекта. Интенсивное журналирование может привести к осложнениям производительности и событиям Event 623 (Version Store Out Of Memory). Подробно об этом типе событий можно прочесть здесь “Troubleshooting Version Store issues – JET_errVersionStoreOutOfMemory”, и дополнительно можно также ознакомиться со статьей “Version Store issues revisited – Event ID 623 at Information Store service startup”.

Теперь существует два типа Search folders (временные и постоянные). Создавая скрытую Search folder, вы используете “постоянный” тип, а пользователи, в последствии могут использовать ее в своих фильтрах. Папки поиска всетаки более стандартный инструмент. Эти папки поиска будут в одном ряду с прочими папками в таблице. И вместо таблицы сообщений будут таблицы поиска, с именами типа “S-1-1234”, где “S” означает Search, а последующий номер – FID (Folder ID) папки поиска.

Таблицы поиска будут содержать набор таблиц папок с сообщениями, в колонках. В идеале, это должно представляться как ряды ссылок на сообщения в папках, с несколькими колонками сортировки.

Папки поиска можно создавать различными почтовыми клиентами, такими как Outlook, или любыми другими, умеющими проводить поисковой запрос в локальном хранилище. Проблема возникает когда клиенты, в совокупности, создают огромное количество Папок поиска и никогда их не удаляют.

Тонны таких Search folders отрицательно влияют на производительность серверов Exchange. Каждый раз, когда сообщение создается, изменяется или удаляется – все связаные папки поиска обновляются в единой транзакции того же самого сообщения. И поскольку все папки поиска обновляются одной транзакцией, они будут заблокированны на время ее выполнения. А когда Exchange Server проводит пачку транзакций, он задействует механизм кеширования Version Store для успешного поддержания работоспособности (привет конкурентам, всяким там керио и сендмэйлам, которым такое и не снилось;).

Так что появляется возможность контролировать Search folders, держать “в пределах видимости” и устанавливать устаревание для неиспользуемых папок. Временное удаление папок поиска делается так: 

Временное удаление папок поиска

Если на сервере Exchange возникают проблемы производительности, в результате чрезмерного использования Search folders, их можно временно удалить. Во время стандартного периода обслуживания баз Exchange Server 2003 зачищает существующие папки поиска, и выставляет их ключи реестра на дефалтовые значения. В последствии Search folders продолжают нормально создаваться и использоваться в Exchange Server 2003.
В редакторе реестра перейдите в ветку
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeIS<Server
name>Public-<GUID>
Если операторы сброса не созданы – создайте их сами
Type: DWORD
Value: Reset
Data: 1
Значение “1” = по умолчанию,
“0” = очистить имеющиеся папки поиска во время следующего периода обслуживания.
Во время следующего maintenance period (обычно 02:00 или 2:00 A.M.) Exchange Server 2003 удалит существующие папки поиска и сбросит значение их персональных ключей в реестре на “0”.

Существует также инструмент FindSearchFolders, написанный Дэйвом Голдманом(MSFT), с помощью которой можно использовать isinteg.pri для поиска пользователей с очень большим количеством search folders. Инструмент называется FindSearchFolders
Примерно следующим образом будут выглядеть результаты работы тулы у вас:
Задача: Найти почтовые ящики, содержащие наибольшее количество Search folders.
Find Search Folders
Dave Goldman - Exchange Escalations Services
Purpose: Find the highest search folder offenders
Time: 05/14/08 18:04:58
1. Выбирается ящик с наибольшим значением Parent FID и по нему проводится поиск по isinteg.pri.
2. Смотреть в ESM, и сверять с найденным количеством, таким образом находятся наиболее ресурсоемкие ящики.
c:isinteg.pri закрывается.
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 <- Обратите внимание на огромное количество папок поиска
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
**********************************************************
Поиск указанных FID приводит к ящикам, имеющим наибольшее количество объектов в таблице.
Теперь можно смотреть в Exchange System Manager, для выявления количества объектов в ранее определенных ящиках, работа с которыми загружает сервер больше других.
[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
Теперь, если вы нашли ящики с наибольшим количеством объектов, как те что выше, можно сделать следущее:
1. Поместить isinteg.pri в корень диска С:
2. Запустить инструмент, он создаст текстовый файл, там же в корневой директории С:
4. Смотрите в конце созданного журнала FID с наибольшим количеством Папок поиска.
5. Затем открывайте isinteg.pri и ищите тот же самый FID, чтобы определить пользователя
6. Выбираете корневой Parent FID для найденного, это и будет указанием на конечный ящик.
... 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 ...
Удачной охоты!

Leave a Reply

Your email address will not be published.