Как стать автором
Обновить

Комментарии 22

НЛО прилетело и опубликовало эту надпись здесь

Да, а потом этот PST благополучно теряется вместе со всей старой почтой при выходе из строя локального диска дектопа или утере ноутбука.

Если работать невозможно, то это скорее всего неправильно подобранные политики отправки данных в архив (когда еще «горячие» данные уже лежат в архиве) или когда экономят и архив хранят, к примеру, на ленте, тогда открытие одного письма занимает хорошо если минуты.

НЛО прилетело и опубликовало эту надпись здесь

Потому что бэкапить данные из единой точки немного удобнее, чем делать это на сотнях и тысячах рабочих станций. А если это ноутбук, который в случайные промежутки времени включен по питанию и подключен к какой-либо сети, то задача становится еще интереснее. Насчет скорости открытия писем вот не поленился, специально прокликал рандомные старые письма в Аутлуке - занимает доли секунды, хотя архивы лежат на какие-то недорогих VNX'ах с обычными SATAшными дисками.

НЛО прилетело и опубликовало эту надпись здесь

Во-первых, мегабит – это очень даже хорошо и хватает для открытия веб-страничек, что собой и представляет интерфейс поиска EV. Во-вторых, насколько у вас тяжелые письма, если через мегабит они долго открываются? А как тогда обычная почта загружается, в чем отличие?

Далее, есть VDI, есть Citrix, есть RDP наконец, вариантов удаленной работы масса.

Ну, и вишенка: Vault Cache – возможность держать зеркало архива у себя локально + при необходимости подключать по аналогии с PST. Но в отличие от PST потеря кэша никакие печальные последствия не создает.

Можно было начать и со штатных archive mailboxes.

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

Все это уже было - SIS для аттачей до Exchange 2010. Но в силу очевидных причин уже удалено.

У штатных archive mailboxes есть недостаток — цена: требуется клиентская лицензия Enterprise вместо Standard, Outlook, опять же, не в любой редакции с ними работать умеет, только в достаточно дорогой (для 2010, хорошо помню, требовался Professional, о чем были разбирательства с филиалами в некоем банке, где я тогда работал — там кое-кто на лицензиях экономить пытался).
Правда, это чудо техники, которое нам тут описывают — оно тоже, наверняка, не бесплатно и даже не дешево: все хотят поиметь с кровавого этенрпрайза много денег.
Все это уже было — SIS для аттачей до Exchange 2010. Но в силу очевидных причин уже удалено.

Мне вот эти причины до сих пор неочевидны: удаление харнения еднственной копии было сделано под предлогом того, чтобы увличить долю линейного чтения, чтобы можно было хранить базы на SATA-дисках с малым IOPS (семитысячниках, к примеру). Может быть, где-то так и делают, но я что-то не встречал таких: все у кого есть SAN, почему-то стремились под базы Exchange задействовать именно его, а не JBOD.
может использовать
НЛО прилетело и опубликовало эту надпись здесь

LVM или ZFS это для Linux, у нас Windows. Любой снепшотинг (аппаратный или софтверный) так же требует дисковых ресурсов, т.к. при долгом бэкапе снепшот будет расти. Да и тонкостей там своих предостаточно, особенно когда хочется их такого бэкап отдельные письма уметь восстанавливать. Техподдержке в ящики пользователей руками условно говоря лазить нельзя, а у пользователей есть свои дела и заставлять их что-то делать, особенно в многотысячной компании, так себе затея.

Бэкапы и так делаются незаметно для пользователя, со снимков томов, сделанных через VSS (софтовым или аппаратным, если есть, провайдером — VSS вполне умеет использовать аппаратный провайдер для SAN).

А обычная дедупликация WinServer разве не поможет? Я имею ввиду дедупликация на уровне fs.

Exchange не поддерживает дедупликацию средствами ОС, только СХД. Но любая база данных дедуплицируется плохо или просто никак. Как правило все блоки в базе уникальны за счет заголовка страницы, дедупликация блочная, а раз все блоки в итоге уникальны то..

Здесь вообще блочная дедупликация слабо применима, база реплицируется, еще и реплики тоже надо дедуплицировать.

Конечно у таких решений есть своя рыночная ниша. С одной стороны костылик, с другой стороны - OCR появился. Сделали систему сложнее, к траблшутингу прибавился еще один слой от другого вендора. Который будет добавлять седых волос на патчах Exchange сервера, Outlook и самого себя.

Можно добавить к предыдущему ответу на этот вопрос, что сама по себе технология OCR появилась уже 5 лет назад и сам по себе EV по нашему опыту является очень и очень стабильным продуктом, чего бывает не скажешь о других решениях.

Ну и в целом EV изначально умеет переводить в html сотни форматов файлов, и это одна из его фич. Мы же не знаем, сможет ли условный Office 2030 открыть документы, созданные в Office 2013, а вот текстовый html точно сможем.

Они не имели DLP, поэтому постоянно что-то искали вручную. А EV позволяет делать не только очень быстрые поиски, но и создавать постоянные поиски, которые похожи на папки с фильтрами. То есть один раз настроив фильтр по слову «откат» и синонимам, безопасники могли бы получать детальную информацию о тех весёлых людях, кто договаривается про такое через корпоративную почту. На самом деле их механизмы были куда сложнее, и Veritas был для них очень желанным.

DLP в Exchange сейчас есть встроенный, на уровне транспорта. Т.е это может быыть именно Prevention: неправильное (нарушающее политики) письмо может быть не только перенаправлено безопасникам но и заблокировано для отправки, или потребовать для отправки явно выраженного намерения отправить (с возможным уведомлением безопасников). Но красивых галочек для этого в ванильном Exchange, конечно, маловато.
Что касается поиска, то его можно создать один раз а потом скриптом повторять с нужной периодичностью. Причем, можно указать, что найденное ни в коем случае не должно быть удалено окончательно (InPlace Hold, аналог Litigation Hold, но только не целиком на п/я, а по критериям поиска), а должно храниться вечно или сколько-то дней (настраивается в параметрах запроса).
Дело в том, что если вы ставите себе DLP-пакет, то нужно включать журналирование ящиков, потому что пользователи вообще-то могут удалить компрометирующее их письмо.

Вообще-то — не нужно. Свежеполученные (хранящиеся в Корзине, т.е. папках внутри Recovery Items) письма можно защитить от окончательного удаления пользователем, включив Single Item Recovery: тогда при удалении пользователем из Корзины письмо не удаляется а перемещается в недоступную пользователю папку Корзины, где хранится полный срок. Плюс — упомянутый Inplace Hold (правда эта радость небесплатна — Enterprise CAL покупать надо) Ну, и Litigation Hold, на крайняк, есть -если он включен то письма в Корзине хранятся вечно. Правда, размер ящика…

Скрипты и костыли – это тоже вариант, но зачем, если есть журналируемый ящик, который можно полностью забирать в архив EV и который не займет дополнительного пространства за счет дедупликации (там те же пользовательские письма) и по которому можно потом осуществлять поиск. Если и этого мало, есть опции Advanced Supervision для анализа и поиска информации инспекторами от ИБ.

Затем, что EV — это лишняя сущность, стоящая дополнительных денег и требующая дополнительного обслуживания.
Ну и журналирование небесплатно: создает дополнительную нагрузку на процессор, память и дисковую подсистему сервера Exchange, вполне соизмеримую с рабочей.
В некоем банке (которого теперь нет) безопасникам просто зеркалировался весь трафик SMTP, а дальше они с этим работали на своем оборудовании — и это создавало куда меньшую нагрузку на серверы Exchange (которые на тот момент были перегружены).
PS Скрипты, чтобы они не были костылями, достаточно вполне адекватно документировать.

Зачем, к примеру, внедрять бэкапы, если можно все заскриптовать? Зачем кластеризовать системы, если опять же можно и руками все делать? С SMTP известная тема и широко используемая ИБ, но тут все же решается другая задача, а тема с ИБ условно бонусная. Опять же EV может выступать агрегатором информации из разных источников (самое популярное - тот же Skype for Business и переписки в нем).

Зачем, к примеру, внедрять бэкапы, если можно все заскриптовать? Зачем кластеризовать системы, если опять же можно и руками все делать?

Баланс «цена-качество» (в «качество» вхдят время реакции на сбой для кластеризации, упрощение отслеживания успешности процесса для резервного копирования и т.д.). Баланс — он для всех разный.
И про недостатки журналирования как средства обеспечения Discovery вы проигнорировали: встроенная eDiscovery, обрабатывающая сообщения по месту, куда как менее прожорлива. И что-то мне подсказывает, что наверняка кто-нибдь прикрутил к ней человеческий интерфейс (благо программный интерфейс для земли и облака примерно одинаков), только вот смотреть и искать откровенно лень.
И, кстати, ЕМНИП агрегатором информации из Lync/SfB Exchange умеет работать и в стандартной комплектации.

Скажу так: инструментов масса, у каждого есть плюсы и минусы, и все утилиты подбираются индивидуально. В статье рассказано об одном из них, пользоваться им или нет, каждый решает сам.

Все правильно.
Конечно, хотелось бы в этой же статье и про альтернативы хоть немного увидеть,
но понимаю, что нельзя объять необъятное.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.