top of page

Меню Exchange 2010

Public Folder

GAL

Сервер Mailbox.

​

Сервер Mailbox отвечает за работу двух типов баз данных: БД почтовых ящиков (Mailbox database) и БД общих папок (Public Folder Database).

В Mailbox database находятся почтовые ящики. Вы должны понимать, что Mailbox database зависит от версии сервера. В версии Standard, одновременно на сервере будет смонтировано не более 5 баз. В версии Exchange Enterprise максимальное количество одновременно смонтированных баз = 100. 

Public Folder Database ящики не хранит. На сервере Mailbox может быть только одна база Public Folder Database, т.е. нельзя создать на одном сервере Mailbox две БД общих папок.

Сервер Mailbox работает на движке ISE (доработанная версия называется Jet). MS пытаются сделать версию Exchange, которая работала бы на SQL, но пока этого не произошло. На ISE(Jet) также сегодня работает Active Directory, WINS, DHCP. 

Jet - транзакционная база данных. Для наглядности, чтобы было понятно, создадим новую БД.

​

База данных создается на уровне организации (Organization Configuration), в разделе Mailbox. Можно конечно же возразить, ведь ранее мы обсуждали, что БД для конкретного сервера создается на уровне Server Configuration. Дело в том, что в Exchange 2010 привязка БД к серверу весьма условна, т.к. здесь есть вариант отказоустойчивости DAG. В нём одна и та же база реплицируется между несколькими серверами, поэтому привязка БД к серверу условна. Так что, помните, что БД создается на уровне организации, хотя в предыдущих версиях она была на уровне сервера. 

Итак, создаем новую БД, кликнув New Mailbox Database из контекстного меню. Вводим имя БД и сервер, на котором она будет изначально располагаться.

Сразу после инсталляции вы получаете две БД: БД под почтовые ящики и БД Public Folder. Эти БД по дефолту будут в C:\Program Files\Microsoft\Exchange Server\V14\Mailbox.

Изменить это можно в следующем окне, в

котором можно вбить руками новый путь

(почему MS не сделали кнопку Обзор

остается загадкой). Создаем на диске D

новую папку MyDB и указываем новый путь. 

Обратите внимание, что указываются два

пути. Первый - это путь самой БД, а второй -

это трансзакционные логи. Поставьте снизу

галку, если хотите сразу примонтировать

базу. 

После установки рассмотрим содержимое папки.  

Итак, как работает трансзакционная база данных (яркий пример это SQL). Информация вначале попадает в оперативную память. Из ОП она попадает в трансзакционный лог (т.е. не в базу, а в отдельный лог) и когда происхоит чекпойнт, по чекпойнту информация записывается в файл базы данных. 

       E03.log - это текущий трансзакционный лог (current transaction log), в который происходит запись. Т.е. если кто-то прислал письмо, это письмо вначале попадает в текущий трансзакционный лог.

       Этот лог всегда размером 1 Мб, даже если в нем ничего нет.

       Представьте, что пришло письмо размером 3 Мб. Мы наполняем ТЛ и выясняется, что он закончился. Тогда текущий ТЛ переименовывается в E0300000001.log. Далее на основе шаблонного лога E03tmp.log происходит создание нового текущего ТЛ. Он ещё раз наполняется и ещё раз переименовывается, но теперь в  E0300000002.log и опять происходит создание нового текущего ТЛ. И так по кругу. Т.е. как только у нас появилась база и начали приходить письма, список отработанных ТЛ (E0300000001.log, 

E0300000002.log и т.д.) непрерывно будет расти.

     У ТЛ (и текущего и отработанного) есть особенность -  у них одинаковый префикс (E03), причем текущий ТЛ всегда состоит только из префикса (E03). Если вы создаете первую БД, у неё будет префикс E00 (+ база общий папок E01), создаете вторую БД - префикс соответственно E02.

       Раз в несколько секунд в Exchange происходит так называемый Checkpoint. В момент осуществления Checkpoint, информация, которая уже есть в отработанных ТЛ записывается в файл базы данных .edb (в нашем случае

​

MyDB.edb) и так по кругу. Т.е. пришли письма, новые трансзакционные логи отработались, информация записалась в базу. 

       Как только информация попадает в ТЛ и в базу edb, делается пометка в чек-файле .chk (в нашем примере E03.chk). Это проверочный файл, который всегда будет 8 Кб. В нём содержится информация, о том что транзакция проведена и данные содержаться и в трансзакционных логах и в базе данных.

Файл temp.edb. Предположим у вас БД 800 Гб. Вы переместили половину пользователей в новую БД. Старая останется 800 Gb. Она останется такой же, пока вы не выполните offline-дефрагментацию. Она осуществляется только в случае, если ваша БД размонтирована. У БД Exchange есть два состояния Mount и Dismount. Mount - база примонтирована, т.е. она залочена, работа ведётся (пользователи могут подключаться). Но в таком случае файл БД .edb залочен и мы ничего с ним сделать не можем.  Dismount - база размонтирована и не один человек к своему п/я не подлючится, но зато с файлом можно что-нибудь поделать офлайн. Так вот, чтобы уменьшить наши 800 Гб, надо базу размонтировать и сделать офлайн-дефрагментацию. Но вообще самый простой и хороший вариант раскидать ящики по новым и существующим базам, а базу 800 Gb грохнуть. Суть офлайн-дефрагментации в следующем: представьте комнату №1, в которую навалены коробки. Если коробки сложить одна к одной, то половина комнаты будет свободно. Но коробки навалены как попало, поэтому в комнату войти нереально. Но у нас есть соседняя комната №2, такая же по размеру. Поэтому мы берем по одной коробке и переносим в свободную комнату. Получаем пустую комнату №1 и наполовину пустую комнату №2. Берём таблички с номерами комнат и меняем их местами. Приблизительно так и выглядит дефрагментация в Exchange 2010: из файла MyDB.edb начинают переноситься данные в tmp.edb. Когда данные перенесены, оригинальный файл БД MyDB.edb удаляется, tmp.edb переименовывается в MyDB.edb и создается новый файл  tmp.edb.

(Легкое отступление. Если работали с SQL, там есть понятие Shrink, когда идёт освобождение свободного места в БД или ТЛ. В SQL есть mdf (файл БД) и ldf (файл ТЛ), т.е. данные пишутся в ТЛоги, потом потихоньку пишутся в БД. Потом вы бэкапите БД и ТЛ, но у вас ТЛ остается по размеру таким же. Его надо "шринькать", чтобы он уменьшился в размере. Смысла в принципе особо и нет, потому что следом идёт опять же увеличение ТЛ и он опять начнёт расти (до Shrink он растёт в рамках себя, где место ограничено (операция Autogroup)).

       Файлы с расширением .jrs просто резервируют место на жестком диске. Если у вас заканчивается место на диске, где находится база, у вас некуда расти новым трансзакционным логам, некуда расти базе, база отмонтируется. Поэтому файлы .jrs просто резервируют место. Их количество и размер (1 Мб) не меняется. Это наследие движка Jet, о котором говорилось выше. Он появился очень давно, а диске тогда были маленькие. Резервировать 10 Мб сегодня это конечно тупость.

       В папке с БД также имеется каталог CatalogData-... Это индекс, для того, чтобы ваши пользователи могли осуществлять поиск по почтовому ящику. Особой ценности эта папка не представляет. Там полнотекстовые индексы. Если вы её удаляете, то она создается и этот индекс генерируется заново (в зависимости от размера БД). Эта папка занимает порядка 5% от размера БД.         

       MS рекомендует в Exchange 2010 не выходить за пределы размера БД: 1 Tb для некластеризированной БД, 2 Tb для БД в кластере. Это с точки зрения производительности и удобства восстановления и резервного копирования. Но максимально допустимого предела нет, это всего лишь рекомендация. Хотя зачастую некоторые стараются держать базы до 500 Gb.  Я тоже. Кстати, для сравнения, в Exchange 2007 рекомендуемые значения были 100 и 200 Gb соответственно.

       Как сделать чтобы БД не разрасталась. Просто создаем вторую базу и перемещаем в нее часть почтовых ящиков.

MS рекомендует не хранить файл БД (в нашем случае MyDB.edb) и транзакционные логи на одном диске (или на одном луне). При создании БД вас не зря спрашивают, где будет расположен файл .edb и ТЛ. Отчасти это связано с производительностью, хотя в Exchange 2010 скорость работы БД  по сравнению с Exchange 2007 выросла на 70%.

       Представим что ТЛ и файл БД хранятся на одном диске и представим, чем это плохо. Вам в любом случае требуется делать резервное копирование, при котором старые транзакционные логи удаляются (без бэкапа ТЛ будут расти очень быстро; в итоге либо кончится место, либо вылетит диск с БД, а копии у вас нет). После выполнения Full backup, в него попадает файл .edb и ТЛ. Те ТЛ, которые уже попали в базу (т.е. те которые закоммичены) удаляются. Теперь представим картину. Ночью в 3 часа мы сделали бэкап, а после бэкапа, днём, в 15:00 у нас вылетел диск, на котором БД и ТЛ. Мы восстанавливаемся из ночного бэкапа, потеряв при этом информацию в 12 часов (между ночным бэкапом и вылетом диска). Если бы БД и ТЛ были на разных дисках, старые ТЛ при бэкапе тоже бы удалялись. Но! В 15:00 вряд ли вылетят диски и с БД и с ТЛ. Если у нас падает диск с ТЛ, мы потеряем только информацию с момента последнего чекпойнта. Т.е. буквально несколько секунд (про чекпойнт читайте выше). Берем новый диск, говорим "смонтировать базу данных", система говорит "я создам новые ТЛ", говорим "хорошо". Перетыкаем диски и работаем. Т.е. бэкап нам и не нужен. Но представим, что вылетел диск, на котором у нас БД. Тут уже без бэкапа не обойтись. Поднимаем бэкап с .edb, который был сделан в 3 часа ночи. И берем диск, где лежат все ТЛ с момента создания бэкапа. Следовательно, все действия, которые с момента создания бэкапа произошли с этой БД будут в этих ТЛ. Нам надо сделать проигрывание транзакционных логов и актуализировать нашу БД на момент падения. Средства восстановления автоматически проигрывают логи, если видят, что в папке более новые логи.      

​Свойства баз данных.

Свойства БД можно посмотреть в Organization Configuration -> Mailbox -> Вкладка Database Management.

На вкладке General можно увидеть общую информацию:

- путь, где находится файл .edb;

- смонтирована ли база;

- на каком сервере смонтирована;

- где хранятся копии этой базы (если у вас кластеризация,

БД может храниться на нескольких серверах). 

Вкладка Maintenance.

Дефрагментация бывает двух видов:

- offline, это когда мы размонтируем базу и применяем dsutil, база уменьшается;

- online, происходит, когда база работает.

Задачи у этих видов дефрагментации разные. Online-дефрагментация не сжимает базу.

Пример. Мы удалили почтовый ящик. Из базы Exchange никогда ничего моментально не удаляется. Для п/я есть параметр в 30 дней. Напротяжении этого времени мы можем восстановить этой ящик из БД, не прибегая к бэкапу. Online-дефрагментация пробегается по базе и смотрит, что 

было удалено (в нашем примере п/я) и истек ли период хранения. Если истек, выполняется удаление. Online-дефрагментация также проводит кучу проверок целостности БД.

В 2007 в поле Maintenance Schedule указывалось, что ежедневно с 1 часа ночи должна стартовать Online-дефрагментация. Галка Enable background database maintenance это нововведение 2010. Если она стоит, то  Exchange 2010 сам решает, когда ему делать Online-дефрагментацию. Сделано это для того, чтобы, если вы заметили, что при Online-дефрагментации у вас жуткие тормоза, снимаете галку и в Maintenance Schedule настраиваете время как вам надо. Т.е. при снятии галки у вас будет работать шедулер, а не 24x7. 

Галка "Не монтировать БД при запуске". Если перезагрузите сервер или перезапустите службу Microsoft Exchange Information Store, БД у вас автоматически не примонтируется.

Галка "БД может быть перезаписана при восстановлении". Это защита от дурака. Если галка не стоит, то нельзя при восстановлении из бэкапа перезатереть файлы базы. Короче говоря, чтобы вы, думая о базе А, случайно не перезатёрли базу В. Правда, чтобы случайно перезатереть базу В, надо чтобы она была отмонтирована. Так что эта галка особо и не нужна. Если конечно вам реально не потребуется перезатереть базу.

Галка "Включить кольцевое перезаписывание трансзакционных логов". Если галка стоит, то лог-файлы у вас не генерируются бесконечно, как это делается при обычном варианте восстановления. При варианте перезаписывания логов, делается чекпойнт и новые ТЛ перезаписывают старые. Т.е. создали вы базу, включить кольцевое перезаписывание и начинаете беспрерывно слать письма. У вас растут ТЛ. Потом происходит чекпойнт и они "обнуляются". Этот вариант хорош, когда вы переносите ящики из старой БД в новую. Например, была старая база 800 Гб и вы хотите переместить ящики в новую, чтобы грохнуть старую. Перемещение приведёт к тому, что у вас будет полтеррабайта логов, которые вам не нужны и удаляться они только после следующего бэкапа. Поэтому на обоих базах включаем Enable circular logging, переносим ящики и снимаем галку.

Вкладка Limits.

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

Issue warning at - когда, размер ящика будет подходить к 2 Гб, юзер будет получать предупреждение. Предупреждения будут рассылаться во время, указанное в Warning message interval (в нашем случае в 1 час ночи).

Если юзер игнорирует предупреждения, то при размере ящика равному полю Prohibit send at (в нашем случае 2 Гб), ему будет запрещена отправка писем.

Ну а позже, и получение, при превышении 2,5 Гб.

Шутка юмора от MS - предупреждения всё равно будут приходить!

В блоке Deletion settings задается время хранения удаленных элементов:

- Keep deleted items for = 14. 14 дней будут храниться удаленные письма и их можно достать, не прибегая к бэкапу;

- Keep deleted mailbox for = 30. 30 дней будут храниться удаленные п/я и их можно достать, не прибегая к бэкапу.

Галка "Не удалять из БД, пока вы не сделаете бэкап". Сроки, описанные выше не будут действовать, если стоит галка и не делается бэкап.

​

В Exchange 2010 отключили фичу SIS (Single Instance Storage), т.е. принцип единого хранения. Например, если в 2003 и 2007 вы делали рассылку для 50-ти пользователей и вкладывали в рассылку документ размером 5 Мб и все пользователи находились в одной БД, то БД вырастала на 5 Мб. Если вы делаете такую рассылку в 2010, то БД вырастет на 250 Мб. Сделали это в борьбе за скорость работы базы. Кстати, именно поэтому, когда перемещают почтовые ящики с 2003 и 2007 на 2010, БД резко вырастает.

Public Folder.

По сути, Public Folder это файловый сервер, содержимое которого хранится в Exchange'вской БД. Доступ к нему можно получать через почтовые клиенты.

Используя Public Folder вам не надо делать рассылку. Кладёте письмо в общую папку и все его читают. 

Создавать папки в корне Общие папки в Outlook по умолчанию могут только админы.

Настройка Public Folder происходит через Toolbox в EMC, в Public Folder Management Console.

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

PublicFolder

Default Public Folders - это общие папки, с которыми работают пользователи. Здесь можно создавать новые папки. Например, создадим папку Инструкции, куда будем складывать IT-инструкции для пользователей.

Нажав ПКМ на созданной папке и выбрав Mail Enable мы включим поддержку почты (чтобы появилось контекстное меню, нужно выбрать  Default Public Folders и в окне справа щелкнуть ПКМ на нужной папке).

Созданные папки лучше именуйте английскими названиями. При включении поддержки почты по умолчанию создается ящик инструкции@domain.ru.

Переходим в свойства созданной общей папки.

На вкладке разрешений через Add добавляем пользователя и присваиваем ему права. В списке Permission Level можно выбрать заранее подготовленную роль с уже готовыми правами (автор, публикующий редактор, владелец и т.д.). Галками можно проставить права вручную (пометил на картинке, кто за что отвечает).

​

MS планирует отказаться от общих папок, т.к. БД общих папок не кластеризируются. Для обеспечения хотя бы какой-то отказоустойчивости, вы можете реплицировать конкретные общие папки между несколькими Mailbox серверами.

Смотрите вкладку Replication в свойствах общей папки. К примеру, у вас есть 2 Mailbox сервера. На каждом у вас по одной БД общих папок. На одном сервере вы создаете папку и говорите, что она будет реплицироваться на другой сервер, в другую базу. Т.е. для конкретной папки вы указываете, между какими базами она будет реплицироваться. И далее указываете (либо на уровне базы, либо на уровне папки) интервал репликации. Итого, папка будет реплицироваться между двумя серверами. При этом будет любопытная ситуация. Репликация осуществляется по протоколу SMTP. Если вы положили файл размером 1,5 Мб, он бьется на куски по 300 Кб, по электронной почте отправляется на сервер назначения, там собирается и кладется в библиотеку. Т.е. когда у вас почта между двумя серверами не ходит, реплицая папок у вас тоже может не работать.

Также интересная вещь. Когда клиент заходит в общие папки и видит там какие-то папки, он не знает, на каком конкретно сервере каждая из этих папок находится. Если у вас два сервера и вы на каждом создадите по папке, то все клиенты будут видеть две папки и обращаться на конкретный сервер. Вообще БД общих папок и сами общие папки - это исключение, в том плане, что доступ к ним осуществляется напрямую к базе, а не через CAS. Если вы возьмете полноценный Outlook и посмотрите соединение, вы увидите, что к почтовому ящику все идут на CAS, а для БД общих папок все идут на Mailbox.

Итого, если вы включаете репликацию, папка реплицируется между двумя базами и одна БД становиться не доступна, пользователь может получить доступ к другой. Но в первую очередь клиент всегда подключается к реплике, находящейся в той базе, которая прописана у него в свойствах Mailbox'а. Посмотрите на скриншот ниже, из которого можно понять, что по умолчанию  

все клиенты, чьи п/я находятся в базе MyDb, идут за общими папками в указанную на вкладке Client Settings базу Public Folder Database 1.

Если вдруг эта БД недоступна, клиент попытается получить информацию с реплик, которые находятся на других базах.

Заметка. Когда на вкладке вы пытаетесь добавить реплику на вкладке Replication и нажимаете применить, у вас может появится окно с кучей ошибок. Заходите во вкладку Permissions, удаляете разрешения Owner у администратора, применяете, и заново добавляете его как владельца, снова применяете. После этого все отработает. Это баг.

​

Посмотрим наглядно на работу общих папок. У нас есть 2 сервера, на каждом есть по одной БД общих папок.

В EMS набираем Get-PublicFolderDatabase и видим вывод: есть два Exchange сервера, каждый из которых имеет БД общих папок.

Посмотрим конкретно по каждому серверу. Набираем Get-PublicFolder -server srv-miat-mail -recurse

​

​

Эта команда выведет нам общие папки, которые существуют на указанном сервере

Указываем второй сервер Get-PublicFolder -server srv-miat-exch1 -recurse

Мы видим ту же самую картину, что и в выводе выше. Почему так происходит.

Дело в том, что у нас есть дерево общих папок (Public Folder Tree). Оно храниться в AD и обновляется и реплицируется средствами AD. 

​

​

​

​

​

​

​

Откройте две оснастки с общими папками на разных серверах. Вид одинаковый, хотя папки хранятся на разных серверах и необязательно, что они реплицируются. Поэтому помните, что есть такое понятие как Public Folder Tree, т.е. дерево (или иерархия) общих папок. Если вы что-то создаете, после обновления у вас в оснастке на других серверах это появится.

​

 

 

 

 

 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Вы можете обновить иерархию вручную, ПКМ на "Public Folder - имя сервера" и выбрать Update Hierarchy.

Но помните, что несмотря на то, что вы видите все общие папки, если сервер, на котором располагается общая папка, недоступен, доступа к этой общей паке вы не получите. Т.е. вы зашли с клиента, видите общую папку, а доступа в неё нет.

Логичный вопрос, а как же посмотреть на каком сервере располагается общая папка? Зайдите в свойства общей папки и посмотрите сервер на вкладке Replication (скриншот был выше). Если этот сервер недоступен, пользователи увидят дерево, но в папку попасть не смогут.

Про репликацию я рассказывал выше. На вкладке Replication можно добавить необходимые сервера для репликации,, т.е. если один отвалится, папка будет доступна. Обновление общей папки идёт по расписанию, либо можно сделать это вручную (ПКМ на общей папке - Update Content).

Также помните, если двое пользователей меняют контент в общей папке, которая реплицируются, прав будет тот, кто был последним (как правило, как и во всех механизмах репликации). 

Получатели (Recipient) в Exchange.

Самый простой вариант - это Mailbox User, т.е. пользователь с включенным почтовым ящиком (учетка в AD, п/я и GAL(адресная книга)).

Вернее правильней его называть Mailbox Enable User. Его подвиды: Room Mailbox, Equipmant Mailbox, Linked Mailbox.

Создайте новый почтовый ящик через EMC и на первой странице перед вами появятся эти подвиды.

​

Room Mailbox и Equipmant Mailbox это спецящики. Они не используются для работы пользователями. Хотя и для Room Mailbox и для Equipmant Mailbox создается учетка, ящик и они отображаются в GAL. Т.е. всё что справедливо для обычного пользователя Mailbox Enable User, справедливо для Room Mailbox и Equipmant Mailbox. Принципиальная разница в том, что Room Mailbox это почтовые ящики, которые олицетворяют собой какое-то место. Это может быть переговорка, склад, какая-то комната. Т.е., представьте, у вас есть компания с 10-ю переговорными комнатами. Для каждой переговорки вы создаете отдельный Room Mailbox. Это удобно, когда пользователи будут работать с календарями, занимая переговорные комнаты. Equipmant Mailbox приблизительно тоже самое, только

создаются они не для комнаты, а для оборудования. Linked Mailbox это ящик, который фактически создается для учетной записи, которая находится в другом лесу AD. Существует такая организация, как Ресурсный лес. Это когда у вас много лесов AD и вы собрались внедрять Exchange. А как я обговаривал в самом начале, Exchange может быть только в одном лесу. Вот в таком случае есть конфигурация ресурсного леса. Linked Mailbox это как раз создание ящика для учетки, которая находится в другом лесу.

Продолжаем создание п/я.

Раньше, в 2003/2007 можно было создать ящик через ADUC. В 2010 так нельзя.

Здесь можно выбрать существующего пользователя и создать для него п/я. Если выберем New user, создается и учетка и почтовый ящик.

Если выбрали New user, вводим ту же информацию, которую указываем при создании учетки в ADUC (в каком OU будет пользователь, имя, логин, пароль и прочее).

     Указываем Alias. Это сокращение, по которому можно обратиться к почтовому ящику. Например, GetMailbox TvoyAlias.              Далее, указываем в какой БД должен храниться п/я. Если вы не указываете БД, по умолчанию происходит равномерное распределение почтовых ящиков между базами. Т.е. создаете 30 ящиков и у вас есть 3 базы. По 10 ящиков Exchange раскидает в каждую базу. 

     Retention Policy отвечает за хранение контента в ящике. Этой политикой вы можете сказать, что письма хранятся 3 недели, после этого удаляются.

     Exchange ActiveSync определяет параметры безопасности при подключении через ActiveSync. ActiveSync это подключение с Windows Mobile. Этой политикой вы можете сказать, например: если подключаешься с коммуникатора, камеру отключить.  И т.д. 

У каждого п/я есть размер, т.е. квота, выше которого он не растёт (по умолчанию 2 Гб).

Если лимит достигнут, обычно пользователь делает у себя архивацию и хранит .pst. PST плохи тем, что админ их не контролирует, они могут сыпаться, теряться и т.д.

MS предложил следующее. Вы создадите 2 БД: для основного почтового ящика и для архива. Основной будет лежать на быстром хранилище, а под архивы можно использовать медленное, но большое хранилище. И вся старая почта будет храниться в архивном п/я.

Итак, мы каждому пользователю создаем основной ящик и архивный. Архивный п/я доступен только online, т.е. если с Exchange у вас подлючения нет, доступа к архивному ящику у вас нет. Архивный п/я доступен либо с Outlook 2007/2010, либо

через OWA. Пользователь может руками перетаскивать почту в архивный ящик, либо вы настраиваете перемещение автоматически (например, почта старше 180 дней переезжает в архивный п/я. Выше я рассказывал про Retention Policy). Итого, на рисунке выбирайте  Create a local archive и указывайте БД, где будет лежать архивный ящик.

​

Операции с п/я.

Выберите ящик и посмотрите операции с ним в контекстном меню.

​

Remove. Учетная запись в AD удаляется, а п/я становиться Disconnected и удаляется через 30 дней. Поэтому, если вы хотите отключить п/я, но при этом сохранить учетку, выбирайте Disable. Учетка при этом останется, а ящик удалиться через 30 дней. Как мы уже говорили, в Exchange ничего сразу не удаляется. Поэтому если вы отключили почтовый ящик, то можете в EMC перейти в Disconnected Mailbox и оттуда восстановить ящик.

       Бывают случаи, когда ящик вы отключили, а в  Disconnected Mailbox его нет. Надо просто немного подождать. Если ждать не хотите, то в EMS выполните команду Clean-MailboxDatabase TvoyaBD. Ящик появится в EMC в Disconnected Mailbox. Посмотреть все отключенные ящики можно командой Get-MailboxDatabase | Get-MailboxStatistics | where {$_.DisconnectReason}

       

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

       В Disconnected Mailbox щелкните Connect на отключенном ящике. На первой странице выберите тип ящика и на следующей странице (см. рисунок слева) выберите пользователя, которому вы привяжите ящик.

       Matching user - это тот, кто последний владел.

       Existing user - это любой другой пользователь, к которому вы можете привязать восстанавливаемый ящик.

Возвращаемся к меню и операциям с п/я. 

New Local Move Request и New Remove Move Request - это перемещение ящика между базами. New Local Move Request - перемещение в одной организации. New Remove Move Request - перемещение в другую организацию Exchange. В 2010 работает технология Online Move, т.е. ящики перемещаются в живую и продолжают работать. Как это работает. В начале перемещения ящика делается снимок (технология VSS). Ящик начинает перемещается в новую базу,  пользователь продолжает работать со старой базой. Как только ящик переместился, делается ещё один снимок, но уже инкрементальный, т.е. те изменения, который произошли с момента создания первого снимка. В итоге, когда Exchange ловит два почтовых ящика на синхронность, он выполняет переключение. При переключении у пользователя отваливается ящик, но это на 10-15 секунд. 

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

При перемещении вы указываете новую БД (Target mailbox database).

Если у вас есть архивный ящик, внизу появятся дополнительные чекбоксы. Без архива их не будет.

В следующем окне задаемся вопросом: а если ящик у нас посыпан (т.е. есть логическое повреждение). Здесь мы можем указать количество поврежденных сообщений при перемещении.

Если пользователь в момент перемещения был подключен к ящику (например, через OWA), он отвалится. Почему? Пользователь у вас подключен к CAS. На этапе подключения к Client Access, он пользователя аутентифицирует (запрашивает логин и пароль), а потом обращается к контроллеру домена. И ему нужно обратиться к базе данных. Откуда CAS узнает, к какой БД нужно обращаться? С контроллера домена. Но БД при перемещении у вас поменялась. А CAS по прежнему считает, что вы находитесь в старой БД. Поэтому, чтобы сказать CAS, что вы на новой базе, надо просто заново аутентифицироваться, т.е. ввести логин и пароль. Если пользователь сидит в Outlook, надо закрыть и открыть его заново.

​

Свойства почтового ящика.

       На вкладке General есть кнопка Custom Attributes. В них вы можете прописать все, что угодно. В последствии вы можете осуществлять фильтрации и выборку на основе этих кастомных атрибутов.

       Переходим на вкладку E-Mail Addresses. Ещё раз оговариваюсь. Ящик - это просто место в базе. Между пользователями его можно перемещать как угодно. Имя для входа пользователя (logon name) по умолчанию никак не связано с электронным адресом. То, что они совпадают при создании ящика, просто политика по умолчанию - берется logon name и имя домена AD. Итого, во вкладке

E-Mail Addresses можно добавлять любые электронные адреса через кнопку Add. Мы можете добавить хоть 10 адресов, но только один адрес будет основным (выделенный жирным). Основной адрес - адрес, от имени которого будет отправляться почта. Принимать вы можете на все прописанные адреса.

Основной адрес формируется политикой. Чтобы сменить основной адрес, надо снять галку, выбрать другой адрес и нажать Set as Reply. Поставив галку обратно, вы всё вернёте как было.

На вкладке Mailbox Features можно включить или отключить различные варианты подключения. Также здесь можно к каждому варианту подключения подложить свою политику (выберите вариант подключения и нажмите Properties). 

Переходим во вкладку Mail Flow Setting.

В Message Size Restriction можно указать размер входящих и исходящих писем. По умолчанию в Exchange везде 10 Мб.

Вы дожлны понимать, что изменение размера сообщений делается на разных уровнях: на уровне ящика, на уровне транспорта, на уровнях коннектора приема, на уровне коннектора отправки. Всё это нужно делать в комплексе. Т.е. если у коннектора отправки у вас стоит 10 Мб, а ящику пользователя вы даете 50 Мб, ничего не изменится.

​

Distribution Group.

Группы рассылки бывают разные. Есть статические. Вы создаете группу и добавляете в неё юзеров. Есть динамические. Это когда вы явно не указываетt членство. Вы указываете признак, например, юзеры, работающие в отделе продаж. На основе этого артибута AD и будет осуществляться членство в динамической группе. Когда приходит письмо, транспорт обращается к КД, делает выборку, и те, кто соответствует выборке, получают письмо.

     В Membership Approval настраиваются разрешения на вход в группу.

Первая опция - кто может войти. Open - любой желающий. Close - никто, т.е. только руками через вкладку Members. Owner Approval - юзер может попроситься, но владелец группы должен это подтвердить.

Вторая опция - кто хочет уйти. Open - любой, т.е. юзер просто нажимает "Покинуть группу". Close - никто.

    На вкладке Group Information вы можете посмотреть владельца группы. Он отображается в поле Managed By. По умолчанию это юзер, который группу создал. 

     Если владельцев несколько, то оповещение о запросе на вхождение в группу будет приходить всем. Кто первый отработал, тот и прав.

​

На вкладке Mail Flow Settings в разделе Message Moderation можно настроить модерацию сообщений в группе.

В примере на рисунке слева, модерация означает:

- все сообщения, которые приходят на эту группу рассылки сначала приходят Иванову. У него две кнопки - пропустить дальше в рассылку или запретить письмо;

- сообщения Петрова не модерируются.

Имейте ввиду, сообщения от администраторов Exchange не модерируются.

Рассмотрим подробнее динамические группы.

На первой странице, также как и в случае статических групп, указываем в каком OU будет лежать группа, её имя и alias. А на 

следующей странице указываем, среди кого будет осуществляться выборка. По умолчанию Exchange предлагает искать в контейнере Users. Кнопкой Browse мы можем указать другой (например выбрать весь домен целиком). Ниже указываем тип пользователей, например, Users with Exchange mailboxes, т.е. классические юзеры с почтовыми ящиками.

И на следующей странице выбираем атрибуты, на основе которых юзеры будут включаться в эту группу. Выше я рассказывал про кастомные атрибуты, которые можно прописать каждому ящику. Так вот на рисунке слева можно выбрать первый атрибут и в поле ниже указать чему он равен. Если указанный атрибут и атрибут у ящика совпадают, этот ящик будет членом этой динамической группы. Есть удобная кнопка Preview, которая покажет, какие ящики подпадают под указанный вами атрибут.

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

Рассмотрим следующие типы получателей, которые есть в Exchange.

​

Это Mail Contact и Mail User. Mail Contact это визитка. В ней можно указать внешний адрес почты (например 123@mail.ru) и он будет отображаться в адресной книге. Также этот контакт пригодится, когда транспортным правилом вы хотите слать почту наружу на свой внешний ящик. В правиле нельзя просто указать адрес, например 123@mail.ru, но можно указать контакт. Mail User это внешний ящик для пользователя в AD. Например, пришёл новый сотрудник, вы сделали ему учетку в AD. А почтой он может пользоваться своей (например 123@mail.ru). Адрес будет отображаться в адресной книге. 

Обслуживание почтовых доменов.

Сразу после установки у вас формируются почтовые адреса с доменом, который совпадает с доменом AD. В большинстве случаев вам придется его менять (например, ваш домен domain.local, а почтовый domain.ru). Поэтому сразу после установки, одно из первых действий - это прописывание дополнительного почтового домена. Exchange может отвечать за множество почтовых доменов одновременно. Почтовый домен (или как в Exchange он называется Accepted Domain) - это домен для которого ваш Exchange принимает почту и от имени которого отправляет.

Заходим в Organization Configuration -> Hub Transport -> Вкладка Accepted Domains и указываем новый домен.

​

Если вы создаете почтовый домен, почта для которого будет хранится только в вашей организации Exchange, вы должны выбрать Authoritative Domain. 

Далее нам нужно, чтобы у всех пользователей домен сменился на newdomain.ru. Можно конечно менять вручную у каждого, но проще через политику. Переходим в соседнюю вкладкуE-mail Address Policies и создаем новую политику или изменяем дефолтную.

​

​

​

GAL. Global Address List.

     GAL это единая адресная книга на всю организацию Exchange. В ней есть всё - пользователи, группы и контакты. Кстати в GAL есть по умолчанию подгруппы - All Users, All Groups, All Contacts и прочее, где отображены только пользователи, только группы или только контакты соответственно.

     Через owa GAL доступен в онлайн. В Outlook можно включить режим кэширования, т.е. у вас локально будет файл ost, который синхронизируется с Exchange, если какие-то изменения произошли. Режим кэширования удобен при недоступности Exchange - вы продолжаете видеть свою почту, даже если Exchange недоступен. В режиме онлайн у вас всё пропадет. В режиме кэширования вы можете видеть офлайновую адресную книгу - это тот же GAL, который был выгружен в файлы и эти файлы скачиваются клиентами и используются локально. Т.е. есть GAL на сервере, сервер делает копию GAL (офлайновая адресная книга) и дает клиентам возможность её загрузить. 

GAL

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

Как узнать какую книгу вы используете, офлайн или GAL. В глобальном списке адресов ПКМ вызовите Свойства адресной книги. В появившемся окне, если в поле "Текущий сервер" указано имя почтового сервера - значит мы используем GAL. Если локальный путь (рисунок слева), значит мы используем офлайн книгу.

Вопрос. Почему, например, я использую режим кэширования, а адресная книга у меня GAL (как на рисунке справа). Дело в том, что офлайн адресную книгу надо сформировать на сервере и она должна быть загружена клиентом. Поэтому проверяем, выполнены  ли эти условия. Идём на сервер, в Organization Configuration в раздел Mailbox  во вкладку Offline Address Book. В колонке Generation Server будет отображаться сервер, который генерирует адресную книгу.

Заходим в Свойства - Customize и видим интервал, который говорит, что офлайн книга генерируется в 5 утра.

Поэтому, если у вас произошли какие-то изменения, пользователь узнает об этом только после 5 утра, когда книга будет сгенерирована и пользователь её закачает. Поэтому добавьте ещё несколько часов.

Если надо срочно обновить, можно сделать это вручную, не ожидая планировщика: ПКМ на офлайн книге - Update.

​

Далее в окне Свойств офлайн адресной книги переходим на вкладку Address Lists.

Установленная галка говорит о том, что в офлайн адресную книгу должен быть включен GAL. Т.е. всё что есть в GAL попадет в офлайн книгу. Вы можете выбрать чекбокс ниже и указать что-то конкретное, а не весь GAL целиком.

Далее переходим на вкладку Distribution.

Офлайн адресная книга распространяется двумя способами. Для старых клиентов (например, Outlook 2003), распространение идёт через общие папки. Т.е. когда она генерируется, она выкладывается в общие папки и клиенты Outlook 2003 её оттуда подгружают. Второй способ распространения - через виртуальную директорию на IIS сервере (т.е. на Client Access). Так могут забирать книгу только клиенты Outlook 2007 и 2010.

     Если старых клиентов у вас нет, снимите галку Enable public folder distribution. Она вам не нужна. Также снимите галку с клиентов Outlook 98, если у вас таких нет. Итого, всё лишнее убираем.

Зайдите на CAS сервере в IIS и посмотрите директорию под названием OAB. Нажмите ПКМ, выбрав Explore и перед вами появится каталог, где лежит офлайн адресная книга. Вот отсюда эта книга и будет забираться клиентами Outlook 2007 и 2010.   

     Но с настройкой офлайн книги мы ещё не закончили. В EMC идём в Server Configuration в Client Access, переходим на вкладку

Offline Address Book Distribution и вызываем свойства. Folling interval указывает, как часто CAS проверяет наличие обновленной офлайн книги и выкладывает её у себя.

Итого, прописанный Generation Server генерирует книгу, CAS лезет на Generation Server, проверяет новую версию и выкладывает у себя. 

Во вкладке URLs должны быть указаны внутренний и внешний URL адрес CAS сервера (я говорил, что если внешнее имя при установке не указывать, его придётся дописывать вручную. Вот здесь как раз одно из этих мест).

​

Через Outlook можно закачать офлайн книгу вручную: Отправка и получение - Группы отправки и получения - Загрузить адресную книгу.

Дополнительно отмечу, что на вкладке Address Lists в Organization Configuration в раздел Mailbox  вы увидите различные адрес листы GAL, где отдельно представлены разные объекты - пользователи, группы, контакты и прочее. Здесь можно создать свой адрес лист.

​

Переходите к следующей странице: CAS Server.

bottom of page