Управление 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_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<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:581. Выбирается ящик с наибольшим значением 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 ...
Удачной охоты!
Свежие комментарии