ExchangeRUS.ru

Всё о о Microsoft Exchange Server и электронной почте.

Сценарии использования Public Folders в Exchange

Опубликовано По

Хоть компания Microsoft и не рекомендует использовать Public Folders при построении решений, в форумах постоянно о них спрашивают, т.е. общие папки продолжают пользоваться своего рода популярностью и причины ее в общем-то понятны – наследие прошлого или бесплатное и простое решение для совместной работы.

          Мне же стало интересно, а собственно, как используют Public Folders на практике?

Из моих наблюдений Public folders используются:

  • Сообщения
  • закрытое хранилище общих сообщений небольших групп пользователей
  • например, отдел продаж или HR
  • хранилище общих сообщений  поступающих из Интернет
  • хранение важных документов в аттачах
  • Календарь
    • общие календари внутри групп
    • расписание отпусков, командировок, больничных, обучение
  • распределение ресурсов
    • автомобили, переговорные, оборудование
  • Контакты
    • общий список контактов предприятия, включая телефонную книгу
    • список контактов подрядчиков/заказчиков
    • список внешних полезных телефонов, адресов
  • Задачи
    • Проекты и задачи над которыми работает отдел в данное время
  • Приложения
    • специально разработанные приложения на основе форм, скриптов, модулей, кастомизирующих работу вышеперечисленных сценариев

                  Это список того, с чем я сталкивался. В MS Exchange 2007  работа с ресурсами изменилась в лучшую сторону, но в остальном все осталось примерно таким-же.     Если Вы можете расширить этот список, то пожалуйста, опишите в комментариях свои случаи.

    p.s.  Микрософт рекомендует для совместной работы использовать Sharepoint Server или Sharepoint Services вместо Public Folders. PF будут поддерживаться до 2014 года и в будущих версиях они поддерживаться не будут, развитие эта технология тоже не получит.

    Похожие посты:

    • Krep

      sharepoint хорошая штука, только ИМХО преимущество общих папок в репликации в т.ч. и по дохлым каналам

    • Kernelix Blogger

      Совместное использование данных во всех проявлениях 🙂 Все верно написал.

    • SergINI

      » только ИМХО преимущество общих папок в репликации в т.ч. и по дохлым каналам»
      5 баллов. Весь AD работает на репликациях и хранилище взятом из Exchange.
      Без репликаций Exchange вместо AD сейчас бы у всех NDS стоял (Novell Directory Services)

    • http://www.exchangerus.ru Pavel Nagaev

      ‘Без репликаций Exchange вместо AD сейчас бы у всех NDS стоял (Novell Directory Services)»
      Это еще почему?

    • http://www.exchangerus.ru Pavel Nagaev

      По поводу репликации. Два офиса, медленный канал, сервер в одном из офисов. Пользователи из офиса, где нет сервера взвоют от медленной работы. Решение — использование средств третьих фирм для репликации, у Микрософта пока его нет.

      У меня уже давно сложилось впечатление, что тенденция такая.  Каналы дешевеют, становятся более доступными и Микрософт на эту тему не очень парятся.  Мне как-то ответили, что резервирование SMTP в Exchange нужно делать с помощью резервирования каналов, а не средствами Exchange.

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

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

    • SergINI

      «Это еще почему?»- это потому что AD детёныш Exchange Servera. У MS не было времени создавать службу каталогов с нуля, так как % Novell-овских сетей среди корпоративных клиентов был очень высок в то время и MS теряла рынок, так как NDS активно покупался и рекламировался. Репликации- это основа службы каталогов, а репликации PB работали отлично. Вот так скоренько к выходу Win2000 из Exchange Servera создали AD. Об этом, например, писал Джеффри Шапиро.

    • http://www.exchangerus.ru Pavel Nagaev

      «AD детёныш Exchange Servera» — это Вы про базу Jet , чья разновидность использовалась в Exchange.

      The Extensible Storage Engine (ESE), also known as JET Blue, is an Indexed Sequential Access Method (ISAM) data storage technology from Microsoft. ESE is notably a core of Microsoft Exchange Server and Active Directory. Its purpose is to allow applications to store and retrieve data via indexed and sequential access. Windows Mail and Desktop Search in the Windows Vista operating system also make use of ESE to store indexes and property information respectively.

      «У MS не было времени создавать службу каталогов с нуля» думаю в этом просто не было необходимости, зачем велик-то изобретать. Это всего лишь способ хранения и доступа к данным.

      Я разговаривал с одним из PM на предмет перехода Exchange и AD на SQL, как-то они заявляли об этом. Так вот, он сказал, что Jet вполне клевая база и лучше подходит, чем SQL для Exchange. У Exchange есть особенность в работе при которой Jet эффективнее MS SQL и перевод Exchange на MS SQL остается под вопросом.

    • SergINI

      Не только. Ключевое слово «репликация». Не было у MS на тот момент ни одного продукта c отлаженным механизмом репликации, кроме репликаций, реализованных в Exchange Server. Думаю, что необходимость всё-таки была. AD был анонсирован ещё в 1996 году. Однако его реализации мы не видели до тех пор пока, как говориться: конкурент не клюнул.

    • http://www.exchangerus.ru Pavel Nagaev

      Спорить не буду, безусловно в Ваших словах есть доля истины, а что уж там было у Микрософт, ну я точно не знаю 🙂

    • Denis Osipov

      Павел, спасибо за познавательные статьи.

      Будет ли какая-нибудь статья с рекомендациями по организации Storage group и mailbox storage в рамках одной, средней по размерам организации?
      В частности, microsoft настоятельно не рекомендует превышать размер в 100 гигабайт для storage… однако по факту почты бывает больше.
      Вопрос не финансовый (enterpise довольно дорого стоит) и не политический (запретить большие письма и большие мейлбоксы), интересует именно best practice.

    • http://www.exchangerus.ru Pavel Nagaev

      best practice:  одна storage группа — одно хранилище. Делать хранилища как можно меньше по размеру. 

      Размер должен быть такой, чтобы базы успевали забекапится во время бекапного окна и чтобы процессы восстановления/ремонта баз занимали приемлемое время. Сколько — решайте сами.  Я стараюсь делать базы не более 10Гб, ограничение на размер ящика по всей компании 500Мб. 
      Для избранных пользователей — отдельные базы со своими ограничениями.

    • Denis Osipov

      Спасибо. Будем нарезать.
      Только увы, при общих объемах баз в 300-350 ГБ это будут куски явно не по 10 гиг. Видимо буду делить по отделам, чтобы письма занимали меньше места.

    • http://www.exchangerus.ru Pavel Nagaev

      Это все очень индивидуально и зависит, а общие тенденции я Вам написал.

    • 40a

      для репликации есть Groove
      репликация и в  Exchange никогда не выделялась качеством, по сравнению с тем же LotusNotes, автор которого и написал Groove впоследствии

    • http://www.exchangerus.ru Pavel Nagaev

      Пытаюсь увязать вышесказанное в голове и чего-то никак.

      Вы про репликацию Public folders?

    • Denis Osipov

      Вероятно про репликацию Sharepoint, через groove.

    • Joker

      «PF будут поддерживаться до 2014 года « — уточнение: до 2016.

      «Я разговаривал с одним из PM на предмет перехода Exchange и AD на SQL, как-то они заявляли об этом. Так вот, он сказал, что Jet вполне клевая база и лучше подходит, чем SQL для Exchange. У Exchange есть особенность в работе при которой Jet эффективнее MS SQL и перевод Exchange на MS SQL остается под вопросом.» — Идея перевода базы Exchange на SQL уже много лет витала в умах, но тестирование показало, что Jet с работой Exchange справляется намного лучше. Основная проблема в индексировании — SQL строит гигантский индекс, не различая между собой почтовые ящики, тогда как Jet подходит к индексированию более оптимально и тратит на это гораздо меньше ресурсов. По крайней мере, я слышал именно такое объяснение.

    • Vladislav Artukov

      Так вот, он сказал, что Jet вполне клевая база и лучше подходит, чем SQL для Exchange. У Exchange есть особенность в работе при которой Jet эффективнее MS SQL и перевод Exchange на MS SQL остается под вопросом.

      Все-таки SQL тщательнее заботится о целостности, а Exchange кладет куски в STM-файл.

      И мы можем получить такую ситуацию — есть письмо с хвостом в STM-файле,  STM-файл в этом месте поврежден. И мы не узнаем, что полписьма тю-тю, пока не полезем смотреть письмишко.

      Основная проблема в индексировании — SQL строит гигантский индекс

      SQL строит индексы так, как ему приказывают разработчики. Если разработчики Exchange так и не договорились, как строить индексы — ну, это же не проблема SQL engine 🙂